Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Moderators: mdrjr, odroid

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby Radium78 » Sat Mar 24, 2018 7:03 pm

I guess it could be work on Odroid XU4. I've installed the Ubuntu package "hugepages" to config hugepages by hugeadm, but this telles me, that the kernel does not support hugepages. So i think, is an issue made from the compiled kernel. But compiling a kernel is out of my mind.

Back to SGMINER-ARM. First, running scrypt doesn't work for me. I got everytime the error, that there is more memory demanded then available.

Running SGMINER in dual mining with cryptonote only is a mess. Tried both SGMINER and XMRIG and indeed SGMINER and CPUMINER-MULTI. Yes, it's not only a temp issue. You can reduce the CPU freq to increase the time before the XU4 will crash. But you can't prevent it. My XU4 has run at max. 50°C temp but crash appr. at 1h running.
I am worried about the many entries in syslog called "mali 11800000.mali: JD: Flushing cache due to PRLAM-10676". They comes every 10 seconds and mostly 5 or more entries at same time. Can't find any description about this message.

I didn't found a possibility to increase the upperlimit for using ram for the mali gpu. As i know, it's limited by 512M but it will used dynamicly from GPU.

Running two insatnce of SGMINER (1 for each GPU) also doesn't work. Both insatnce won't calc hashes. Very funny, the second GPU will have double hashrate, but never accepted hashes...

At the monent, i will give up dual mining.

Have you tried to mine with XU4 as cluster by using spark?
Radium78
 
Posts: 24
Joined: Mon Mar 19, 2018 3:30 am
languages_spoken: english
ODROIDs: XU4, C2

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby mad_ady » Sat Mar 24, 2018 8:25 pm

Very funny, the second GPU will have double hashrate,

It's expected. The GPU is made up from 6 processing units divided 2+4 logically. So one GPU instance will have double the performance.
User avatar
mad_ady
 
Posts: 4585
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2, N1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby Radium78 » Sun Mar 25, 2018 3:45 am

Okay, just a hint. The error message "mali 11800000.mali: JD: Flushing cache due to PRLAM-10676" doesn't appear when running only one gpu. This error must be cause by dual gpu using. If you have time to check ;-)
Radium78
 
Posts: 24
Joined: Mon Mar 19, 2018 3:30 am
languages_spoken: english
ODROIDs: XU4, C2

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby hominoid » Sun Mar 25, 2018 11:07 am

Hi Radium78, I'm going to try and answer your questions, but out of order
Radium78 wrote:Have you tried to mine with XU4 as cluster by using spark?
No, I have not.

Radium78 wrote:Back to SGMINER-ARM. First, running scrypt doesn't work for me. I got everytime the error, that there is more memory demanded then available.
I'm assuming your talking about Verium (VRM) which uses scrypt squared or scrypt with N Factor=1048576. It is designed not to be mine-able with a GPU by design. It uses more memory than GPU's have and is design not to be economical to design FPGA or ASIC's to mine it through this same strategy. That is what makes it a CPU only mine-able coin. So, I'm not surprised by the error message your getting and it is exactly what I would expect. Please read the white papers at the Verium site for more information.

Radium78 wrote:I didn't found a possibility to increase the upper limit for using ram for the mali gpu. As i know, it's limited by 512M but it will used dynamicly from GPU.
I'm not sure what this means or what your asking but some facts, the GPU is limited in the memory it has access to and it cannot dynamically allocate more. The Mali-T628 uses a non-coherent cache which means that both devices use their own memory area and cannot access each others. This is why there are 2 OpenCL kernels that are started when both devices are used

Radium78 wrote:Running two insatnce of SGMINER (1 for each GPU) also doesn't work. Both insatnce won't calc hashes. Very funny, the second GPU will have double hashrate, but never accepted hashes...
I think I know what you mean but I want to be clear...If you mean literally running sgminer-arm twice(2 instances), then that is definitely problematic. There is one GPU with two devices, each device runs one OpenCL kernel, because the Mali-T628 has non-cohernt caches. This is what I believe your implying and @mad_ady already answered part of your question.
mad_ady wrote:It's expected. The GPU is made up from 6 processing units divided 2+4 logically. So one GPU instance will have double the performance.
Not ever getting accepted hashes is typical when your tuning configuration is wrong or your pushing the GPU to hard. It is producing hashes but not good hashes and therefore will not find valid hashes and the pool/GPU will not show accepted hashes. The solution to this problem is to re-tune the GPU resources lower. This could be part of or why your getting the error messages in the syslog. Which leads into the last issue.
Radium78 wrote:I am worried about the many entries in syslog called "mali 11800000.mali: JD: Flushing cache due to PRLAM-10676". They comes every 10 seconds and mostly 5 or more entries at same time. Can't find any description about this message.


IMO, It still sounds like your trying to push the GPU too hard. In the 12 hour run I posted while testing cryptonight, I received 56 GPU hardware errors. This indicated to me I needed to tune the performance down some, especially if I expected to extended the run time any longer otherwise, It most likely would have eventually crashed.
Radium78 wrote:Running SGMINER in dual mining with cryptonote only is a mess. Tried both SGMINER and XMRIG and indeed SGMINER and CPUMINER-MULTI. Yes, it's not only a temp issue. You can reduce the CPU freq to increase the time before the XU4 will crash. But you can't prevent it. My XU4 has run at max. 50°C temp but crash appr. at 1h running.

