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

Moderators: odroid, mdrjr

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: 3660
Joined: Wed Jul 15, 2015 5:00 pm
Location: Bucharest, Romania
languages_spoken: english
ODROIDs: XU4, C1+, C2

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: 158
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: 158
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 677 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 677 times
hominoid
 
Posts: 158
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 590 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 590 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: 158
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: 27744
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: 4723
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: 158
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: 158
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: 18
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: 2
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: 2
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: 158
Joined: Tue Feb 28, 2017 3:55 am
Location: Lake Superior Basin, USA
languages_spoken: english
ODROIDs: C2, XU4, MC1, N1

Previous

Return to Projects

Who is online

Users browsing this forum: No registered users and 2 guests