IMO, your setup for dual mining the CPU as well as the GPU may be too much for your cooling configuration(2 passive XU4's with a 12v 90mm fan running at 5v). A recent study I read by Microsoft Engineers working with SBC's indicated that fan proximity and angle makes a big difference in the cooling and sustainable operation for heavy workloads as well. Without much more detail I can only speculate(frequency, ambient temp, thread count for the CPU, GPU settings or whether your pool or solo mining to name a few). It also takes a lot more energy and system resources if your pool mining then solo mining and the algorithms your running. More than once I have run 8-12 hours or more with what I thought was adequate temperatures only to find a hung or crashed system. Turning down the CPU frequency more ultimately solved the problem in all cases. The work load can vary greatly, especially when pool mining. Look at the Pool hash rate chart from the 12 hour cryptonight test and notice the significant increase in hash rate that happens from time to time during that extended run. Add to that ambient temperature changes that occur in most environments, a machine already tuned at, near or beyond it's capability and you can get crashes at any time.

Now with all that said, there are definitely other things it could be and I could just be plain wrong; at the sgminer-gm git site there are 70 reported issues. But until I know more, I'm still in the camp that more needs to be done to improve your cooling and tuning of both the CPU and GPU for what your trying to do. I'm in the middle of some things but, when I get a chance, I will stage a XU4 dual mining on cryptonight and post back here the results of what I find.
hominoid
 
Posts: 186
Joined: Tue Feb 28, 2017 3:55 am
Location: Lake Superior Basin, USA
languages_spoken: english
ODROIDs: C2, XU4, MC1, N1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby hominoid » Mon Mar 26, 2018 12:09 am

Long Run Cryptonight Test
Late last night I started a long run dual mining test on a MC-1 cluster for cryptonight. 2 running sgminer, XMRig and 2 running sgminer, cpuminer-multi. Approximate reported hashrate for each are GPU's 19h/m, CPU's 19h/m

All machines 1.7Ghz frequency, ambient temperature 71f (21.66c)
All machines - Linux c5n0 4.14.5-92 #1 SMP PREEMPT Mon Dec 11 15:48:15 UTC 2017 armv7l armv7l armv7l GNU/Linux

c5n0 - GPU sgminer-5.5.6-ARM-RC1, CPU XMRig version 2.44
c5n1 - GPU sgminer-5.5.6-ARM-RC1, CPU XMRig version 2.51 (latest release posted 1 day ago)
c5n2 - GPU sgminer-5.5.6-ARM-RC1, CPU cpuminer-multi version 1.3.1
c5n3 - GPU sgminer-5.5.6-ARM-RC1, CPU cpuminer-multi version 1.3.1

sgminer-5.5.6-ARM-RC1 GPU Configuration
-I 6 -w 32 -d 0,1 --thread-concurrency 8192 --monero --pool-no-keepalive

XMRig version 2.44 & 2.51 CPU Configuration
-t 7 --cpu-affinity 0xFE

cpuminer-multi CPU Configuration
-t 7 --randomize --no-redirect --cpu-affinity 0xFE

As of this posting the test has run for 9+ hours with no abnormal issues on any machine. At 8:42 hours, c5n1 was changed from xmrig version 2.44 to version 2.51 without stopping the GPU. FYI, As of April 7, 2018 there is a hard fork of the Monero (XMR) block chain which requires most mining software to be updated. sgminer-5.5.6-ARM-RC1 should have all the changes already incorporated. XMRig versions prior to 2.5 are affected. Stay tuned for the results...
hominoid
 
Posts: 186
Joined: Tue Feb 28, 2017 3:55 am
Location: Lake Superior Basin, USA
languages_spoken: english
ODROIDs: C2, XU4, MC1, N1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby Radium78 » Mon Mar 26, 2018 3:26 pm

yes, got it running also. But why is only gpu 1 flushing cache and gpu 0 doesn't create this message in syslog? driver issue?

If have also hugepage enabled now (you need to recompile kernel for that). But for cryptonight there is no increase of performance.
Radium78
 
Posts: 24
Joined: Mon Mar 19, 2018 3:30 am
languages_spoken: english
ODROIDs: XU4, C2

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby hominoid » Fri Mar 30, 2018 4:34 am

Stability Testing Complete
After 4 days and 8 hours of stability testing everything ran as expected with no errors reported in any syslog. Both XMRig and cpuminer-multi ran normally. Configuration used as previously reported:

Approximate reported hashrate for each are GPU's 19h/s, CPU's 19h/s as reported by the application.
All machines 1.7Ghz frequency, ambient temperature 71f (21.66c)
All machines - Linux c5n0 4.14.5-92 #1 SMP PREEMPT Mon Dec 11 15:48:15 UTC 2017 armv7l armv7l armv7l GNU/Linux

c5n0 - GPU sgminer-5.5.6-ARM-RC1, CPU XMRig version 2.44
c5n1 - GPU sgminer-5.5.6-ARM-RC1, CPU XMRig version 2.51
c5n2 - GPU sgminer-5.5.6-ARM-RC1, CPU cpuminer-multi version 1.3.1
c5n3 - GPU sgminer-5.5.6-ARM-RC1, CPU cpuminer-multi version 1.3.1

sgminer-5.5.6-ARM-RC1 GPU Configuration
-I 6 -w 32 -d 0,1 --thread-concurrency 8192 --monero --pool-no-keepalive

XMRig version 2.44 & 2.51 CPU Configuration
-t 7 --cpu-affinity 0xFE

cpuminer-multi CPU Configuration
-t 7 --randomize --no-redirect --cpu-affinity 0xFE

Results
All sgminer's showed similar performance as c5n0. Summary of each miner is included below.
c5n0-4Days8Hours-clip.png
c5n0-4Days8Hours-clip.png (33.44 KiB) Viewed 2081 times

c5n0 Summary Results
Code: Select all
[13:53:00] Shutdown signal received.
[13:53:00]
Summary of runtime statistics:

[13:53:00] Started at [2018-03-25 05:38:19]
[13:53:00] Pool: stratum+tcp://pool.supportxmr.com:3333
[13:53:00] Runtime: 104 hrs : 14 mins : 40 secs
[13:53:00] Average hashrate: 0.0 Kilohash/s
[13:53:00] Solved blocks: 0
[13:53:00] Best share difficulty: 16.2M
[13:53:00] Share submissions: 1012
[13:53:00] Accepted shares: 995
[13:53:00] Rejected shares: 17
[13:53:00] Accepted difficulty shares: 5006256
[13:53:00] Rejected difficulty shares: 85000
[13:53:00] Reject ratio: 1.7%
[13:53:00] Hardware errors: 352
[13:53:00] Utility (accepted shares / min): 0.16/min
[13:53:00] Work Utility (diff1 shares solved / min): 0.16/min

[13:53:00] Stale submissions discarded due to new blocks: 0
[13:53:00] Unable to get work from server occasions: 272
[13:53:00] Work items generated locally: 407984
[13:53:00] Submitting work remotely delay occasions: 0
[13:53:00] New blocks detected on network: 3096

[13:53:00] Summary of per device statistics:

[13:53:00] GPU0                | (5s):9.359 (avg):9.341h/s | A:2522369 R:25000 HW:170 WU:0.081/m
[13:53:00] GPU1                | (5s):9.361 (avg):9.329h/s | A:2483886 R:60000 HW:182 WU:0.081/m

c5n1 Summary Results
Code: Select all
[13:52:55] Shutdown signal received.
[13:52:55]
Summary of runtime statistics:

[13:52:55] Started at [2018-03-25 05:38:28]
[13:52:55] Pool: stratum+tcp://pool.supportxmr.com:3333
[13:52:55] Runtime: 104 hrs : 14 mins : 26 secs
[13:52:55] Average hashrate: 0.0 Kilohash/s
[13:52:55] Solved blocks: 1
[13:52:55] Best share difficulty: 1.23M
[13:52:55] Share submissions: 1027
[13:52:55] Accepted shares: 1008
[13:52:55] Rejected shares: 19
[13:52:55] Accepted difficulty shares: 5053564
[13:52:55] Rejected difficulty shares: 95000
[13:52:55] Reject ratio: 1.9%
[13:52:55] Hardware errors: 353
[13:52:55] Utility (accepted shares / min): 0.16/min
[13:52:55] Work Utility (diff1 shares solved / min): 0.16/min

[13:52:55] Stale submissions discarded due to new blocks: 0
[13:52:55] Unable to get work from server occasions: 223
[13:52:55] Work items generated locally: 407460
[13:52:55] Submitting work remotely delay occasions: 0
[13:52:55] New blocks detected on network: 3096

[13:52:55] Summary of per device statistics:

[13:52:55] GPU0                | (5s):9.331 (avg):9.351h/s | A:2405910 R:50000 HW:176 WU:0.078/m
[13:52:55] GPU1                | (5s):9.324 (avg):9.340h/s | A:2647653 R:45000 HW:177 WU:0.086/m

c5n2 Summary Results
Code: Select all
[13:52:48] Shutdown signal received.
[13:52:48]
Summary of runtime statistics:

[13:52:48] Started at [2018-03-25 05:38:38]
[13:52:48] Pool: stratum+tcp://pool.supportxmr.com:3333
[13:52:48] Runtime: 104 hrs : 14 mins : 9 secs
[13:52:48] Average hashrate: 0.0 Kilohash/s
[13:52:48] Solved blocks: 1
[13:52:48] Best share difficulty: 50.1M
[13:52:48] Share submissions: 1034
[13:52:48] Accepted shares: 1009
[13:52:48] Rejected shares: 25
[13:52:48] Accepted difficulty shares: 5081646
[13:52:48] Rejected difficulty shares: 125000
[13:52:48] Reject ratio: 2.4%
[13:52:48] Hardware errors: 334
[13:52:48] Utility (accepted shares / min): 0.16/min
[13:52:48] Work Utility (diff1 shares solved / min): 0.17/min

[13:52:48] Stale submissions discarded due to new blocks: 0
[13:52:48] Unable to get work from server occasions: 257
[13:52:48] Work items generated locally: 414051
[13:52:48] Submitting work remotely delay occasions: 0
[13:52:48] New blocks detected on network: 3099

[13:52:48] Summary of per device statistics:

[13:52:48] GPU0                | (5s):9.226 (avg):9.186h/s | A:2607526 R:45000 HW:172 WU:0.084/m
[13:52:48] GPU1                | (5s):9.225 (avg):9.188h/s | A:2474119 R:80000 HW:162 WU:0.081/m

c5n3 Summary Results
Code: Select all
[13:52:38] Shutdown signal received.
[13:52:38]
Summary of runtime statistics:

[13:52:38] Started at [2018-03-25 05:38:47]
[13:52:38] Pool: stratum+tcp://pool.supportxmr.com:3333
[13:52:38] Runtime: 104 hrs : 13 mins : 51 secs
[13:52:38] Average hashrate: 0.0 Kilohash/s
[13:52:38] Solved blocks: 3
[13:52:38] Best share difficulty: 4.01M
[13:52:38] Share submissions: 1059
[13:52:38] Accepted shares: 1028
[13:52:38] Rejected shares: 31
[13:52:38] Accepted difficulty shares: 5165010
[13:52:38] Rejected difficulty shares: 155000
[13:52:38] Reject ratio: 2.9%
[13:52:38] Hardware errors: 350
[13:52:38] Utility (accepted shares / min): 0.16/min
[13:52:38] Work Utility (diff1 shares solved / min): 0.17/min

[13:52:38] Stale submissions discarded due to new blocks: 1
[13:52:38] Unable to get work from server occasions: 251
[13:52:38] Work items generated locally: 405818
[13:52:38] Submitting work remotely delay occasions: 1
[13:52:38] New blocks detected on network: 3096

[13:52:38] Summary of per device statistics:

[13:52:38] GPU0                | (5s):9.319 (avg):9.247h/s | A:2365471 R:75000 HW:175 WU:0.078/m
[13:52:38] GPU1                | (5s):9.336 (avg):9.265h/s | A:2799539 R:80000 HW:175 WU:0.092/m

Pool Graph

c5n0-c5n3-Pool-4Days8Hours-clip.png
c5n0-c5n3-Pool-4Days8Hours-clip.png (106.8 KiB) Viewed 2081 times
hominoid
 
Posts: 186
Joined: Tue Feb 28, 2017 3:55 am
Location: Lake Superior Basin, USA
languages_spoken: english
ODROIDs: C2, XU4, MC1, N1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby Radium78 » Sat Apr 07, 2018 2:35 am

Since Monero has changed to PoW v7 there are a lot of invalid shares with SGMINER_ARM which didn't happend before. Can you check it?

Did you think about an ARM version of xmrig-amd gpu miner?
Radium78
 
Posts: 24
Joined: Mon Mar 19, 2018 3:30 am
languages_spoken: english
ODROIDs: XU4, C2

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby Radium78 » Sat Apr 07, 2018 3:27 pm

I think, cryptonight algo is not working proper. I've seen a lot of "rejected stratum share..." caused by an unknown json-message "procedure not found". This is only happen with cryptonight on Minergate.

On supportXMR and MoneroOcean this rejections never happend before change to Monero v7. I did not checked if cryptonight (xmr) is working proper at supportXMR or MoneroOcean now. But those rejection will count as a reject in the overall counter but never in the accept/reject ratio. So you get something like A:200000 | R: 300000 but the ratio is R:0.1%, which doesn't make sense. And I am not sure if supportXMR and MoneroOcean have switched to new Algo right now. As I know, they have time til april 24th.

I know it work with XMRIG proper on Minergate. So I believe it's still a problem with SGMINER.

What have you changed on the SGMINER fork to get it running with MALI T628 and ARM comupte libary without using and installing AMD SDK?
Radium78
 
Posts: 24
Joined: Mon Mar 19, 2018 3:30 am
languages_spoken: english
ODROIDs: XU4, C2

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby hominoid » Sun Apr 08, 2018 11:16 am

Radium78 wrote:I think, cryptonight algo is not working proper. I've seen a lot of "rejected stratum share..." caused by an unknown json-message "procedure not found". This is only happen with cryptonight on Minergate.

On supportXMR and MoneroOcean this rejections never happend before change to Monero v7. I did not checked if cryptonight (xmr) is working proper at supportXMR or MoneroOcean now. But those rejection will count as a reject in the overall counter but never in the accept/reject ratio. So you get something like A:200000 | R: 300000 but the ratio is R:0.1%, which doesn't make sense. And I am not sure if supportXMR and MoneroOcean have switched to new Algo right now. As I know, they have time til april 24th.

I know it work with XMRIG proper on Minergate. So I believe it's still a problem with SGMINER.

What have you changed on the SGMINER fork to get it running with MALI T628 and ARM comupte libary without using and installing AMD SDK?


There are a lot of things going on with the cryptonight algorithm and the coins that use it right now. I would advice you do more reading and specifics research. As far as I can tell there is nothing wrong with sgminer-arm-5.5.6-arm-RC1.

From the Monero Developers regarding Monero v7:
"Patches will be available for the following software: zone117x's pool, Snipa's pool, Lucas Jones' CPU miner, wolf0's CPU miner, ccminer-cryptonight, sgminer-gm, xmr-stak, xmrig-nvidia, wolf-xmr-miner."

Here is what I believe I know:

1. The MoneroV (XMV) hard fork has not taken place yet. It has been postponed until the end of the month. The Monero v7 (XMR) fork happened on April 6th. https://monero.org/forks/

2. Various pools may or may not have upgraded their software. Know what and where your mining.

3. The announced ASIC machines, even though pre-release, are apparently already running on the block chains and having an effect. I have read that other miners are already indicating a 20% lower ROI. The ASIC machines have approximately 10 times the hash at 1/2 the power usage of a GPU and will affect all cryptonight block chains (Monero and other coins) negatively(higher network hash rate, more rejected/stale shares, etc).

Radium78 wrote:So you get something like A:200000 | R: 300000 but the ratio is R:0.1%, which doesn't make sense.

4. The README.md file and other documentation clearly indicate what A and R stand for and it is not accepted and rejected shares:
"The output line shows the following: (5s):1713.6 (avg):1707.8 Mh/s | A:729 R:8 HW:0 WU:22.53/m
Each column is as follows: 5s: A 5 second exponentially decaying average hash rate avg: An all time average hash rate A: The total difficulty of Accepted shares R: The total difficulty of Rejected shares HW: The number of HardWare errors WU: The Work Utility defined as the number of diff1 shares work / minute (accepted or rejected)."

5. I have not used Minergate but as I understand it is a not a traditional pool as your indicating. That's why they have their own GUI/Mining software. Others have posted and indicated many varying problems with minergate over time. Their reputation proceeds them. Both them and Nicehash are banned by some pools and are known not to follow the established protocols. The developers of sgminer-gm have posted about their specific issues with Nicehash many times at different places.

6. The files effected and changes made for sgminer-arm-5.5.6-arm-RC1 are well document in the posts above and the specific code changes can be viewed at the git. They have nothing to do with the Monero v7 fork, only optimizations.

7. At the sgminer-gm git, there are no new valid issues opened. There have been no new commits since I forked from the sgminer-gm-5.5.6 Master.

8. There is a testnet pool for the Monero new POW: http://killallasics.moneroworld.com/ Feel free to use it.

MoneroPOWTestPool.jpg
MoneroPOWTestPool.jpg (401.4 KiB) Viewed 1975 times

Code: Select all
root@c0n0:~/sgminer-arm# ./sgminer-start-monero-testpool
[00:31:39]
Summary of runtime statistics:

[00:31:39] Started at [2018-04-08 00:24:34]
[00:31:39] Pool: stratum+tcp://killallasics.moneroworld.com:3333
[00:31:39] Runtime: 0 hrs : 7 mins : 4 secs
[00:31:39] Average hashrate: 0.0 Kilohash/s
[00:31:39] Solved blocks: 0
[00:31:39] Best share difficulty: 33.9K
[00:31:39] Share submissions: 22
[00:31:39] Accepted shares: 22
[00:31:39] Rejected shares: 0
[00:31:39] Accepted difficulty shares: 4100
[00:31:39] Rejected difficulty shares: 0
[00:31:39] Reject ratio: 0.0%
[00:31:39] Hardware errors: 10
[00:31:39] Utility (accepted shares / min): 3.14/min
[00:31:39] Work Utility (diff1 shares solved / min): 3.14/min

[00:31:39] Stale submissions discarded due to new blocks: 0
[00:31:39] Unable to get work from server occasions: 1
[00:31:39] Work items generated locally: 469
[00:31:39] Submitting work remotely delay occasions: 0
[00:31:39] New blocks detected on network: 9

[00:31:39] Summary of per device statistics:

[00:31:39] GPU0                | (5s):13.32 (avg):13.10h/s | A:2100 R:0 HW:7 WU:1.714/m
[00:31:39] GPU1                | (5s):10.31 (avg):10.36h/s | A:2000 R:0 HW:3 WU:1.428/m
[00:31:39]
root@c0n0:~/sgminer-arm#

9. For sgminer-arm-5.5.6-arm-RC1, Notice that "monero variant 1" was recognized as the algorithm and set for the GPU devices in the posted samples for both pool.supportxmr.com and the Monero new POW testnet pool above.

MoneroTest-supportXMR.jpg
MoneroTest-supportXMR.jpg (404.18 KiB) Viewed 1975 times

Code: Select all
root@c0n0:~/sgminer-arm# ./sgminer-start-monero
[00:08:45]
Summary of runtime statistics:

[00:08:45] Started at [2018-04-07 23:11:04]
[00:08:45] Pool: stratum+tcp://pool.supportxmr.com:3333
[00:08:45] Runtime: 0 hrs : 57 mins : 40 secs
[00:08:45] Average hashrate: 0.0 Kilohash/s
[00:08:45] Solved blocks: 0
[00:08:45] Best share difficulty: 115K
[00:08:45] Share submissions: 16
[00:08:45] Accepted shares: 16
[00:08:45] Rejected shares: 0
[00:08:45] Accepted difficulty shares: 80000
[00:08:45] Rejected difficulty shares: 0
[00:08:45] Reject ratio: 0.0%
[00:08:45] Hardware errors: 2
[00:08:45] Utility (accepted shares / min): 0.28/min
[00:08:45] Work Utility (diff1 shares solved / min): 0.28/min

[00:08:45] Stale submissions discarded due to new blocks: 0
[00:08:45] Unable to get work from server occasions: 3
[00:08:45] Work items generated locally: 3674
[00:08:45] Submitting work remotely delay occasions: 0
[00:08:45] New blocks detected on network: 12

[00:08:45] Summary of per device statistics:

[00:08:45] GPU0                | (5s):13.31 (avg):13.35h/s | A:50000 R:0 HW:2 WU:0.174/m
[00:08:45] GPU1                | (5s):10.44 (avg):10.42h/s | A:30000 R:0 HW:0 WU:0.104/m
[00:08:45]
root@c0n0:~/sgminer-arm#
hominoid
 
Posts: 186
Joined: Tue Feb 28, 2017 3:55 am
Location: Lake Superior Basin, USA
languages_spoken: english
ODROIDs: C2, XU4, MC1, N1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby odroid » Mon Apr 23, 2018 10:11 am

@hominoid,

Do you know how we can check the 6 GPUs usage?
Is there any sysfs node to monitor the GPU utilization on Kernel 4.14?
User avatar
odroid
Site Admin
 
Posts: 28704
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby rooted » Mon Apr 23, 2018 11:44 am

Gator is the only way I know

https://github.com/ARM-software/gator
User avatar
rooted
 
Posts: 5579
Joined: Fri Dec 19, 2014 9:12 am
Location: Gulf of Mexico, US
languages_spoken: english
ODROIDs: C1, C1+, C2
XU3 Lite, XU4
N1
VU7+
HiFi Shield 2
Smart Power (original)

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby hominoid » Tue Apr 24, 2018 1:36 am

odroid wrote:@hominoid,

Do you know how we can check the 6 GPUs usage?
Is there any sysfs node to monitor the GPU utilization on Kernel 4.14?

Not that I have found anywhere yet.
hominoid
 
Posts: 186
Joined: Tue Feb 28, 2017 3:55 am
Location: Lake Superior Basin, USA
languages_spoken: english
ODROIDs: C2, XU4, MC1, N1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby odronew » Fri Apr 27, 2018 6:46 am

Hello,

I have an HC1, loaded with the Optimized OS Image for Verium Mining (https://wiki.vericoin.info/index.php?title=Odroid). I have compiled sgminer 2 times following the very detailed updated guide on the 1st page.

Some info:

Code: Select all
uname -a
Linux OdroidHC1 4.14.0+ #1 SMP PREEMPT Wed Nov 15 21:41:32 UTC 2017 armv7l armv7l armv7l GNU/Linux


Code: Select all
lsb_release -a
No LSB modules are available.
Distributor ID:   Ubuntu
Description:   Ubuntu 16.04.4 LTS
Release:   16.04
Codename:   xenial


Code: Select all
./sgminer --ndevs
[00:29:45] CL Platform vendor: ARM                   
[00:29:45] CL Platform name: ARM Platform                   
[00:29:45] CL Platform version: OpenCL 1.2 v1.r12p0-04rel0.03af15950392f3702b248717f4938b82                   
[00:29:45] Platform devices: 2                   
[00:29:45]    0   Mali-T628                   
[00:29:45]    1   Mali-T628                   
[00:29:45] 2 GPU devices max detected     


Code: Select all
sysctl -p
vm.nr_hugepages = 839


From the above I can see that GPUs are detected.

I am executing this script:

Code: Select all
cat test_monero.sh
#!/bin/bash

export GPU_FORCE_64BIT_PTR=1
export GPU_USE_SYNC_OBJECTS=1
export GPU_MAX_ALLOC_PERCENT=100
export GPU_SINGLE_ALLOC_PERCENT=100
export GPU_MAX_HEAP_SIZE=100

./sgminer -k cryptonight -o stratum+tcp://killallasics.moneroworld.com:3333 -u my_XMR_address  -p x -I 6 -w 32 -d 0,1 --thread-concurrency 8192 --monero --pool-no-keepalive



and it exists after several seconds with:

Code: Select all
[00:38:27] Started sgminer 5.5.6-ARM-RC1
[00:38:27] * using Jansson 2.7
[00:38:27] Probing for an alive pool
[00:39:27] No servers were found that could be used to get work from.
[00:39:27] Please check the details from the list below of the servers you have input
[00:39:27] Most likely you have input the wrong URL, forgotten to add a port, or have not set up workers
[00:39:27] Pool: 0  URL: stratum+tcp://killallasics.moneroworld.com:3333  User: my_XMR_address  Password: x
[00:39:27] Press any key to exit, or sgminer will try again in 15s.
[00:39:43] No servers were found that could be used to get work from.
[00:39:43] Please check the details from the list below of the servers you have input
[00:39:43] Most likely you have input the wrong URL, forgotten to add a port, or have not set up workers
[00:39:43] Pool: 0  URL: stratum+tcp://killallasics.moneroworld.com:3333  User: my_XMR_address  Password: x
[00:39:43] Press any key to exit, or sgminer will try again in 15s.


Since also cpuminer_multi refuses to run: :

Code: Select all
./test_monero.sh
** cpuminer-multi 1.3.4 by tpruvot@github **
BTC donation address: 1FhDPLPpw18X4srecguG3MxJYe4a1JsZnd (tpruvot)

[2018-04-27 00:43:43] Using JSON-RPC 2.0
[2018-04-27 00:43:43] CPU Supports AES-NI: NO
[2018-04-27 00:43:43] Binding process to cpu mask fe
[2018-04-27 00:43:43] Starting Stratum on stratum+tcp://killallasics.moneroworld.com:3333
[2018-04-27 00:43:43] 7 miner threads started, using 'cryptonight' algorithm.
[2018-04-27 00:43:44] JSON invalid result
[2018-04-27 00:43:44] rpc2_login_decode: fail


were:
Code: Select all
 test_monero.sh
./cpuminer -a cryptonight -o stratum+tcp://killallasics.moneroworld.com:3333 -u my_XMR_address  -p od1 -t 7 --randomize --no-redirect --cpu-affinity 0xFE


I believe it is something in the system.
Any ideas?
odronew
 
Posts: 28
Joined: Tue May 10, 2016 6:06 am
languages_spoken: english, italian, greek
ODROIDs: C2, HC1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby hominoid » Fri Apr 27, 2018 8:47 am

Sgminer seems to indicate it doesn't see a valid server. Any time I've seen that response from sgminer, indeed the url or login was incorrect. cpuminer_multi is indicating the login is incorrect. The url your using seems correct. Is your xmr address a testnet address as required by the testnet pool?

"...You need a testnet address to mine to this pool. Other than that, it should be same as any other pool..."

If you are using a testnet address try the config below. I just tried it with their posted testnet address and had no problems connecting.
Code: Select all
#!/bin/bash
export GPU_FORCE_64BIT_PTR=0
export GPU_USE_SYNC_OBJECTS=1
export GPU_MAX_ALLOC_PERCENT=100
export GPU_SINGLE_ALLOC_PERCENT=100
export GPU_MAX_HEAP_SIZE=100

./sgminer -k cryptonight -o stratum+tcp://killallasics.moneroworld.com:3333 -u 9v4vTVwqZzfjCFyPi7b9Uv1hHntJxycC4XvRyEscqwtq8aycw5xGpTxFyasurgf2KRBfbdAJY4AVcemL1JCegXU4EZfMtaz -p x -I 6 -w 32 -d 0,1 --thread-concurrency 8192 --monero --pool-no-keepalive
hominoid
 
Posts: 186
Joined: Tue Feb 28, 2017 3:55 am
Location: Lake Superior Basin, USA
languages_spoken: english
ODROIDs: C2, XU4, MC1, N1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby wtarreau » Fri Apr 27, 2018 6:29 pm

Note for those short on SD card space, I could remove arm64 and static libs support from the arm_compute archive, shrinking /opt from 5.4 GB to 898 MB this way :

Code: Select all
# tar --exclude='*arm64*' --exclude='*-static.a' -zxf arm_compute-v18.03-bin-linux.tar.gz
wtarreau
 
Posts: 21
Joined: Thu Jan 21, 2016 1:22 am
languages_spoken: english, french
ODROIDs: C2

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby odronew » Sat Apr 28, 2018 2:00 am

hominoid wrote:Sgminer seems to indicate it doesn't see a valid server. Any time I've seen that response from sgminer, indeed the url or login was incorrect. cpuminer_multi is indicating the login is incorrect. The url your using seems correct. Is your xmr address a testnet address as required by the testnet pool?

"...You need a testnet address to mine to this pool. Other than that, it should be same as any other pool..."

If you are using a testnet address try the config below. I just tried it with their posted testnet address and had no problems connecting.
Code: Select all
#!/bin/bash
export GPU_FORCE_64BIT_PTR=0
export GPU_USE_SYNC_OBJECTS=1
export GPU_MAX_ALLOC_PERCENT=100
export GPU_SINGLE_ALLOC_PERCENT=100
export GPU_MAX_HEAP_SIZE=100

./sgminer -k cryptonight -o stratum+tcp://killallasics.moneroworld.com:3333 -u 9v4vTVwqZzfjCFyPi7b9Uv1hHntJxycC4XvRyEscqwtq8aycw5xGpTxFyasurgf2KRBfbdAJY4AVcemL1JCegXU4EZfMtaz -p x -I 6 -w 32 -d 0,1 --thread-concurrency 8192 --monero --pool-no-keepalive



Does not run again but with different output:
Code: Select all
[19:58:23] Started sgminer 5.5.6-ARM-RC1
[19:58:23] * using Jansson 2.7./test_monero.sh: line 9:  1034 Killed                  ./sgminer -k cryptonight -o stratum+tcp://killallasics.moneroworld.com:3333 -u 9v4vTVwqZzfjCFyPi7b9Uv1hHntJxycC4XvRyEscqwtq8aycw5xGpTxFyasurgf2KRBfbdAJY4AVcemL1JCegXU4EZfMtaz -p x -I 6 -w 32 -d 0,1 --thread-concurrency 8192 --monero --pool-no-keepalive
                                                                                                         root@OdroidHC1:~/Data/crypto/sgminer-arm#
odronew
 
Posts: 28
Joined: Tue May 10, 2016 6:06 am
languages_spoken: english, italian, greek
ODROIDs: C2, HC1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby lltKoboldMiningUnion » Thu May 03, 2018 7:46 am

I've made a fresh image of https://wiki.odroid.com/odroid-xu4/os_images/linux/ubuntu_4.14/20171213 and git your fork from https://github.com/hominoids/sgminer-arm.
Everything went well following your instructions here and on github (I did SKIP the "Source Code Edits" as i assumed you committed the change on your git fork.
I've started a live test run on nicehash with lyra2re algo and went to bed leaving it running for an good 8hrs.
I don't have much to offer but i still want to contribute the way i can from my experience, i have average/good linux skill but never 'make'd before.
I have a few years of PHP programming behind me and been 'bash'ing for a little while but have no clue about C.

Notice : they just added a new release yesterday (20180501) night https://wiki.odroid.com/odroid-xu4/os_i ... 4/20180501 but seems like only the mate image is available (at time of writing).

## Before jumping to the results, I had a hard time finind the AMD_APP_SDK since most of the amd web site link are broken but i found one on sourceforge.net if anyone looking for it:
https://sourceforge.net/projects/nicehashsgminerv5viptools/files/APP%20SDK%20A%20Complete%20Development%20Platform/AMD%20APP%20SDK%203.0%20for%2032-bit%20Linux/AMD-APP-SDKInstaller-v3.0.130.136-GA-linux32.tar.bz2/download
## According to google's cached page md5sum should be ab99423b3dfbb5ea1969b9c8854f7a70 :
https://webcache.googleusercontent.com/search?q=cache%3AUxGKO0L94SkJ%3Ahttps%3A%2F%2Fdeveloper.amd.com%2Famd-accelerated-parallel-processing-app-sdk%2Fsystem-requirements-driver-compatibility%2F%20&cd=2&hl=en&ct=clnk&gl=ca&client=firefox-b
## I've simply downloaded, checksumed, extracted, scp'ed and run the .sh file. I've personnaly installed it as root in the default /opt location.
## I've also stripped the ComputeLibrary down to 563mb by removing the documentation/, examples/ and arm64 related files and foldes.
## In addition to the dependecies you have on the git page i also had --- build-essential cmake git g++ hugepages libhwloc-dev libmicrohttpd-dev make --- packages installed if any of them matters.

:arrow: MY RESULTS (lyra2re on nicehash) ===================================
https://github.com/tpruvot/cpuminer-multi give me a steady 60kH/s and a regular accepted shared using these options:
Code: Select all
-t 7 --randomize --no-redirect --cpu-affinity 254 -R 30 -T 60

NOTE: (-R (retry) and -T (timeout) significaly dropped the disconnection error on my not-so-fast (10mb) cable connection)
Code: Select all
[2018-05-02 18:42:09] accepted: 44/44 (diff 0.016), 60.42 kH/s yes!
[2018-05-02 18:44:44] accepted: 45/45 (diff 0.008), 60.56 kH/s yes!
[2018-05-02 18:58:51] accepted: 46/46 (diff 0.075), 59.56 kH/s yes!
[2018-05-02 19:01:07] accepted: 47/47 (diff 0.015), 60.52 kH/s yes!
[2018-05-02 19:07:36] accepted: 48/48 (diff 0.019), 59.15 kH/s yes!
[2018-05-02 19:07:59] accepted: 49/49 (diff 0.060), 62.14 kH/s yes!
[2018-05-02 19:09:36] accepted: 50/50 (diff 0.007), 60.11 kH/s yes!
[2018-05-02 19:17:05] accepted: 51/51 (diff 0.071), 60.87 kH/s yes!
[2018-05-02 19:22:13] accepted: 52/52 (diff 0.076), 60.22 kH/s yes!
[2018-05-02 19:25:40] accepted: 53/53 (diff 0.008), 60.40 kH/s yes!


:ugeek: my CPU affinity learning curve ==============
I had a hard time figuring out how the cpu affinity mask works (I've learn cpu mask existed like 48hrs ago :P) but this seems to work.
The `Binding thread X to cpu mask 0` confuse me. Here an sample output with -D (debug) option:
Code: Select all
[2018-05-02 20:42:09] Binding process to cpu mask fe
[2018-05-02 20:42:09] Starting Stratum on stratum+tcp://lyra2re.usa.nicehash.com:3342
[2018-05-02 20:42:09] Binding thread 0 to cpu mask 0
[2018-05-02 20:42:09] Binding thread 1 to cpu mask 0
[2018-05-02 20:42:09] Binding thread 2 to cpu mask 0
[2018-05-02 20:42:09] Binding thread 3 to cpu mask 0
[2018-05-02 20:42:09] Binding thread 4 to cpu mask 0
[2018-05-02 20:42:09] Binding thread 5 to cpu mask 0
[2018-05-02 20:42:09] 7 miner threads started, using 'lyra2re' algorithm.
[2018-05-02 20:42:09] Binding thread 6 to cpu mask 0
[2018-05-02 20:42:10] DEBUG: job_id='00000034fd85f2b9' extranonce2=000000 ntime=5aea2229
[2018-05-02 20:42:10] Stratum difficulty set to 1.6 (0.01250)
[2018-05-02 20:42:10] lyra2re block 2960401, diff 2.098

The hash rate makes me believe it is using 4 big core and 3 small (as expected from 254 or 0xFE ). Anyone can confirm or have a better/proper way of doing this?
Code: Select all
[2018-05-02 20:42:16] CPU #0: 12.01 kH/s
[2018-05-02 20:42:16] CPU #3: 12.03 kH/s
[2018-05-02 20:42:16] CPU #2: 12.01 kH/s
[2018-05-02 20:42:16] CPU #1: 11.87 kH/s
[2018-05-02 20:42:19] DEBUG: job_id='00000034fd85f2cc' extranonce2=000000 ntime=5aea2242
[2018-05-02 20:42:19] CPU #4: 5.20 kH/s
[2018-05-02 20:42:19] CPU #5: 5.18 kH/s
[2018-05-02 20:42:19] CPU #6: 5.18 kH/s
[2018-05-02 20:42:34] DEBUG: job_id='00000034fd85f36a' extranonce2=000000 ntime=5aea2252


:twisted: GPU mining tweak (lyra2re on nicehash) ================
As for https://github.com/hominoids/sgminer-arm i get share accepted every 20 minute or so and both GPUs get accepted shared. (here a lucky example ;) )
Code: Select all
[19:18:19] Accepted 52ef97af Diff 1.543/0.800 GPU 1
[19:18:39] Accepted 8678dda5 Diff 0.952/0.800 GPU 0

Seems like each GPU has it own soft-spot for intensity, notice how GPU0 jumps from 9kH/s@(-I 7) to 13kH/s@(-I 8) and back down to 6kH/s@(-I 9).
Since i saw somewhere that each GPU is different i wonder if we can get better result by doing the same with -w and --thread-concurrency. Gonna have to do more benchmark tonight.
Code: Select all
#args="--extranonce -I 23 -w 32 --thread-concurrency 8192"   #0/0H #gpu init fail
#args="--extranonce -I 23 -w 64 --thread-concurrency 8192"   #0/0H #gpu init fail
#args="--extranonce -I 31 -w 128 --thread-concurrency 8192" #0/0H #gpu init fail
#args="--extranonce -I 14 -w 64 --thread-concurrency 8192"   #7/8H=15H
#args="--extranonce -I 15 -w 64 --thread-concurrency 8192"   #6/8K=14K
#args="--extranonce -I 18 -w 64 --thread-concurrency 8192"   #5/7K=12K
#args="--extranonce -I 13 -w 64 --thread-concurrency 8192"   #8/9K=15k
#args="--extranonce -I 8 -w 64 --thread-concurrency 8192"     #12/6K=18k
#args="--extranonce -I 7,12 -w 64 --thread-concurrency 8192" #9/6K=15k
#args="--extranonce -I 9,13 -w 64 --thread-concurrency 8192" #6/9K=15k
#args="--extranonce -I 8,13 -w 64 --thread-concurrency 8192" #13/4K=17k
#args="--extranonce -I 8,14 -w 64 --thread-concurrency 8192" #13/7K=20k
#args="--extranonce -I 8,15 -w 64 --thread-concurrency 8192" #12/9K=21k
args="--extranonce -I 8,16 -w 64 --thread-concurrency 8192"   #13/9K=22k #peak13/10=23


:?: Hugepages Kernel Build (please) ===================
Note that i've installed the hugepages packages but i still think they are not used as i never compiled a kernel, nor know how. If someone could point me where i can learn to build the Odroid kernel with hugepages enabled i would appreciate it.
Code: Select all
# grep Hugepagesize /proc/meminfo
# sysctl -w vm.nr_hugepages=512
sysctl: cannot stat /proc/sys/vm/nr_hugepages: No such file or directory
.


:oops: Summer is coming =============================
The only real concern so far is the thermal zones. I'Ve made a little watch script to cat /sys/devices/virtual/thermal/thermal_zone([0-4])i/temp" and /sys/devices/system/cpu/cpu([0-7])/cpufreq/scaling_cur_freq
Should i be concerned, seems high compared to my desktop Intel i3 :D (but seriously what is the threshold for these little monster?) The system is throttling down but i was expecting that somehow.
I mean it feels hot to the touch but i could hold it in my hand without burning myself. I have a cpu fan blowing on it just like if it was stacked with 3 other. (the higher value is the reported temp * 9 / 5 - 32, First value is the average).

Code: Select all
## 5 ZONES : (avg) 172F / 78C : 179/82 165/74 177/81 183/84 163/73
## 8 CORES : (avg) 1600 mhz :  1500 1500 1500 1500 1700 1700 1700 1700


I truely want to thank you for this thread. I barely made 0.000002 btc but it was entertaining as hell. Also it is nice to know that you can actually get result with a 45$ computer, 20w powersupply, 10mb Internet and free open-source software.
Best regards,
llt


:cry: SGMINER-GM build error on cryptonight ===============
sgminer-gm, it breaks at compiling the crypto7, I have NO experience with C so hard for me to debug, if anyone interested here the failure.. Opencl is installed and the sdk as well. (aka everything works above and it still fails here)
Code: Select all
 
cp -R /opt/AMDAPPSDK-3.0/include ADL_SDK/
git submodule init
git submodule update
autoreconf -fi
CFLAGS="-Os -Wall -march=native -std=gnu99 -mfpu=neon" LDFLAGS="-L/usr/lib/arm_compute-v18.03-bin-linux/lib/linux-armv7a-neon-cl" ./configure --disable-git-version --disable-adl --disable-adl-checks --prefix=/opt/sgminer #error: imposible constraint in 'asm'
make

Code: Select all
 
CC       algorithm/sgminer-cryptonight.o
algorithm/cryptonight.c: In function 'cryptonight':
algorithm/cryptonight.c:213:24: warning: passing argument 2 of 'CNKeccak' from incompatible pointer type [-Wincompatible-pointer-types]
  CNKeccak(CNCtx.State, Input, Length);
                        ^
algorithm/cryptonight.c:130:6: note: expected 'uint64_t * {aka long long unsigned int *}' but argument is of type 'uint8_t * {aka unsigned char *}'
 void CNKeccak(uint64_t *output, uint64_t *input, uint32_t Length)
      ^
algorithm/cryptonight.c:229:19: warning: passing argument 1 of 'CNAESTransform' from incompatible pointer type [-Wincompatible-pointer-types]
    CNAESTransform(text + (j << 1), ExpandedKey1);
                   ^
algorithm/cryptonight.c:183:6: note: expected 'uint32_t * {aka unsigned int *}' but argument is of type 'uint64_t * {aka long long unsigned int *}'
 void CNAESTransform(uint32_t *X, const uint32_t *Key)
      ^
algorithm/cryptonight.c:245:12: warning: passing argument 1 of 'CNAESRnd' from incompatible pointer type [-Wincompatible-pointer-types]
   CNAESRnd(c, a);
            ^
algorithm/cryptonight.c:171:6: note: expected 'uint32_t * {aka unsigned int *}' but argument is of type 'uint64_t * {aka long long unsigned int *}'
 void CNAESRnd(uint32_t *X, const uint32_t *key)
      ^
algorithm/cryptonight.c:245:15: warning: passing argument 2 of 'CNAESRnd' from incompatible pointer type [-Wincompatible-pointer-types]
   CNAESRnd(c, a);
               ^
algorithm/cryptonight.c:171:6: note: expected 'const uint32_t * {aka const unsigned int *}' but argument is of type 'uint64_t * {aka long long unsigned int *}'
 void CNAESRnd(uint32_t *X, const uint32_t *key)
      ^
algorithm/cryptonight.c:279:19: warning: passing argument 1 of 'CNAESTransform' from incompatible pointer type [-Wincompatible-pointer-types]
    CNAESTransform(text + (j << 1), ExpandedKey2);
                   ^
algorithm/cryptonight.c:183:6: note: expected 'uint32_t * {aka unsigned int *}' but argument is of type 'uint64_t * {aka long long unsigned int *}'
 void CNAESTransform(uint32_t *X, const uint32_t *Key)
      ^
algorithm/cryptonight.c: In function 'cryptonight_regenhash':
algorithm/cryptonight.c:333:14: warning: passing argument 1 of 'cryptonight' from incompatible pointer type [-Wincompatible-pointer-types]
  cryptonight(ohash, data, work->XMRBlobLen, variant);
              ^
algorithm/cryptonight.c:207:6: note: expected 'uint8_t * {aka unsigned char *}' but argument is of type 'uint32_t * {aka unsigned int *}'
 void cryptonight(uint8_t *Output, uint8_t *Input, uint32_t Length, int Variant)
      ^
algorithm/cryptonight.c:333:21: warning: passing argument 2 of 'cryptonight' from incompatible pointer type [-Wincompatible-pointer-types]
  cryptonight(ohash, data, work->XMRBlobLen, variant);
                     ^
algorithm/cryptonight.c:207:6: note: expected 'uint8_t * {aka unsigned char *}' but argument is of type 'uint32_t * {aka unsigned int *}'
 void cryptonight(uint8_t *Output, uint8_t *Input, uint32_t Length, int Variant)
      ^
algorithm/cryptonight.c: In function 'cryptonight':
algorithm/cryptonight.c:159:2: error: impossible constraint in 'asm'
  __asm__("mul %%rdx":
  ^
Makefile:1664: recipe for target 'algorithm/sgminer-cryptonight.o' failed
make[2]: *** [algorithm/sgminer-cryptonight.o] Error 1
make[2]: Leaving directory '/home/kobold/miners-odroidMC1/sgminer-gm'
Makefile:1721: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/kobold/miners-odroidMC1/sgminer-gm'
Makefile:663: recipe for target 'all' failed
make: *** [all] Error 2
lltKoboldMiningUnion
 
Posts: 4
Joined: Thu May 03, 2018 4:48 am
languages_spoken: english
ODROIDs: MC1

Succefully recompiled kernel with Hugepages (as far as i kno

Unread postby lltKoboldMiningUnion » Tue May 08, 2018 4:51 am

I've wrote all the steps i took to have the kernel running hugepages, seems to work. Feel free to add/remove/modify/share this post anyway you want.
This is pretty much raw command i pasted in a dummy sh file, It is not meant to be ran as a script but i rather copy/paste the commands. Sure there is a way to mkae it noob proof but i think this qualify as an 'don't go there if you don't know what you are doing' zone.

Will post results later on, tell me if i'm hijacking your thread but i think this is more of an 'addition' to your original post than a 'fork' :P
It's all thanks to you if i got this far. Best regards,
llt

#!/bin/bash
exit; #Not meant to be runned as a script by itself.

### 1. Download latest image from https://dn.odroid.com/5422/ODROID-XU3/Ubuntu/
Code: Select all
# wget https://dn.odroid.com/5422/ODROID-XU3/Ubuntu/ubuntu-16.04.3-4.14-minimal-odroid-xu4-20171213.img.xz -O ubuntu-odroidMC1.img.xz
# wget https://dn.odroid.com/5422/ODROID-XU3/Ubuntu/ubuntu-16.04.3-4.14-minimal-odroid-xu4-20171213.img.xz.md5sum -O ubuntu-odroidMC1.img.xz.md5sum
# checksum
# extract
# checksum
# wirte image to card
# Unmount card and insert it in device


### 2. Power un the device for first boot
# wait 2-3 minutes for resizefs ro expand rootfs
# when blue light goes off, unplug and replug the device

### 3. Setup ssh to the device
Code: Select all
ssh-copy-id root@DEVICE_IP
ssh root@DEVICE_IP


# 4. Prepare Ubuntu
Code: Select all
nano /etc/apt/sources.list.d/saiarcot895-ubuntu-myppa-xenial.list # What is this ppa and who is this guy?
nano /etc/hostname    #set your hostname
nano /etc/hosts      #change odroid to your new hostname


# 5. Typical update | see https://wiki.odroid.com/odroid-xu4/os_i ... 4/20171213
# IF you get the following error, check top for unattended updates running in the background.
# E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
# E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?

# If you want to disable unattended upgrades | see https://askubuntu.com/questions/953779/ ... d-upgrades
Code: Select all
sudo apt-get update
sudo apt-get -y upgrade
sudo apt-get -y dist-upgrade
sudo apt-get -y install linux-image-xu3
sudo reboot now


# 6.SSH back in the device for Kernel hugepages rebuild | see https://wiki.odroid.com/odroid-xu4/os_i ... 4/20180501
Code: Select all
sudo apt-get install git gcc g++ build-essential libncurses5-dev bc libssl-dev   #added bc and libssl-dev based on errors i got
git clone --depth 1 https://github.com/hardkernel/linux -b odroidxu4-4.14.y
cd linux

# 6.1 ENALBE CONFIG_ARM_LPAE to see hugepages in menuconfig | see viewtopic.php?f=146&t=28992
Code: Select all
nano .config    # Press CTRL-w and search for LPAE


# 6.2 using menuconfig to enable huge page, transparent huge page and/or hugepagefs
Code: Select all
make menuconfig  # press / to do a search : huge
# HUGETLBFS -> File systems -> Pseudo filesystems
# TRANSPARENT_HUGEPAGE -> Kernel Features
# TRANSPARENT_HUGEPAGE_ALWAYS -> Kernel Features -> Transparent Hugepage Support -> sysfs defaults


# 6.2 Rebuild the kernel. # took way over 1 hrs with 8 thread,
Code: Select all
make -j8 #$(nproc)   
make modules_install
sudo cp -f arch/arm/boot/zImage /media/boot
sudo cp -f arch/arm/boot/dts/exynos5422-odroid*dtb /media/boot
sync


# 6.2.1 Updating root ramdisk (Optional)
Code: Select all
sudo cp .config /boot/config-`make kernelrelease`
sudo update-initramfs -c -k `make kernelrelease`
sudo mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n uInitrd -d /boot/initrd.img-`make kernelrelease` /boot/uInitrd-`make kernelrelease`
sudo cp /boot/uInitrd-`make kernelrelease` /media/boot/uInitrd


# You would check all necessary files are in place as below before reboot. The file size would differ.
Code: Select all
ls -l /media/boot/

#total 14756
#-rwxr-xr-x 1 root root 9536 Oct 25 23:29 boot.ini
#-rwxr-xr-x 1 root root 753 Aug 20 22:38 boot.ini.default
#-rwxr-xr-x 1 root root 62565 Nov 2 01:24 exynos5422-odroidxu3.dtb
#-rwxr-xr-x 1 root root 61814 Nov 2 01:24 exynos5422-odroidxu3-lite.dtb
#-rwxr-xr-x 1 root root 62225 Nov 2 01:24 exynos5422-odroidxu4.dtb
#-rwxr-xr-x 1 root root 61714 Oct 25 23:30 exynos5422-odroidxu4-kvm.dtb
#-rwxr-xr-x 1 root root 9996513 Nov 2 01:27 uInitrd
#-rwxr-xr-x 1 root root 4844744 Nov 2 01:24 zImage


Code: Select all
sudo sync
sudo reboot


# 7 Reconnect to the device and setup hugepage
Code: Select all
ssh root@DEVICE IP
sysctl -w vm.nr_hugepages=512
cat /proc/meminfo

# HugePages_Total: 512
# HugePages_Free: 512
# HugePages_Rsvd: 0
# HugePages_Surp: 0
# Hugepagesize: 2048 kB


# 8 Last apt-get run to mae sure everything is up to date.
Code: Select all
sudo apt-get update
sudo apt-get -y upgrade
sudo apt-get -y dist-upgrade
sudo apt-get -y autoremove
sudo apt-get -y autoclean
sudo shutdown


#Remove the sdcard and make a backup image for later reuse ;)
lltKoboldMiningUnion
 
Posts: 4
Joined: Thu May 03, 2018 4:48 am
languages_spoken: english
ODROIDs: MC1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby Phoenixkonsole » Sun May 13, 2018 9:53 am

Hi,

does this miner support x16r ?
And should it be possible to miner monerov7? I can't : ) But perhaps it is a problem with my firewall.
Phoenixkonsole
 
Posts: 79
Joined: Sun Jun 22, 2014 11:38 pm
languages_spoken: english
ODROIDs: U3

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby hominoid » Mon May 14, 2018 9:28 am

Phoenixkonsole wrote:Hi,

does this miner support x16r ?
And should it be possible to miner monerov7? I can't : ) But perhaps it is a problem with my firewall.


It does not support x16r. I have not been mining lately but It should be working with Monero v7.
hominoid
 
Posts: 186
Joined: Tue Feb 28, 2017 3:55 am
Location: Lake Superior Basin, USA
languages_spoken: english
ODROIDs: C2, XU4, MC1, N1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby fxsecltd » Mon May 28, 2018 3:06 am

hominoid wrote:
rooted wrote:How long did it take to make that $10?

Awesome that GPU acceleration is enabled and actually functional.

I can't say because I only use this account for testing occasionally. The shares from the recent 12hr test haven't all matured yet either. But here is the real irony for me; while testing this weekend on sgminer-5.5.5a-arm, I found a block with in the first 10 minutes of one of the tests. Monero block reward is a little over 5 coins, at recent pricing in the $250 range per coin... :o
I really need to setup for solo mining when I do this stuff!
Cryptonight Test 1hrs Block Found.png


Really, my time for block finding from 48 minutes to 23 hours (with 8 hours finding once).
I tested latest version of miner on several XMR pools with solo mining enabled - however, no one can recognize it (Found block for ... BLOCK!) as block solution. After external pool testing, I made test VDS with monero node and monero-stratum pool server. I've tried solo mining, but monero-stratum pool can not recognize found share as block solution (if recognizes, it submit work to node), is it stratum based error, or miner difficulty calculation defect?
fxsecltd
 
Posts: 2
Joined: Mon May 28, 2018 2:01 am
languages_spoken: english
ODROIDs: XU4 MC1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby hominoid » Mon May 28, 2018 5:52 am

fxsecltd wrote:
hominoid wrote:
rooted wrote:How long did it take to make that $10?

Awesome that GPU acceleration is enabled and actually functional.

I can't say because I only use this account for testing occasionally. The shares from the recent 12hr test haven't all matured yet either. But here is the real irony for me; while testing this weekend on sgminer-5.5.5a-arm, I found a block with in the first 10 minutes of one of the tests. Monero block reward is a little over 5 coins, at recent pricing in the $250 range per coin... :o
I really need to setup for solo mining when I do this stuff!
Cryptonight Test 1hrs Block Found.png


Really, my time for block finding from 48 minutes to 23 hours (with 8 hours finding once).
I tested latest version of miner on several XMR pools with solo mining enabled - however, no one can recognize it (Found block for ... BLOCK!) as block solution. After external pool testing, I made test VDS with monero node and monero-stratum pool server. I've tried solo mining, but monero-stratum pool can not recognize found share as block solution (if recognizes, it submit work to node), is it stratum based error, or miner difficulty calculation defect?

I don't understand everything your saying but I gather your trying to solo mine XMR with sgminer?? I have never solo mined XMR but I don't think any version of sgminer supports solo mining XMR. Looking at the documentation it looks like it only supports pool mining. I was pool mining XMR when I found that block during GPU testing, not solo mining. I had been dual CPU//GPU testing other software and coins so my comment "I really need to setup for solo mining when I do this stuff!" was meant more as a general statement to maybe solo mine when I can. I have always pool mined during testing because it is generally much quicker and easier to setup. No block-chain to download or sync. While dual CPU/GPU mining some CPU mining software may be able to solo mine XMR but I don't believe sgminer can. Didn't mean to mislead anyone.
hominoid
 
Posts: 186
Joined: Tue Feb 28, 2017 3:55 am
Location: Lake Superior Basin, USA
languages_spoken: english
ODROIDs: C2, XU4, MC1, N1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby fxsecltd » Mon May 28, 2018 9:23 am

Thank you for your answer! In my comment I mean: - if miner detected bliock, it must be detected as block (not simple share) at pool, but in my testing environment miner detects block, sends it to pool, but pool did not detected found share as block - instead, it stores result as share without submit to node. If so, block detection code at miner side may be not equal with block detection code at pool side. So, it can be caused by wrong block detection code at miner side.
fxsecltd
 
Posts: 2
Joined: Mon May 28, 2018 2:01 am
languages_spoken: english
ODROIDs: XU4 MC1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby hominoid » Tue May 29, 2018 1:48 pm

fxsecltd wrote:Thank you for your answer! In my comment I mean: - if miner detected bliock, it must be detected as block (not simple share) at pool, but in my testing environment miner detects block, sends it to pool, but pool did not detected found share as block - instead, it stores result as share without submit to node. If so, block detection code at miner side may be not equal with block detection code at pool side. So, it can be caused by wrong block detection code at miner side.

What your saying does not make technical sense to me for these reasons:

Stratum servers are only used for pools and pool mining.

Getwork is generally used (by the coins I have solo mined) for solo mining on their respective block chains. A stratum server is not used nor necessary when solo mining; It would have no purpose.

sgminer does not support Getwork only Stratum connections and therefore can only pool mine coins (as far as I can tell). Like I said earlier not all multi-coin mining software supports solo mining a given coin.

I know some pool operators have setup "solo mining ports" but as far as I know you still have to use mining software that supports the underlying block chain work distribution protocol for the coin e.g. Getwork or whatever it is, not a stratum server. Since sgminer only supports stratum connections the pool correctly sees them as submitted shares not blocks. Because they are stratum shares, which are different then blocks on the block chain and are not interchangeable, they would not be recognized by the other block chain nodes as valid if they were submitted. I hope this information helps.
hominoid
 
Posts: 186
Joined: Tue Feb 28, 2017 3:55 am
Location: Lake Superior Basin, USA
languages_spoken: english
ODROIDs: C2, XU4, MC1, N1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby lltKoboldMiningUnion » Sun Jun 10, 2018 2:22 am

hominoid wrote:
fxsecltd wrote:Thank you for your answer! In my comment I mean: - if miner detected bliock, it must be detected as block (not simple share) at pool, but in my testing environment miner detects block, sends it to pool, but pool did not detected found share as block - instead, it stores result as share without submit to node. If so, block detection code at miner side may be not equal with block detection code at pool side. So, it can be caused by wrong block detection code at miner side.

What your saying does not make technical sense to me for these reasons:

Stratum servers are only used for pools and pool mining.

Getwork is generally used (by the coins I have solo mined) for solo mining on their respective block chains. A stratum server is not used nor necessary when solo mining; It would have no purpose.

sgminer does not support Getwork only Stratum connections and therefore can only pool mine coins (as far as I can tell). Like I said earlier not all multi-coin mining software supports solo mining a given coin.

I know some pool operators have setup "solo mining ports" but as far as I know you still have to use mining software that supports the underlying block chain work distribution protocol for the coin e.g. Getwork or whatever it is, not a stratum server. Since sgminer only supports stratum connections the pool correctly sees them as submitted shares not blocks. Because they are stratum shares, which are different then blocks on the block chain and are not interchangeable, they would not be recognized by the other block chain nodes as valid if they were submitted. I hope this information helps.


I think we are here to learn so let me ask you a question, Do you think i wold be possible to use a mining proxy (somewhat like https://github.com/xmrig/xmrig-proxy) to send the sgminer shares to it a then get the proxy handle the getWork?.

Just a brainstorm, i haven'T experienced proxy yet.
lltKoboldMiningUnion
 
Posts: 4
Joined: Thu May 03, 2018 4:48 am
languages_spoken: english
ODROIDs: MC1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby lltKoboldMiningUnion » Sun Jun 10, 2018 2:47 am

I've been playing with my MC1 for about a month here.
Here sme observation i made that might help trouble shoot some stuff.
If someone can confirm the same results would be nice to know.
If it helps somene, well good

- sgminer, I got rid of the 'share above target' on XMR if set -w 32 down from -w 64.
- sgminer: If both GPU run at the same hash rate you can probably raise the intesity.
- sgminer if hashrate goes into a rollercoaster ride of +/- 10% you probably need to lower your intensity or worksize for that particular gpu.

- xmrig: Was getting alot of Rejected untracked stratum share from xmr.pool.minergate.com and got of them by adding the --pool-no-keepalive option. (i just don't mine minergate anymore)

i'Ve notice some algo works better with --rawintensity. Like if i put -I 4 on monero both gpu fails, but if i set --rawintensity it works flawlessly.

Anyone noticed the --shaders option on 5.5.6? I've came to the conclusion that you need to specify the per-unit shaders, in our case --shaders 64 works best. I've tried --shaders 256,128 and gpu 0 was rollercoasting hashrate. Once i've set a single value of 64, both hash rate went up and stabilised. You can use this instead of --thread-conccurency, it will do the maths for you.,

To tweak sgminer, here how i do it:
1. I set thw intensity or raw intensity to a low value, -I 4 or --rawintensity 128 to adjust the worksize.
2. Most common -w that worked for me was in the power of 2 (4, 8, 16, 32, 64). Above 64 the hashrate start to go down significaly on most alog i'Ve tried so i start at 64 and divide by 2 until the GPU's actually starts.
3. From there i bring up the intesity until GPU0 start to have higher hash rate than GPU1, from there i know GPU1 has capped his 2 units and keep trying higer values for gpu0 by comma separating the vlues -I 10,9.
4. On i see the hash rate of GPU0 stop raising i know i've capped the intensity.
5. From there i leave it run for an hours or so and check for stale, above share etc (see troubleshoot above).
6. I often need to bring worksize, intensity or rawintesity a one notch down to get optimal accepted share. You'll try to aim so a stable hashrate with an higher value on GPU0 that GPU1. i've never actually got to the point were GPU0 has twice the hashrate of GPU1 but you should get about 150% more. (ei on Lyra2rev2 i get 43 and 25, on xmr i get 12 and 8)

I get more from pools with a lower but stable hashrate that having a high hashrate and lots of hardware erro (HW). Use the 'quality over quatity' analogy here.

Really hope this can help people have more fun mining. be safe y'all and thanks again to hominoid for this thread.
lltKoboldMiningUnion
 
Posts: 4
Joined: Thu May 03, 2018 4:48 am
languages_spoken: english
ODROIDs: MC1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby hominoid » Mon Jun 11, 2018 8:01 am

Thanks for sharing your tuning approach and sgminer-arm experience. I have found similar metrics and results with some variance based on the algo used and whether dual CPU/GPU mining. Each coin will be different but the procedure is sound to zero in on a good set of tuned values. As I'm sure you realized, one can spend a lot of time tuning. I'm glad your having a good time messing around with it. :)
hominoid
 
Posts: 186
Joined: Tue Feb 28, 2017 3:55 am
Location: Lake Superior Basin, USA
languages_spoken: english
ODROIDs: C2, XU4, MC1, N1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby hominoid » Tue Jun 12, 2018 5:19 am

lltKoboldMiningUnion wrote:
hominoid wrote:
fxsecltd wrote:Thank you for your answer! In my comment I mean: - if miner detected bliock, it must be detected as block (not simple share) at pool, but in my testing environment miner detects block, sends it to pool, but pool did not detected found share as block - instead, it stores result as share without submit to node. If so, block detection code at miner side may be not equal with block detection code at pool side. So, it can be caused by wrong block detection code at miner side.

What your saying does not make technical sense to me for these reasons:

Stratum servers are only used for pools and pool mining.

Getwork is generally used (by the coins I have solo mined) for solo mining on their respective block chains. A stratum server is not used nor necessary when solo mining; It would have no purpose.

sgminer does not support Getwork only Stratum connections and therefore can only pool mine coins (as far as I can tell). Like I said earlier not all multi-coin mining software supports solo mining a given coin.

I know some pool operators have setup "solo mining ports" but as far as I know you still have to use mining software that supports the underlying block chain work distribution protocol for the coin e.g. Getwork or whatever it is, not a stratum server. Since sgminer only supports stratum connections the pool correctly sees them as submitted shares not blocks. Because they are stratum shares, which are different then blocks on the block chain and are not interchangeable, they would not be recognized by the other block chain nodes as valid if they were submitted. I hope this information helps.


I think we are here to learn so let me ask you a question, Do you think i wold be possible to use a mining proxy (somewhat like https://github.com/xmrig/xmrig-proxy) to send the sgminer shares to it a then get the proxy handle the getWork?.

Just a brainstorm, i haven'T experienced proxy yet.


It looks like the mining proxy is for stratum only so I don't think it would work for solo mining without a lot of additional coding. But, what your describing is a pool. By just setting up your own private pool you can accomplish what your asking about. Query the internet, there are several guides out there on setting up a private pool. For example...
hominoid
 
Posts: 186
Joined: Tue Feb 28, 2017 3:55 am
Location: Lake Superior Basin, USA
languages_spoken: english
ODROIDs: C2, XU4, MC1, N1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby brad » Thu Aug 23, 2018 11:02 am

Thanks for posting your work I got sgminer running cryptonight on my N1 :) Im playing (learning) with an unnamed coin which is using an odd cryptonight algorithm

I have 1 question it is only showing 1 GPU does the N1 have 2 like XU4? N1 has 3 cores would they all be included in GPU0 stats?

sqminer config options I used for the N1 (gcc-8)

Code: Select all
CFLAGS="-Os -Wall -mcpu=cortex-a72.cortex-a53+crypto -I/media/test/arm_compute-v18.03-bin-linux/include/CL" LDFLAGS="-L/media/test/arm_compute-v18.03-bin-linux/lib/linux-armv64-v8a-neon-cl" ./configure


Code: Select all
------------------------------------------------------------------------
sgminer 5.5.6-ARM-RC1
------------------------------------------------------------------------


Configuration Options Summary:

  Use git version......: yes
  libcurl(GBT+getwork).: Enabled: -lcurl
  curses.TUI...........: FOUND: -lncurses
  OpenCL...............: FOUND. GPU mining support enabled
  ADL..................: SDK NOT found, GPU monitoring support DISABLED

Compilation............: make (or gmake)
  CPPFLAGS.............:
  CFLAGS...............: -Os -Wall -mcpu=cortex-a72.cortex-a53+crypto -I/media/test/arm_compute-v18.03-bin-linux/include/CL
  LDFLAGS..............: -L/media/test/arm_compute-v18.03-bin-linux/lib/linux-armv64-v8a-neon-cl -lpthread
  LDADD................:  -lcurl submodules/jansson/src/.libs/libjansson.a -lpthread -lOpenCL    -lm -lrt

Installation...........: make install (as root if needed, with 'su' or 'sudo')
  prefix...............: /usr/local


Verbose startup with no environment variables set...
Code: Select all
[11:19:15] Started sgminer 5.5.6-ARM-RC1
[11:19:15] * using Jansson 2.7
[11:19:15] CL Platform vendor: ARM
[11:19:15] CL Platform name: ARM Platform
[11:19:15] CL Platform version: OpenCL 1.2 v1.r14p0-01rel0-git(966ed26).1adba2a645140567eac3a1adfc8dc25d
[11:19:15] Platform devices: 1
[11:19:15]      0       Mali-T860
[11:19:15] Failed to open hwmon directory /sys/bus/pci/devices/0000:ff:ff.ff/hwmon for GPU0
[11:19:15] Failed to open hwmon directory /sys/class/drm/card0/device/hwmon for GPU0
[11:19:15] Default Devices = all
[11:19:15] set_devices(all)
[11:19:15] GPU 0 Thread Concurrency set to 8192.
[11:19:15] GPU 0 Worksize set to 32.
[11:19:15] Loading settings from default_profile for pool 0
[11:19:15] Pool 0 Algorithm set to "cryptonight"
[11:19:15] Pool 0 devices set to "all"
[11:19:15] Pool 0 lookup gap set to "(null)"
[11:19:15] Pool 0 Intensity set to "8"
[11:19:15] Pool 0 Thread Concurrency set to "8192"
[11:19:15] Pool 0 GPU Clock set to "(null)"
[11:19:15] Pool 0 GPU Memory clock set to "(null)"
[11:19:15] Pool 0 GPU Threads set to "(null)"
[11:19:15] Pool 0 GPU Fan set to "(null)"
[11:19:15] Pool 0 GPU Powertune set to "(null)"
[11:19:15] Pool 0 GPU Vddc set to "(null)"
[11:19:15] Pool 0 Shaders set to "(null)"
[11:19:15] Pool 0 Worksize set to "32"
[11:19:15] WARNING: GPU_MAX_ALLOC_PERCENT is not specified!
[11:19:15] WARNING: GPU_USE_SYNC_OBJECTS is not specified!


Code: Select all
sgminer 5.5.6-ARM-RC1 - Started: [2018-08-23 11:22:23] - [0 days 00:01:36]
--------------------------------------------------------------------------------
(5s):38.99 (avg):34.62h/s | A:0  R:0  HW:0  WU:0.000/m
ST: 2  SS: 0  NB: 1  LW: 86  GF: 0  RF: 0
Connected to ************** (stratum) diff  as user 1***************************************
Block: 0000000...  Diff:  Started: [11:22:23]  Best share: 0
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0:                |  35.70/ 34.62h/s | R:  0.0% HW:0 WU:0.000/m I: 8
--------------------------------------------------------------------------------


I also have have cpuminer-multi running (tpruvot version) with some hacks for a different variant of cryptonight and some aarch64 specifics for the N1. I want to optimise some of the code by including an option for using aarch64 neon crypto extensions. Next N2 should have them too and maybe bigger aarch CPU/Mali GPU's

With cpuminer im getting just over 20H/s mining cryptonight on CPU and via sgminer 35H/s on the Mali T860 GPU. In comparison my old Pentium i5 can pull just over 60H/s on CPU maxing out 4 cores but uses much more energy (You can use it as a heater )
brad
 
Posts: 708
Joined: Tue Mar 29, 2016 1:22 pm
Location: Australia
languages_spoken: english
ODROIDs: C2

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby hominoid » Fri Aug 24, 2018 12:25 am

brad wrote:Thanks for posting your work I got sgminer running cryptonight on my N1 :) Im playing (learning) with an unnamed coin which is using an odd cryptonight algorithm

I have 1 question it is only showing 1 GPU does the N1 have 2 like XU4? N1 has 3 cores would they all be included in GPU0 stats?

Your are correct. All the GPU cores for the N1 show up as a single GPU device.

brad wrote:I also have have cpuminer-multi running (tpruvot version) with some hacks for a different variant of cryptonight and some aarch64 specifics for the N1. I want to optimise some of the code by including an option for using aarch64 neon crypto extensions. Next N2 should have them too and maybe bigger aarch CPU/Mali GPU's

That's great, please share in the future if your so inclined. For the GPU and sgminer-arm, one of the main optimizations for Cryptonight that I removed was in algorithm/cryptonight.c lines 163-186.
static inline uint64_t mul128(uint64_t multiplier, uint64_t multiplicand, uint64_t* product_hi)

It was INTEL assembler that I replaced with some C code. Replacing it with ARM assembler would most likely be the quickest way to gain a significant performance increase for the GPU and Cryptonight algo.

brad wrote:With cpuminer im getting just over 20H/s mining cryptonight on CPU and via sgminer 35H/s on the Mali T860 GPU. In comparison my old Pentium i5 can pull just over 60H/s on CPU maxing out 4 cores but uses much more energy (You can use it as a heater )

Your GPU performance on the Cryptonight algo is about what I was receiving on some very early testing, if memory serves me correctly. At the time there was no minimal image for the N1 so the performance was not consistent because the GPU was being shared with the desktop GUI. I also did some early N1 VRM performance testing for the CPU cores if you missed it. Because of the extra memory it performed very well.

The bottom line is there are several areas that could be optimized for better performance on the CPU and GPU. Right now I have one or two other projects I have been trying to complete in order to post on the forum, so the little discretionary time I have this time of year was been going to those. Keep us all informed on how your mods go, very interesting!
hominoid
 
Posts: 186
Joined: Tue Feb 28, 2017 3:55 am
Location: Lake Superior Basin, USA
languages_spoken: english
ODROIDs: C2, XU4, MC1, N1

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby brad » Fri Aug 24, 2018 5:03 pm

hominoid wrote:Your are correct. All the GPU cores for the N1 show up as a single GPU device.

I was hoping I was wrong, but great thank you :)
hominoid wrote:That's great, please share in the future if your so inclined. For the GPU and sgminer-arm, one of the main optimizations for Cryptonight that I removed was in algorithm/cryptonight.c lines 163-186.
static inline uint64_t mul128(uint64_t multiplier, uint64_t multiplicand, uint64_t* product_hi)

It was INTEL assembler that I replaced with some C code. Replacing it with ARM assembler would most likely be the quickest way to gain a significant performance increase for the GPU and Cryptonight algo.


I need to look into the sgminer code for cryptonight somewhat further, gpu workloads are handled a bit differently :) Have been understanding cpuminer first.
hominoid wrote:Your GPU performance on the Cryptonight algo is about what I was receiving on some very early testing, if memory serves me correctly. At the time there was no minimal image for the N1 so the performance was not consistent because the GPU was being shared with the desktop GUI. I also did some early N1 VRM performance testing for the CPU cores if you missed it. Because of the extra memory it performed very well.

The bottom line is there are several areas that could be optimized for better performance on the CPU and GPU. Right now I have one or two other projects I have been trying to complete in order to post on the forum, so the little discretionary time I have this time of year was been going to those. Keep us all informed on how your mods go, very interesting!


WIll be happy to keep you all informed and thank you for your tips and information. I ran the cpuminer code on the C2 (unfortunately binary did not work as mismatched ssl shared libraries) so compiled it up. Performance is basically identical to the N1's little cores (same a53 cores but no crypto license) at max 3H/s per core and the C2 does not have arm crypto module (it does have neon, fp and simd). Not sure how much improvement arm crypto extensions would give for GPU but should help somewhat for CPU I suspect.
brad
 
Posts: 708
Joined: Tue Mar 29, 2016 1:22 pm
Location: Australia
languages_spoken: english
ODROIDs: C2

Re: Dual GPU-CPU Mining on the XU4/MC1/HC1/HC2

Unread postby Antonio66 » Thu Oct 18, 2018 11:12 pm

Any chance for a new sgminer-arm version able to work with the new protocol update v8?

Many thanks
Antonio
Antonio66
 
Posts: 10
Joined: Sat Oct 29, 2016 5:01 am
languages_spoken: english
ODROIDs: XU4

Previous

Return to Projects

Who is online

Users browsing this forum: No registered users and 2 guests

cron