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

Moderators: odroid, mdrjr

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

Unread postby hominoid » Tue Jan 16, 2018 7:25 am

I know there are many people using the XU4/MC1/HC1 for CPU crypto mining so I thought I would share how to setup for GPU mining, The algorithm performance isn't viable for many popular coins but in the right situation it might make sense such as coins with a low difficulty or new coins. If nothing else it's just cool, fun and another tool for the tool bag.

After looking around at all the available options, I have been working on getting the genesis mining fork of sgminer compiled. sgminer-gm 5.5.5 is an OpenCL GPU crypto miner and is the most recently maintained version of sgminer I could find. It supports more crypto algorithms then earlier versions, has no usage fee and has been around awhile.
(Credits, Scrypt, NScrypt, X11, X13, X14, X15, Keccak, Quarkcoin, Twecoin, Fugue256, NIST, Fresh, Whirlcoin, Neoscrypt, WhirlpoolX, Lyra2RE, Lyra2REV2, Pluck, Yescrypt, Yescrypt-multi, Blakecoin, Blake, Vanilla, Ethash, Cryptonight, Equihash)
https://github.com/genesismining/sgminer-gm
https://bitcointalk.org/index.php?topic=1612329.0

dual mining-lyra2rev-1c.jpg
dual mining-lyra2rev-1c.jpg (504.37 KiB) Viewed 11575 times
XU4 dual pool mining Monacoin with cpuminer-multi and sgminer-gm 5.5.5 using lyra2rev2

It is possible, in conjunction with cpuminer-multi or a coin specific miner like veriumMiner, to dual CPU and GPU mine. I haven't done extensive testing but have run a number of dual mining configurations that included scrypt2, lyra2rev2 and cryptonight(cpu only) solo and pool mining. It is possible to solo mine on one and pool mine on the other while running different or the same crypto algorithms. The CPU temperatures while dual mining require the large CPU cores to be slowed down so please pay attention to the temperatures if you try this!

CPUMiner-Multi - supports 45+ crypto algorithms. Check it out if your not familiar.
https://github.com/tpruvot/cpuminer-multi

For those mining Verium (VRM), another helpful program for dual mining is a fork of VeriumMiner by fireworm71.
https://github.com/fireworm71/veriumMiner
It can run 1-way and 3-way's at the same time which may allow for better memory utilization. So far it appears that if the GPU(sgminer) is started first you end up with more memory to use for the CPU crypto algorithm while dual mining. Below is the command line used mining Verium (4 large cores 3-way and 1 small core 1-way) while also GPU mining Monacoin with lyra2rev2.
Code: Select all
~/cpuminer -o stratum+tcp://yourpool.na:port -u username -p password --randomize --no-redirect -t 4 -1 1 --cpu-affinity-stride 1 --cpu-affinity-default-index 4 --cpu-affinity-oneway-index 0

EDIT:The new release of sgminer 5.5.6-ARM.RC1 has changed the installation process. Please see the March 13, 2018 post further down for completely new instructions.
Compiling sgminer-gm 5.5.5 for XU4/MC1/HC1
The following instructions are typical for sgminer with the exclusion of the source file edits.
For general reference and configuration information there is a good install wiki for x86 Ubuntu 16.04
https://github.com/genesismining/sgminer-gm/wiki/Compile-sgminer-5.5.5-in-Ubuntu-16.04.1-LTS

The following SDK's are required:

Download ARM Computer Vision and Machine Learning library
https://github.com/ARM-software/ComputeLibrary/releases/download/v17.12/arm_compute-v17.12-bin.tar.gz
Warning - Uncompressed this will not fit on a 8gb SD card. You can delete the unneeded libraries from ./arm_compute-v17.12-bin/lib to get it down to size. Keep the linux-armv7a libraries and delete the android-* and linux-arm8*.
Default installation is /usr/lib/arm_compute-v17.12-bin
Code: Select all
cd /usr/lib
tar -xvzf ~/arm_compute-v17.12-bin.tar.gz
cd ~/
rm arm_compute-v17.12-bin.tar.gz

Download AMD APP SDK for 32-bit Linux
https://developer.amd.com/amd-accelerated-parallel-processing-app-sdk/
This is for a root installation from ~/. See the installation notes for a non-root installation
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/AMD_APP_SDK_InstallationNotes.pdf

Default installation is /opt/AMDAPPSDK-3.0
Code: Select all
tar -xvjf AMD-APP-SDKInstaller-v3.0.130.136-GA-linux32.tar.bz2
./AMD-APP-SDK-v3.0.130.136-GA-linux32.sh
rm AMD-APP-SDK-v3.0.130.136-GA-linux32.sh
rm AMD-APP-SDKInstaller-v3.0.130.136-GA-linux32.tar.bz2

Download AMD Display Library (ADL) SDK
https://developer.amd.com/display-library-adl-sdk/
Default installation is /opt/ADL_SDK_V10.2
Code: Select all
apt-get install unzip
unzip ADL_SDK_V10.2.zip -d /opt/ADL_SDK_V10.2
rm ADL_SDK_V10.2.zip

Install Dependencies
Code: Select all
apt-get install automake autoconf pkg-config libcurl4-openssl-dev libjansson-dev libssl-dev libgmp-dev make g++ git libgmp-dev libncurses5-dev libtool opencl-headers mali-fbdev
Note: mali-fbdev needed if using Ubuntu minimalist image, malit628-odroid for debian minimalist image.

Download Git and Move Headers
Code: Select all
git clone https://github.com/genesismining/sgminer-gm
cd sgminer-gm
cp /opt/ADL_SDK_V10.2/include/*.h ./ADL_SDK

Source Code Edits
Some of the versions of sgminer I have looked at have similar compile issues and others have additional problems. Here is what I changed in sgminer-5.5.5

Make the following edits in 4 files:

kernel/lyra2rev2.cl
CHANGE LINE 32 FROM:
Code: Select all
#pragma OPENCL EXTENSION cl_amd_printf : enable
CHANGE TO:
Code: Select all
#pragma OPENCL EXTENSION cl_amd_printf : disable


kernel/skein256.cl
CHANGE STARTING ON LINE 49-59 FROM:
Code: Select all
__constant static const int ROT256[8][4] =
{
   46, 36, 19, 37,
   33, 27, 14, 42,
   17, 49, 36, 39,
   44, 9, 54, 56,
   39, 30, 34, 24,
   13, 50, 10, 17,
   25, 29, 39, 43,
   8, 35, 56, 22,
};
CHANGE TO:
Code: Select all
__constant static const int ROT256[8][4] =
{
   {46, 36, 19, 37},
   {33, 27, 14, 42},
   {17, 49, 36, 39},
   {44, 9, 54, 56},
   {39, 30, 34, 24},
   {13, 50, 10, 17},
   {25, 29, 39, 43},
   {8, 35, 56, 22}
};


ocl/build_kernel.c
CHANGE LINE 58
Code: Select all
  sprintf(data->compiler_options, "-I \"%s\" -I \"%s/kernel\" -I \".\" -D WORKSIZE=%d",
CHANGE TO:
Code: Select all
  sprintf(data->compiler_options, "-I %s -I %s/kernel -I . -D WORKSIZE=%d",

CHANGE LINE 66
Code: Select all
    strcat(data->compiler_options, " -I \"");
CHANGE TO:
Code: Select all
    strcat(data->compiler_options, " -I ");

CHANGE LINE 68
Code: Select all
    strcat(data->compiler_options, "\"");
CHANGE TO:
Code: Select all
    strcat(data->compiler_options, "/");


algorithm/cryptonight.c
CHANGE STARTING ON LINE 139 FROM:
Code: Select all
   __asm__("mul %%rdx":
   "=a" (lo), "=d" (hi):
   "a" (a), "d" (b));
CHANGE TO:
Code: Select all
   //__asm__("mul %%rdx":
   //"=a" (lo), "=d" (hi):
   //"a" (a), "d" (b));

Cryptonight is dysfunctional by commenting out the assembler optimization.
DO NOT USE CRYPTONIGHT
Here is what is going on. After fixing the extended assembly above, I was able to get it to compile but there was another problem I don't believe can be fixed. The cryptonight kernel is using AMD calls that aren't supported on the ARM platform and therefore cannot initialize the GPU. I believe the cryptonight kernel would have to be rewritten to get it to work...bummer. I'll keep exploring other options because cryptonight is one of the algorithms I was hoping to GPU mine.

Issue the following commands in the base sgminer-gm directory.

Code: Select all
git submodule init
git submodule update
autoreconf -fi
CFLAGS="-Os -Wall -march=native -std=gnu99 -mfpu=neon" LDFLAGS="-L/usr/lib/arm_compute-v17.12-bin/lib/linux-armv7a-neon-cl" ./configure --disable-git-version --disable-adl --disable-adl-checks --prefix=/opt/sgminer

In the configuration summary you should see that OpenCL was found and GPU mining was enabled. If it is not then OpenCL is not setup correctly and must be fixed before proceeding. The Hard Kernel Ubuntu images come with OpenCL setup. This build was done on ubuntu-16.04.3-4.14-minimal-odroid-xu4-20171213.img successfully. Check your proceeding steps for accuracy.
Code: Select all
------------------------------------------------------------------------
sgminer 5.5.5-gm-a
------------------------------------------------------------------------


Configuration Options Summary:

  Use git version......: no
  libcurl(GBT+getwork).: Enabled: -lcurl
  curses.TUI...........: FOUND: -lncurses
  OpenCL...............: FOUND. GPU mining support enabled
  ADL..................: Detection overrided. GPU monitoring support DISABLED

Compilation............: make (or gmake)
  CPPFLAGS.............:
  CFLAGS...............: -Os -Wall -march=native -std=gnu99 -I/opt/AMDAPPSDK-3.0/include
  LDFLAGS..............: -L/usr/lib/arm_compute-v17.12-bin/lib/linux-armv7a-neon-cl -lpthread
  LDADD................: -ldl -lcurl submodules/jansson/src/.libs/libjansson.a -lpthread -L/opt/AMDAPPSDK-3.0/lib/x86 -lOpenCL    -lm -lrt

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

To Finish
Code: Select all
make -j5
make install

Quick Tests
Code: Select all
./sgminer --version

sgminer 5.5.5-gm-a

Code: Select all
./sgminer -n

[20:41:54] CL Platform vendor: ARM
[20:41:54] CL Platform name: ARM Platform
[20:41:54] CL Platform version: OpenCL 1.2 v1.r12p0-04rel0.03af15950392f3702b248717f4938b82
[20:41:54] Platform devices: 2
[20:41:54]      0       Mali-T628
[20:41:54]      1       Mali-T628
[20:41:54] 2 GPU devices max detected

According to the install wiki "The first of these will fail if any libraries are missing, so if we get a version number then the compiled binary duly executes on our system. The second checks for OpenCL GPU devices on the default OpenCL platform...If both commands work without error and the latter indicates the correct OpenCL platform, you're well on the way to a working installation."

Assuming you have accounts setup at pools or are solo mining, a quick way to configure is by using the command line instead of a configuration file. You can learn more about all of this at the install wiki and under ./sgminer/doc/configuration.md. I have been using a simple script for testing because it's quick, easy and some variables need to be set.
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 algorithm -o stratum+tcp://pool.na:port -u user.worker -p password -I 14 -w 64 -d 0,1 --thread-concurrency 8192

The intensity(-I 14) and work size(-w 64) can be tuned for better (or worse) performance. Since the Mali-T628 has 2 device, both are selected(-d 0,1). Device 0 has 4 cores and device 1 has 2 cores.

When you start sgminer there is a long 30-40 second delay while the kernels for both GPU devices are created and loaded. The screen only has a couple of lines and it looks frozen. Be patient, it will then turn black for about 10-15 seconds and then will show the curses interfaces. For testing you can use a -T in the command line to disable the curses terminal interface and use simple text. It shows more information during the initialization process. While running some hardware errors are normal. If your getting a lot of hardware errors while running try adjusting the intensity, each algorithm will be different and needs to be tuned. This is were using a configuration file is useful. You can use different setting for different algorithms and pools.

I divide up my XU4/MC1 cluster into 4 thermal groups and run them at speeds to maintain 24/7/365 operation in the 70c's. The MC1's run the coolest of all the Odroid's. Here is one dual pool mining Verium with scrypt (cpuminer) and Monacoin with lyra2rev2 (sgminer), 2 hours for benchmark purposes. With this combination and frequency rate, the CPU hash rate decreased approximately 19% while GPU mining and the GPU hash rate decreased approximately 4% during CPU mining. There has been one 24hr test of 30 Odroids dual mining with no issues.

dual mining-scrypt-lyra2rev-1.jpg
dual mining-scrypt-lyra2rev-1.jpg (1.18 MiB) Viewed 11575 times
Regardless of cryptonight not working this is still the best option I'm aware of for GPU mining on the XU4/MC/HC1. The good news is that there are many other crypto algorithms sgminer-gm supports but be aware only a few were tested. Let everyone know if you find other ones that have a problem. If I make more head way on cryptonight and sgminer-5.5.5 or find a better solution I'll let everyone know.
Have fun with it and good luck micro-mining!
Last edited by hominoid on Thu Jun 14, 2018 8:51 am, edited 4 times in total.
hominoid
 
Posts: 188
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

Unread postby DarkBahamut » Tue Jan 16, 2018 9:28 am

I'm not really into mining myself but good work on getting GPU mining up and running. I'm sure this is going to make a few people interested :)

I'm curious, how are GPU temps holding up while mining? 2 things come to mind. If the GPU is much faster than the CPU's when mining I wonder if we can squeeze a bit more out of the GPU clocks for better performance. I'm fairly sure there's more headroom there. I run headless so I've never messed with it too much, but perhaps I need to get a GPU miner for some stability testing ;)

One other thing to address on the back of that is the kernel has no thermal protection for the GPU at all. I would guess for most people that's no issue at all, but for GPU mining it should probably be monitored just for a bit of safety.
DarkBahamut
 
Posts: 321
Joined: Tue Jan 19, 2016 10:19 am
languages_spoken: english
ODROIDs: XU4, N1

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

Unread postby mad_ady » Tue Jan 16, 2018 4:50 pm

Since the gpu is on the same soc as the cpu, can it reach 120C without triggering severe throttling in the A15 cores? Throttling the cpu would bring temperature down.
User avatar
mad_ady
 
Posts: 4890
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

Unread postby hominoid » Wed Jan 17, 2018 2:50 am

DarkBahamut wrote:I'm curious, how are GPU temps holding up while mining? 2 things come to mind. If the GPU is much faster than the CPU's when mining I wonder if we can squeeze a bit more out of the GPU clocks for better performance. I'm fairly sure there's more headroom there. I run headless so I've never messed with it too much, but perhaps I need to get a GPU miner for some stability testing ;)

One other thing to address on the back of that is the kernel has no thermal protection for the GPU at all. I would guess for most people that's no issue at all, but for GPU mining it should probably be monitored just for a bit of safety.

This may set the record for the most transistors turned on simultaneously on a XU4/MC1/HC1. :o
But seriously, I cannot speak to the GPU temps yet because of the limited testing done so far. I have been focused on making sure sgminer was working and reasonably stable before I posted. The 24hr test was only run at 1.2Ghz because I wasn't sure what to expect and was more about software stability. Really leaning into it will require some preparation and I was not ready. As you mentioned, I wanted to look at GPU frequency, voltage and temp control/monitoring. Unfortunately the AMD monitoring and control does not work on ARM.

odroid-gpu-control?...@mad_ady :-)

I'm always interesting in faster but for now I'm more interested in under-voltage and temperature control with the goal of not destroying any devices. Once a comfort level is reached that I will not be forever known as "hominoid the destroyer", I'll start pushing the limits. To your point about running headless, all of the testing and operation has been done headless. I will only be running this headless. This has not been run with a graphics front-end but forgoing any intentional GPU use conflicts I believe it should work.
mad_ady wrote:Since the gpu is on the same soc as the cpu, can it reach 120C without triggering severe throttling in the A15 cores? Throttling the cpu would bring temperature down.

Anything is possible at this point. More testing is necessary to answer these questions because we may be in new thermal territory. My very very limited experience seems to indicate the CPU clock frequency may be a larger controlling factor then I initial thought to overall GPU temperature?

Some of the questions I will be researching to move forward are:
Can the GPU frequency and voltage be controlled dynamically from the command line?
What is the relationship and granular effect between the GPU and CPU operational loads and temperature?
What is the best way to control and monitor the GPU and CPU temps in real-time with kernel 4.14?
hominoid
 
Posts: 188
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

Unread postby mad_ady » Wed Jan 17, 2018 3:57 am

@hominid_the_destroyer: Kernel 3.10 had a gpu utilization entry in sysfs under /sys/devices/11800000.mali/utilization, but newer kernels no longer have it - that's why there is no gpu option in odroid-cpu-control. :)

There are some nodes in /sys/bus/platform/devices/11800000.mali:/devfreq/11800000.mali:/ that can help you with governor. I use simple_ondemand and the gpu sits idle @177MHz, while it is at 600MHz when processing. I could add those to odroid-cpu-control...
User avatar
mad_ady
 
Posts: 4890
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

Unread postby hominoid » Wed Jan 17, 2018 9:54 am

@mad_ady, Thank you for the info and offer, it's very kind. I don't want you to needlessly spend time on something I'm not sure solves the real problem. Having no indication of the GPU temp is the problem. I'm going to think on this a little while.
hominoid
 
Posts: 188
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

Unread postby odroid » Wed Jan 17, 2018 10:02 am

You can read the GPU temperature via /sys/class/thermal/thermal_zone4/temp with Kernel 4.14.
thermal_zone 0 to 3 are assigned to four A15 Eagle cores.
User avatar
odroid
Site Admin
 
Posts: 29097
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English
ODROIDs: ODROID

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

Unread postby hominoid » Wed Jan 17, 2018 10:27 am

odroid wrote:You can read the GPU temperature via /sys/class/thermal/thermal_zone4/temp with Kernel 4.14.
thermal_zone 0 to 3 are assigned to four A15 Eagle cores.

Thanks @odroid for the correction, I confused an earlier comment. Apparently I need more sleep or to focus better. :)
hominoid
 
Posts: 188
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

Unread postby hominoid » Wed Jan 17, 2018 4:25 pm

Dual Gpu-Cpu Mining Test to study the effects of CPU frequency change on GPU operational temperature
1hr 50min. Ambient Air Temperature approximately 76f (24.44c)

First 10 Minutes of the test was GPU only mining to establish the baseline GPU operational temperature.
Monacoin with lyra2rev2 (sgminer) Pool, -I 14 -w 64 -d 0,1 --thread-concurrency 8192

For the remainder of the dual mining test CPU Verium with scrypt (cpuminer 8 threads No affinity) Solo and GPU Monacoin with lyra2rev2 (sgminer 1 thread) Pool, -I 14 -w 64 -d 0,1 --thread-concurrency 8192

Starting at 1.7Ghz, the CPU frequency was decreased by 100Mhz every 10 minutes to 1.2Ghz then raised 100Mhz every 5 Minutes until 1.9Ghz, then changed to 1.6Ghz for the remainder of the test.

The GPU mined at 51c for the first 10minutes of the test and then rose with the temperature of the CPU cores forming a plateau at each frequency change. The GPU never exceeding 72c except for a few brief spike to 74c. The temperature drops in the GPU during the test appear to be correlated to the frequency change of the CPU cores. The GPU hash rate (71 kh/s) was steady during the whole test while the CPU hash rate varied according to the frequency setting as expected.
multicoretempchart.png
multicoretempchart.png (254.82 KiB) Viewed 11360 times
hominoid
 
Posts: 188
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

Unread postby Spada » Thu Jan 18, 2018 4:09 am

Hi hominoid! I've gone through the steps, everything went well on my XU4. I've been mining using the same pool as you, but although I get messages of work being done, on the pool website, my worker is shown as inactive, my hashrate is 0 and I get no shares. I've been mining for more than an hour, yet nothing happens.

Verbose output:

Code: Select all
[21:02:48] (5s):65.10K (avg):62.91Kh/s | A:0  R:0  HW:4  WU:0.000/m
[21:02:53] (5s):66.06K (avg):62.97Kh/s | A:0  R:0  HW:4  WU:0.000/m
[21:02:58] (5s):66.29K (avg):63.02Kh/s | A:0  R:0  HW:4  WU:0.000/m
[21:03:04] (5s):64.65K (avg):63.01Kh/s | A:0  R:0  HW:4  WU:0.000/m
[21:03:07] Work update message received
[21:03:10] (5s):63.79K (avg):63.00Kh/s | A:0  R:0  HW:4  WU:0.000/m
[21:03:16] (5s):63.08K (avg):62.99Kh/s | A:0  R:0  HW:4  WU:0.000/m
[21:03:21] (5s):55.93K (avg):62.75Kh/s | A:0  R:0  HW:4  WU:0.000/m
[21:03:27] (5s):57.60K (avg):62.71Kh/s | A:0  R:0  HW:4  WU:0.000/m
[21:03:33] (5s):58.57K (avg):62.67Kh/s | A:0  R:0  HW:4  WU:0.000/m
[21:03:39] (5s):68.14K (avg):62.95Kh/s | A:0  R:0  HW:4  WU:0.000/m
[21:03:39] New block: 289cc6edebeca49a15ae48bd96f7945a5f2dfa06417057d13e99841610070597... diff 26.2K
[21:03:39] Work update message received
[21:03:44] (5s):67.98K (avg):63.01Kh/s | A:0  R:0  HW:4  WU:0.000/m
[21:03:49] (5s):67.61K (avg):63.06Kh/s | A:0  R:0  HW:4  WU:0.000/m
[21:03:53] New block: e0027daf8ba4bf1ab6b3faec7421c42ccfe285da92733c9e87369060b20249cf... diff 25.7K
[21:03:53] Work update message received
[21:03:55] (5s):65.29K (avg):63.04Kh/s | A:0  R:0  HW:4  WU:0.000/m


If I enable the debug output, I see 'discarding' or 'discarded work':

Code: Select all
0000000000000000000000000000000000000000000000000000080020000
[21:06:13] [THR0] Work job_id 4402 nonce2 33 ntime 5a5f9e87
[21:06:13] [THR0] Generated target 0000000000000000000000000000000000000000000000000000fcff03000000
[21:06:13] Generated stratum work
[21:06:13] [THR0] Pushing work from mona.suprnova.cc to hash queue
[21:06:15] total hashes: 36012032, total runtime / s: 571.872
[21:06:15] [THR0] Staged work: total (2) > max (1), discarding
[21:06:15] [THR0] Discarded work
[21:06:15] (5s):52.22K (avg):62.97Kh/s | A:0  R:0  HW:6  WU:0.000/m
[21:06:15] Selecting mona.suprnova.cc for work
[21:06:15] [THR0] gen_stratum_work() - algorithm = lyra2rev2
[21:06:15] [THR0] Generated stratum merkle 63357a13327dc771be080704bc9c559147d39c7da943d5247d419a9935665658
[21:06:15] [THR0] Generated stratum header 200000000c2bd4130733ba7a3749ab253882ee1762654dd94e71073ec28e270957c1505f63357a13327dc771be080704bc9c559147d39c7da943d5247d419a99356656585a5f9e871b025cf8000000000000008000000000000000000000000000
00000000000000000000000000000000000000000000000000000080020000
[21:06:15] [THR0] Work job_id 4402 nonce2 34 ntime 5a5f9e87
[21:06:15] [THR0] Generated target 0000000000000000000000000000000000000000000000000000fcff03000000
[21:06:15] Generated stratum work
[21:06:15] [THR0] Pushing work from mona.suprnova.cc to hash queue
[21:06:16] [thread 0: 196608 hashes, 38.388 khash/sec]
[21:06:16] [thread 0: 16384 hashes, 42.28 khash/sec]
[21:06:17] [THR0] Popping work from get queue to get work
[21:06:17] [THR0] preparing thread...



This is the third pool I've been mining and I get the same results. Could you please let me know if there is something I'm missing?
Spada
 
Posts: 18
Joined: Tue Oct 18, 2016 1:23 am
languages_spoken: english
ODROIDs: C2, XU4

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

Unread postby hominoid » Thu Jan 18, 2018 5:24 am

Spada wrote:Hi hominoid! I've gone through the steps, everything went well on my XU4. I've been mining using the same pool as you, but although I get messages of work being done, on the pool website, my worker is shown as inactive, my hashrate is 0 and I get no shares. I've been mining for more than an hour, yet nothing happens.
This is the third pool I've been mining and I get the same results. Could you please let me know if there is something I'm missing?

Hi Spada,
Happy to hear it compiled without a problem and is running. I don't believe there is a technical problem with sgminer-gm, I see one rejection. The hash rate your producing is a micro fraction based on the difficulty and network hash rate for Monacoin. The typical modern gpu for Monacoin running lyra2rev2 is in the mh/s (18-30mh/s) now and the Mali-T628 is running about 72kh/s. It will take a long time to even find a valid share for Monacoin. This is why I said in the opening of the post that this was for low difficulty and new coins possibly. After 24hrs on 30 Odroids I did find shares and earn a little Monacoin but I was only using it as a test bed. Try to focus on new and low diff. coins on the Odroid platform for better economic success.
hominoid
 
Posts: 188
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

Unread postby Spada » Thu Jan 18, 2018 5:35 am

Sweet! Thank you for your reply. The 'discarded' got me a little bit scared.
Spada
 
Posts: 18
Joined: Tue Oct 18, 2016 1:23 am
languages_spoken: english
ODROIDs: C2, XU4

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

Unread postby hominoid » Thu Jan 18, 2018 7:11 am

Hey new miners,
A quick note about rejected shares. There are numerous reasons why you might get rejected or stale shares. It could be an error, but most are caused by network latency. Two scenarios: your rig is mining away on a block, finds a valid share and submits to the network. In the meantime the block was solved and a new block and work issued. When your share is submitted it is now stale and will be rejected. The ST indicator in sgminer indicates the number of stale shares you have submitted. This is not an error and there is not much you can do about it. You can reduce the chances of having a problem by not mining to a pool on the other side of the world there in creating more latency for your miner. Find a server in your own country or as close as possible. Most pools offer multiple geographically dispersed servers for this reason.

Scenario 2, you get lucking and find a block and when the solution is presented someone else submitted a valid solution before you did. You now have an orphaned block. These are two of the most common causes and unless you getting a lot of rejects it shouldn't be a problem. If your getting a lot of rejects and have a lot of GPU HW errors, your probably pushing your GPU too hard and need to adjust the intensity, work size or number of threads. And as always, just because you can mine a coin does not mean you find a coin, if solo mining or a valid share if pool mining. A good example would be to try and mine bitcoin with anything other than an ASIC device(application specific integrated circuit). The hash rate and difficulty is beyond other hardware's capability...unless you get extremely luck...if so, stop, you just won the lottery!

Most/all pools will not show a hash rate or that your even mining until you submit a valid share. And, when the block changes and no new shares have been submitted, your back to not showing up at the pool. So if your mining a economically mismatched coin for the device, don't be surprised when your miner is not seen by the pool. So, find a coin you want to mine and match the appropriate HW device for the difficulty and hash rate. Or, using the HW devices available to you, see what coins it's possible to mine with it's capability.
hominoid
 
Posts: 188
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 Wef » Sat Feb 10, 2018 7:37 am

Thanks, @hominoid! I, too, followed this guide and got everything working on a brand spanking new XU4.
Wef
 
Posts: 1
Joined: Sat Feb 10, 2018 7:29 am
languages_spoken: english
ODROIDs: XU4

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

Unread postby hominoid » Sun Feb 11, 2018 3:19 am

Wef wrote:Thanks, @hominoid! I, too, followed this guide and got everything working on a brand spanking new XU4.

Great, thanks for sharing your successful build and Welcome to the community!
hominoid
 
Posts: 188
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 golgoth » Thu Feb 15, 2018 5:49 pm

Hey guys,
first thanks a lot to hominoid for sharing your work, I've tried mining monacoin on an hc2 with the same performance your reported.

anyway, when i tried to mine some neoscrypt based coin i have a strange error reported:

Code: Select all
[08:41:27] Building binary neoscryptMali-T628gw64l4lgtc8192.bin
[08:41:28] Error -11: Building Program (clBuildProgram)
[08:41:28] <source>:1372:24: error: passing '__global ulong16 *' to parameter of incompatible type '__global uint16 *'
                if (i) SMix_Chacha(X,V); else SMix_Salsa(Z,V);
                                     ^

<source>:1309:48: note: passing argument to parameter 'V' here
void SMix_Chacha(uint16 X[4], __global uint16 *V)
                                               ^

<source>:1372:46: error: passing '__global ulong16 *' to parameter of incompatible type '__global uint16 *'
                if (i) SMix_Chacha(X,V); else SMix_Salsa(Z,V);
                                                           ^

<source>:1287:47: note: passing argument to parameter 'V' here
void SMix_Salsa(uint16 X[4], __global uint16 *V)
                                              ^

error: Compiler frontend failed (error code 59)


that doesn't really make sense to me since both types are the same.

Anyone have an idea?
edit:
I'm blind, types aren't the same...still not working for the moment
edit2:
ok so I tried changing the declaration of v to uint16 or changing the declaration of both function (SMix_Salsa and SMix_ChaCha) to ulong16, in both case the program stopped crashing but I only get a black screen and no hash rate reported on the pool, even with -D.
golgoth
 
Posts: 33
Joined: Wed Nov 02, 2016 1:02 am
languages_spoken: english

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

Unread postby hominoid » Sat Feb 17, 2018 1:50 am

Thanks for the post and the information. I took a quick look at sgminer-gm/kernel/neoscrypt.cl.
https://github.com/genesismining/sgmine ... oscrypt.cl
There seems to be a lot of AMD optimization specific code here by Wolf, a well known AMD optimization specialist. It also might have something to do with his comments on line 578 and 579. :) Warning explicit language.

FYI, Here is an update of what I've been doing, where this project is at and it's direction.
I have been reviewing all of the OpenCL kernels to identify which ones have AMD specific extensions. Besides Cryptonight, I have also identified Ethash, Equihash and WhirlpoolX. They all use one or more of the following AMD OpenCL Extensions:

amd_printf
ARM has an extension to replace this one but it may be irrelevant because printf in now part of OpenCL 1.2. I still have to see if it is a direct replacement. There are no ARM OpenCL extensions for the next two.

#pragma OPENCL EXTENSION cl_amd_media_ops : enable
amd_bitalign
https://www.khronos.org/registry/OpenCL ... ia_ops.txt

#pragma OPENCL EXTENSION cl_amd_media_ops2 : enable
specifically, amd_bfe is the most used AMD optimization in the kernels.
https://www.khronos.org/registry/OpenCL ... a_ops2.txt

There is also the assembler extension to deal with in cryptonight. it is a uint64, uint64, mul_uint128. My original replacement was legal but incorrect (uint64 uint64 mul_uint64) but it got me past it only to find the AMD Extensions.

I'm currently working to see if the kernels can be fixed, even if de-optimized by replacement of the AMD extensions. I have been examining possible functions to replace the amd_bfe and amd_bitalign extensions. I'm definitely in front of my skis on this one headed down a steep slope but, I'll do my best. If that doesn't happen for some reason, then I'll go to a previous fork before the optimizations took place. The original OpenCL kernel requirements in doc/kernel.md says
Code: Select all
## Submitting new kernels

### Requirements

* OpenCL source code only, licenced under GPLv3 (or later).
* Not hard-coded for a specific GPU model or manufacturer.
* Known limitations and any specific configuration quirks must be
  mentioned.

At some point that changed. FYI, there are some limitations listed for specific kernels in that file. While in the midst of this, it has been nagging me that clinfo did not work on the XU4.
Code: Select all
root@c0n0:~# apt install clinfo
root@c0n0:~# clinfo
Number of platforms                               0

So most recently I dedicated some time to get it working as posted here. clinfo should now work. I'm continuing to work on OpenCL kernels but the new Odroid N1 engineering sample just arrived. I'll be slowing down on this project for a little while to lend a hand shaking down the N1. I'll continue working more on this as the launch time of the N1 gets closer so check back occasionally for any progress. I'm sorry that there is no immediate solution to your problem.
hominoid
 
Posts: 188
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 golgoth » Sat Feb 17, 2018 2:50 am

hominoid wrote:Thanks for the post and the information. I took a quick look at sgminer-gm/kernel/neoscrypt.cl.
https://github.com/genesismining/sgmine ... oscrypt.cl
There seems to be a lot of AMD optimization specific code here by Wolf, a well known AMD optimization specialist. It also might have something to do with his comments on line 578 and 579. :) Warning explicit language.

FYI, Here is an update of what I've been doing, where this project is at and it's direction.
I have been reviewing all of the OpenCL kernels to identify which ones have AMD specific extensions. Besides Cryptonight, I have also identified Ethash, Equihash and WhirlpoolX. They all use one or more of the following AMD OpenCL Extensions:

amd_printf
ARM has an extension to replace this one but it may be irrelevant because printf in now part of OpenCL 1.2. I still have to see if it is a direct replacement. There are no ARM OpenCL extensions for the next two.

#pragma OPENCL EXTENSION cl_amd_media_ops : enable
amd_bitalign
https://www.khronos.org/registry/OpenCL ... ia_ops.txt

#pragma OPENCL EXTENSION cl_amd_media_ops2 : enable
specifically, amd_bfe is the most used AMD optimization in the kernels.
https://www.khronos.org/registry/OpenCL ... a_ops2.txt

There is also the assembler extension to deal with in cryptonight. it is a uint64, uint64, mul_uint128. My original replacement was legal but incorrect (uint64 uint64 mul_uint64) but it got me past it only to find the AMD Extensions.

I'm currently working to see if the kernels can be fixed, even if de-optimized by replacement of the AMD extensions. I have been examining possible functions to replace the amd_bfe and amd_bitalign extensions. I'm definitely in front of my skis on this one headed down a steep slope but, I'll do my best. If that doesn't happen for some reason, then I'll go to a previous fork before the optimizations took place. The original OpenCL kernel requirements in doc/kernel.md says
Code: Select all
## Submitting new kernels

### Requirements

* OpenCL source code only, licenced under GPLv3 (or later).
* Not hard-coded for a specific GPU model or manufacturer.
* Known limitations and any specific configuration quirks must be
  mentioned.

At some point that changed. FYI, there are some limitations listed for specific kernels in that file. While in the midst of this, it has been nagging me that clinfo did not work on the XU4.
Code: Select all
root@c0n0:~# apt install clinfo
root@c0n0:~# clinfo
Number of platforms                               0

So most recently I dedicated some time to get it working as posted here. clinfo should now work. I'm continuing to work on OpenCL kernels but the new Odroid N1 engineering sample just arrived. I'll be slowing down on this project for a little while to lend a hand shaking down the N1. I'll continue working more on this as the launch time of the N1 gets closer so check back occasionally for any progress. I'm sorry that there is no immediate solution to your problem.


Great to hear from you.
Seems that late opencl based mining software all include amd optimisation sadly.
Today I tried to compile various opencl based xmr miner, like xmrig-amd or xmr-stak-amd, both for the same results: either amd specific code, or x86_64 (like sse2) specific code.
Some say the old wolf-xmr-miner should work on mali, but all GitHub repositories are down sadly.
Since I'm far from your C/C++ knowledge i haven't tried function substitution of course.

Finally regarding the new Odroid N, considering what a fine piece of hardware it seems to be, I would do the same if I was in your position, have fun!
golgoth
 
Posts: 33
Joined: Wed Nov 02, 2016 1:02 am
languages_spoken: english

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

Unread postby hominoid » Sat Feb 17, 2018 3:31 am

golgoth wrote:Since I'm far from your C/C++ knowledge i haven't tried function substitution of course.

Hah! I have no c/c++ skills anymore. What I did know once is long forgotten or so rusty that my knuckles squeak when I type. And, OpenCL and OpenCL kernels are new to me. This is brute determination to get it done.
hominoid wrote: I'm definitely in front of my skis on this one headed down a steep slope but, I'll do my best.

So anyone, at any level, should feel comfortable chiming in and sharing what they can. It's all appreciated in order to reach a common goal.
hominoid
 
Posts: 188
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 boardt » Tue Feb 20, 2018 5:31 am

So what is the best/most profitable coin(s) to mine on the XU4? I have only been able to get Magicoin to work. I am going to try Verium, but heard that it will take a LOOOONNNNNGGGG time to mine that.

I am getting about 28 h/s for Magicoin.
boardt
 
Posts: 33
Joined: Thu Feb 15, 2018 4:40 am
languages_spoken: english

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

Unread postby hominoid » Tue Feb 20, 2018 10:43 am

boardt wrote:So what is the best/most profitable coin(s) to mine on the XU4? I have only been able to get Magicoin to work. I am going to try Verium, but heard that it will take a LOOOONNNNNGGGG time to mine that.

I am getting about 28 h/s for Magicoin.

Hey @boardt, Unfortunately this is off-topic for this thread and forum. Most folks on this forum are not involved in crypto-currencies. A much better and appropriate place to ask your question would be on one of the forums on the subject such as bitcointalk.org's alt-coin sub-forum. There you will find already active and on going threads on that specific topic. Here is also a link to the Verium(VRM) thread.

I will offer 2 pieces of unsolicited advice; One, if you don't have much hashing power use a pool; Two, No one can answer your question other than you. You have to do your own homework because everyone's situation and risk adversity is different. It just the way it is, Good Luck!
hominoid
 
Posts: 188
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 boardt » Tue Feb 20, 2018 10:07 pm

Ok.. sorry. Thought a thread about MINING on the XU4 was ok.. but I will go searching over there. Thanks.
boardt
 
Posts: 33
Joined: Thu Feb 15, 2018 4:40 am
languages_spoken: english

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

Unread postby rooted » Wed Feb 21, 2018 7:31 am

boardt wrote:Ok.. sorry. Thought a thread about MINING on the XU4 was ok.. but I will go searching over there. Thanks.
You are free to start your own thread and discuss any topic ;)
User avatar
rooted
 
Posts: 5883
Joined: Fri Dec 19, 2014 9:12 am
Location: Gulf of Mexico, US
languages_spoken: english

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

Unread postby hominoid » Wed Feb 21, 2018 10:00 am

rooted wrote:
boardt wrote:Ok.. sorry. Thought a thread about MINING on the XU4 was ok.. but I will go searching over there. Thanks.
You are free to start your own thread and discuss any topic ;)

@rooted is correct. I just didn't want my project thread hijacked and didn't think you would get much response on the forum regarding the profitability of CPU Crypto mining. There are lots of opinions on the subject at the link I provided. I stand corrected, thanks @rooted...Definitely no need to apologize.
hominoid
 
Posts: 188
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 huantxo » Sun Feb 25, 2018 2:13 am

Hello. Congratulations for the wonderful tutorial.

However, I think you forgot to add one package to the install list. It failed for me to compile with some missing headers, until I installed 'opencl-headers'
Code: Select all
sudo apt install opencl-headers
huantxo
 
Posts: 25
Joined: Thu Feb 22, 2018 1:09 am
languages_spoken: English, Spanish
ODROIDs: HC1, XU4

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

Unread postby hominoid » Tue Feb 27, 2018 11:25 am

huantxo wrote:Hello. Congratulations for the wonderful tutorial.

However, I think you forgot to add one package to the install list. It failed for me to compile with some missing headers, until I installed 'opencl-headers'
Code: Select all
sudo apt install opencl-headers

Thanks @huantxo for pointing that out. We do need OpenCL Headers installed and that is probably the easiest way. One could also copy the ARM Computer Vision and Machine Learning library headers. Either should work.
Code: Select all
mkdir /usr/include/CL
cp /usr/lib/arm_compute-v17.12-bin/include/CL/* /usr/include/CL

I originally had the package listed to be installed but ended up removing it in the process of figuring out why clinfo didn't work and if there was a standard for the OpenCL libraries installation location, see this post.
I have updated the package list. Thanks for the correction!
hominoid
 
Posts: 188
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 » Wed Mar 14, 2018 3:06 am

Update: Release of sgminer 5.5.6-ARM-RC1
The removal of all the OpenCL AMD dependencies and INTEL assembler for the OpenCL kernels and crypto algorithms is now complete for sgminer. We had a another positive event happen in the last 2 days; Genesis Mining released a new version of sgminer-gm 5.5.6. And as is usually the case, it happened a couple hours after finishing all the testing on 5.5.5a as I was preparing to post the results on the forum. I decided to take the extra time to incorporate the new release and repeat the testing. Here is brief summary of the kernels and crypto algorithms that were modified for the HK Odroid and the test results.

ocl/build_kernel.c
algorithm/cryptonight.c - INTEL assembler optimizations
algorithm/neoscrypt.c - AMD architecture optimizations

kernel/cryptonight.cl - AMD OpenCL extensions
kernel/equihash.cl - AMD OpenCL extensions and AMD architecture optimizations
kernel/ethash.cl - AMD OpenCL extensions
kernel/ethash-genoil.cl - AMD architecture optimizations
kernel/ethash-new.cl - AMD architecture optimizations
kernel/lyra2re.cl - AMD OpenCL extensions
kernel/lyra2rev2.cl - AMD OpenCL extensions
kernel/whirlpoolx.cl - AMD architecture optimizations
kernel/wolf-aes.cl - AMD OpenCL extensions
kernel/wolf-skein.cl - AMD OpenCL extensions

Many(7 of 10) of the OpenCL kernels share one or more of the same AMD OpenCL extensions that were replaced, and were tested with the cryptonight kernel, which also uses 2 OpenCL helper kernels (wolf-aes.cl and wolf-skein.cl). I'm not sure that ethash-new.cl is even used for any coins which would leave only 2 unproven in anyway, whirlpoolx.cl and ethash-genoil.cl. The others had only AMD and or Nvidia architecture optimizations that were removed. I took the most conservative approach possible in my modifications so they would run on a broad spectrum of current and future GPU's, but there is always room for technical and human error. Still, this gives me a certain comfort that we should be in a good position for the release of sgminer 5.5.6-ARM-RC1.
sgminer-5.5.6-ARM-RC1 Test1.png
sgminer-5.5.6-ARM-RC1 Test1.png (206.16 KiB) Viewed 9402 times

The test was run for 12hours+ and ran smoothly. I have a relatively slow internet connection so any statrum server disconnects and purported stale shares are not unusual. With that said, the summary shows only 2 rejected shares.
sgminer-5.5.6-ARM-RC1 Test Summary1.png
sgminer-5.5.6-ARM-RC1 Test Summary1.png (94.21 KiB) Viewed 9402 times

The pool stats verify the summary results.
sgminer-5.5.6-ARM-RC1 Test Pool Results.png
sgminer-5.5.6-ARM-RC1 Test Pool Results.png (36.21 KiB) Viewed 9402 times

With the increasing modification of sgminer, a git was setup for ease of use and future modification. Likewise, the installation process has changed and no longer requires any AMD_SDK, only the ARM Computer Vision and Machine Learning library. Below is the new procedure.

Download and install the latest ARM Computer Vision and Machine Learning library
https://github.com/ARM-software/ComputeLibrary/releases
Note: They have separated the Linux and Android libraries so it now fits on a 8GB SDcard. Use tar -xvzf `file` to extract

Install Dependecies
Code: Select all
apt-get install automake autoconf pkg-config libcurl4-openssl-dev libjansson-dev libssl-dev libgmp-dev make g++ git libgmp-dev libncurses5-dev libtool opencl-headers mali-fbdev

I have found an issue with the ARM Computer Vision and Machine Learning library OpenCL header files and the Ubuntu repository opencl-headers. The easiest way around this right now is to simply copy the ARM Computer Vision and Machine Learning library OpenCL header files over the opencl-headers with the following command.
Code: Select all
cp ./arm_compute-v18.03-bin-linux/include/CL/* /usr/include/CL/

Download sgminer-5.5.6-ARM-RC1
Code: Select all
git clone https://github.com/hominoids/sgminer-arm


Compile Source
Code: Select all
cd sgminer-arm
git submodule init
git submodule update
autoreconf -fi

CFLAGS="-Os -Wall -march=native -std=gnu99 -mfpu=neon" ./configure --disable-git-version --disable-adl --disable-adl-checks

or explicit to where you placed the library.
Code: Select all
CFLAGS="-Os -Wall -march=native -std=gnu99 -mfpu=neon -I/opt/arm_compute-v18.03-bin-linux/include/CL" LDFLAGS="-L/opt/arm_compute-v18.03-bin-linux/lib/linux-armv7a-neon-cl" ./configure --disable-git-version --disable-adl --disable-adl-checks

Code: Select all
make -j5

Here is the script and settings used for the testing of Monero coin using the cryptonight algorithm.
Code: Select all
#!/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://pool.supportxmr.com:3333 -u username -p password -I 7 -w 32 -d 0,1 --thread-concurrency 8192 --monero --pool-no-keepalive

The test above was done on an Odroid-XU4 and I did do some testing on ARMv8 using the Odroid-N1 engineering sample with some success. I ran into some minor issues I need to investigate further but going to far on an ES with an interim OS and kernel does not make sense. The sgminer-arm implementation should be CPU and GPU agnostic but I cannot say for sure at this time. This also raises the question whether to do some ARM-Mali optimization based on specific architectures (ARMv7, ARMv8, Mali-T628, Mali-T860) in the future. That will have to wait for now.

As always, any feedback, comments, results or issues are highly appreciated. The Odorid Community now has the only fully implemented Linux ARM based OpenCL GPU miner that I'm aware of in the crypto community! Have fun and good luck micro mining!

Edit: Running the Desktop, which I learned is using the GPU on the Odroid-N1 OS, is likely the cause of the minor issue I was having. As soon as a minimalist image becomes available I'll continue my testing on the ARMv8 architecture.

EDIT: I have updated the compile instructions to include an explicit link to the ARM Computer Vision and Machine Learning library OpenCL include files to deal with a possible conflict with the Ubuntu repository opencl-headers.

EDIT: The explicit link didn't work. See my post below for more details
Last edited by hominoid on Sat Mar 17, 2018 11:00 pm, edited 8 times in total.
hominoid
 
Posts: 188
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 rooted » Wed Mar 14, 2018 3:29 am

How long did it take to make that $10?

Awesome that GPU acceleration is enabled and actually functional.
User avatar
rooted
 
Posts: 5883
Joined: Fri Dec 19, 2014 9:12 am
Location: Gulf of Mexico, US
languages_spoken: english

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

Unread postby hominoid » Wed Mar 14, 2018 5:12 am

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
Cryptonight Test 1hrs Block Found.png (160.21 KiB) Viewed 9389 times
hominoid
 
Posts: 188
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 » Wed Mar 14, 2018 6:13 am

:o :twisted:

Can you tell me which Kernel version do you run now?
User avatar
odroid
Site Admin
 
Posts: 29097
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 hominoid » Wed Mar 14, 2018 9:18 am

odroid wrote: :o :twisted:

Can you tell me which Kernel version do you run now?

I'm running the latest stock kernel, I believe, on all my machines and have been for awhile. Testing I did awhile back convinced me that 4.14 was ready for crypto mining! Great job with it HK developers! The last command in the test summary above is a uname -a indicating 4.14.5-92.

As an additional note, I believe @crashoverride's response to my question in the N1 forum, regarding GPU utilization, explains the behavior of the N1 GPU that I experienced. So I'm relatively confident that the N1 is going to be good to go as well. Still would like to see some testing though before claiming ARMv8 support. I have temporarily left it off the tested list on the sgminer-arm git until then.

[Edit] Just noticed @merveric is working on a N1 minimalist image! I'll have to investigate moving forward.
Last edited by hominoid on Wed Mar 14, 2018 11:39 am, edited 1 time in total.
hominoid
 
Posts: 188
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 » Wed Mar 14, 2018 10:23 am

Thank you for the positive response. I missed "uname -a" output on the screenshots.

Did you have any chance to try to compare the Verium hash rate(CPU mining, not GPU mining) between XU4 vs N1?
According to our quick test, XU4 was slightly better than N1, as expected.
User avatar
odroid
Site Admin
 
Posts: 29097
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 odroid » Wed Mar 14, 2018 10:29 am

Another side note.
The current XU4 kernel version is
Code: Select all
odroid@odroid:~$ uname -a
Linux odroid 4.14.26-120 #1 SMP PREEMPT Wed Mar 14 00:21:56 UTC 2018 armv7l armv7l armv7l GNU/Linux

Marc Zyngier's patches were included from 4.14.15 to fix the Spectre vulnerable.
User avatar
odroid
Site Admin
 
Posts: 29097
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 hominoid » Wed Mar 14, 2018 11:43 am

odroid wrote:Another side note.
The current XU4 kernel version is
Code: Select all
odroid@odroid:~$ uname -a
Linux odroid 4.14.26-120 #1 SMP PREEMPT Wed Mar 14 00:21:56 UTC 2018 armv7l armv7l armv7l GNU/Linux

Marc Zyngier's patches were included from 4.14.15 to fix the Spectre vulnerable.


Thanks for the headsup, I don't run auto-update because almost all of my systems are production systems running 24/7 on an already challenged internet connection. I do planned maintenance, which is when those things happen. :)
hominoid
 
Posts: 188
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 » Sat Mar 17, 2018 11:29 am

I have found an issue with the ARM Computer Vision and Machine Learning library OpenCL header files and the Ubuntu repository opencl-headers. I'm getting a compile failure caused by a couple of OpenCL calls. The easiest way around this right now is to simply copy the ARM Computer Vision and Machine Learning library OpenCL header files over the opencl-headers with the following command.
Code: Select all
cp ./arm_compute-v18.03-bin-linux/include/CL/* /usr/include/CL/


I work with the OpenCL library configured so I don't have to use explicit links, which might be why I didn't see it right away. There have been 4 releases of the Arm Library since starting this project so I'm not sure if it's been there the whole time or not.
Code: Select all
tar -xvzf ./arm_compute-v18.03-bin-linux.tar.gz
cp ./arm_compute-v18.03-bin-linux/include/CL/* /usr/include/CL/
mkdir /usr/lib/OpenCL
mkdir /usr/lib/OpenCL/vendors
mkdir /usr/lib/OpenCL/vendors/arm
cp ./arm_compute-v18.03-bin-linux/lib/linux-armv7a-neon-cl/* /usr/lib/OpenCL/vendors/arm/
echo "/usr/lib/OpenCL/vendors/arm" > /etc/ld.so.conf.d/opencl-vendor-arm.conf
ldconfig

I'm not sure of the best way to permanently solve this right now. Originally I thought explicitly referencing the ARM Library include files would work but it did not. By just copying them over the Ubuntu repository opencl_headers I'm worried they might be over written with an apt upgrade in the future. The problem might be related to the version of the ARM library but it appears both are needed for OpenCL to work. sgminer-arm seems to be running fine regardless.

I'm currently running:
Linux c0n0 4.14.5-92 #1 SMP PREEMPT Mon Dec 11 15:48:15 UTC 2017 armv7l armv7l armv7l GNU/Linux
opencl-headers/xenial,now 2.0~svn32091-2 all [installed]
Arm Library v18.03 commit e40997b

Anyone else have a compile problem with a couple of OpenCL calls? Did moving the OpenCL headers as above remedy the problem?
hominoid
 
Posts: 188
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 19, 2018 3:45 am

I am failing all the time by trying the both methods.

Thats the error message I get, when starting sgminer:

Code: Select all
va.cc.
[19:27:10] Startup Pool No = 0
[19:27:10] Initialising kernel ckolivas.cl with nfactor 10, n 1024
[19:28:11] GPUs did not become initialized in 60 seconds...
[19:28:16] Maximum buffer memory device 0 supports says 522586112
[19:28:16] Your settings come to 536870912
[19:28:18] Initialising kernel ckolivas.cl with nfactor 10, n 1024
[19:28:21] Error -6: Creating Kernel from program. (clCreateKernel)
[19:28:21] Failed to init GPU thread 1, disabling device 1
[19:28:21] Restarting the GPU from the menu will not fix this.
[19:28:21] Re-check your configuration and try restarting.
Press enter to continue:



My Kernel is the same:
Code: Select all
Linux MN2 4.14.5-92 #1 SMP PREEMPT Mon Dec 11 15:48:15 UTC 2017 armv7l armv7l armv7l GNU/Linux


I use the original Odroid Ubuntu 16.04. minmal Image "ubuntu-16.04.3-4.14-minimal-odroid-xu4-20171213.img" and had all packages installed incl. update and upgrade.
Installing all the stuff didn't bring up any errors. But some warnings while doing "make -j5".


EDIT:
Okay, found issue. My Mali was setup to "powersave"-Mode... Best to check allways following file:

/sys/devices/platform/11800000.mali/devfreq/devfreq0/governor

:lol:
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 » Mon Mar 19, 2018 6:49 am

Does anybody now, why dualminig cryptonight with xmrig 2.5.0 and sgminer-arm 5.5.6 isn't possible. After few seconds of dual mining, the XU4 will reboot.

This ist what happended in the syslog:
Code: Select all
Mar 18 22:39:24 MN3 systemd[1]: Started Session 2 of user root.
Mar 18 22:39:32 MN3 kernel: [  133.763627] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:39:40 MN3 kernel: [  141.195497] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:39:42 MN3 kernel: [  143.347008] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:39:42 MN3 kernel: [  143.361528] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:39:42 MN3 kernel: [  143.365549] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:39:42 MN3 kernel: [  143.367687] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:39:42 MN3 kernel: [  143.368844] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:39:44 MN3 kernel: [  145.503188] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:39:51 MN3 kernel: [  152.717402] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:39:51 MN3 rsyslogd-2007: action 'action 9' suspended, next retry is Sun Mar 18 22:40:21 2018 [v8.16.0 try http://www.rsyslog.com/e/2007 ]
Mar 18 22:39:53 MN3 kernel: [  154.884442] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:39:53 MN3 kernel: [  154.886343] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:39:53 MN3 kernel: [  154.890373] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:39:53 MN3 kernel: [  154.892476] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:39:53 MN3 kernel: [  154.893653] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:39:55 MN3 kernel: [  157.025886] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:39:59 MN3 xmrig[892]:  * VERSIONS:     XMRig/2.5.0 libuv/1.8.0 gcc/5.4.0
Mar 18 22:39:59 MN3 xmrig[892]:  * HUGE PAGES:   available, disabled
Mar 18 22:39:59 MN3 xmrig[892]:  * CPU:          Unknown (1) -x64 -AES-NI
Mar 18 22:39:59 MN3 xmrig[892]:  * THREADS:      4, cryptonight, av=3, donate=0%, affinity=0xF0
Mar 18 22:39:59 MN3 xmrig[892]:  * POOL #1:      +++++++++++++++++++++++++++
Mar 18 22:39:59 MN3 xmrig[892]:  * POOL #2:      +++++++++++++++++++++++++++
Mar 18 22:39:59 MN3 xmrig[892]:  * COMMANDS:     'h' hashrate, 'p' pause, 'r' resume
Mar 18 22:40:03 MN3 kernel: [  164.261593] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:40:05 MN3 kernel: [  166.416267] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:40:05 MN3 kernel: [  166.418570] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:40:05 MN3 kernel: [  166.422553] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:40:05 MN3 kernel: [  166.424685] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:40:05 MN3 kernel: [  166.425853] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:40:07 MN3 kernel: [  168.558008] mali 11800000.mali: JD: Flushing cache due to PRLAM-10676
Mar 18 22:40:53 MN3 rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="511" x-info="http://www.rsyslog.com"] start
Mar 18 22:40:53 MN3 ureadahead[217]: ureadahead: Error while tracing: No such file or directory
Mar 18 22:40:53 MN3 rsyslogd-2222: command 'KLogPermitNonKernelFacility' is currently not permitted - did you already set it via a RainerScript command (v6+ config)? [v8.16.0 try http://www.rsyslog.com/e/2222 ]
Mar 18 22:40:53 MN3 rsyslogd: rsyslogd's groupid changed to 109
Mar 18 22:40:53 MN3 ureadahead[217]: Counted 8 CPUs


22:39:32 is time when sgminer starts working
22:40:53 is restart time of XU4.
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 rooted » Mon Mar 19, 2018 8:36 am

Power issue perhaps
User avatar
rooted
 
Posts: 5883
Joined: Fri Dec 19, 2014 9:12 am
Location: Gulf of Mexico, US
languages_spoken: english

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

Unread postby hominoid » Mon Mar 19, 2018 11:03 am

Radium78 wrote:I am failing all the time by trying the both methods.

Thats the error message I get, when starting sgminer:

Code: Select all
va.cc.
[19:27:10] Startup Pool No = 0
[19:27:10] Initialising kernel ckolivas.cl with nfactor 10, n 1024
[19:28:11] GPUs did not become initialized in 60 seconds...
[19:28:16] Maximum buffer memory device 0 supports says 522586112
[19:28:16] Your settings come to 536870912
[19:28:18] Initialising kernel ckolivas.cl with nfactor 10, n 1024
[19:28:21] Error -6: Creating Kernel from program. (clCreateKernel)
[19:28:21] Failed to init GPU thread 1, disabling device 1
[19:28:21] Restarting the GPU from the menu will not fix this.
[19:28:21] Re-check your configuration and try restarting.
Press enter to continue:



My Kernel is the same:
Code: Select all
Linux MN2 4.14.5-92 #1 SMP PREEMPT Mon Dec 11 15:48:15 UTC 2017 armv7l armv7l armv7l GNU/Linux


I use the original Odroid Ubuntu 16.04. minmal Image "ubuntu-16.04.3-4.14-minimal-odroid-xu4-20171213.img" and had all packages installed incl. update and upgrade.
Installing all the stuff didn't bring up any errors. But some warnings while doing "make -j5".


EDIT:
Okay, found issue. My Mali was setup to "powersave"-Mode... Best to check allways following file:

/sys/devices/platform/11800000.mali/devfreq/devfreq0/governor

:lol:

Hey @Radium78,
The error I was referring to above only occurs during the actual compile of sgminer. So if sgminer compiled cleanly your good to go; the warnings are normal, ignore them. I don't believe your problem was the GPU power save mode either. If you look at the error messages it says the OpenCL kernel is trying to allocate more memory then it has available. Looks like you need to back off of your GPU settings a little.
Code: Select all
[19:28:16] Maximum buffer memory device 0 supports says 522586112
[19:28:16] Your settings come to 536870912

When you start sgminer-arm and the settings are wrong or too much for the GPU, it can manifest itself in a lot of different ways. The OpenCL kernel can crash, hang or spit out a bunch of different error messages. Below is another clue it is most likely a GPU tuning problem. It couldn't build the OpenCL kernel. This is a very typical message regarding tuning.
Code: Select all
[19:28:21] Error -6: Creating Kernel from program. (clCreateKernel)
[19:28:21] Failed to init GPU thread 1, disabling device 1

With that said, I did have to make choices about specific coin algorithms and OpenCL kernels that had architecture specific setting (not AMD extensions) as indicated in the sgminer-arm 5.5.6-rc1 post. It is why I took the time to highlight which ones might be affected . They may/can be adjusted based on what the GPU(s) can handle or to better optimize ARM-Mali GPU's. Crytponight shouldn't be effected but some others might need the source code modified(tuned) to address any performance issues(they aren't errors per se).

What I usually do when I'm first trying to figure out what the settings should be for a coin I haven't mined, is to start very conservatively(low) with all of the setting and work my way up using trial and error until it starts to fail or the performance starts to drop. Keep in mind that on all ARM-Mali SOC, the GPU shares the main memory with the CPU so there is a dynamic between the two when your dual mining as well. That is why generally you loss some performance on the CPU compared to only mining on the CPU.

My advice is to get one tuned and running by itself and then get the other tuned and running by itself. Then try to run both together but expect to adjust them again accordingly(usually the CPU). Most CPU mining software is going to try and use every system resource it can. You may have to manually set parameters for the CPU miner instead of letting it choose. Likewise, I have had situations where there is such tight memory usage that any other normal process trying to start may cause a system problem(crash, errors etc). It is probably the most likely reason your system rebooted but it could be cooling. You have to monitor CPU temperatures until you know what your rig setup is capable of with the crypto-algorithms your using.

@rooted does makes another good point because I have not done any power utilization testing, only thermal. But I have not seen anything myself with the limited testing done, still a possibility, lots of transistors turned on at once. :) Cryptonight(Monero) is one of the least power intensive crypto-algorithms I have seen. For example, my experience is that it uses approximately 20-25% less power over scrypt(VRM) mining on any of the architectures(ARM, X86 or any GPU) I've used. So power usage can be significantly different between crypto-algorithms. When I get a HK Smartpower2 I'll do some power utilization studies for a better understanding of ARM-Mali power use while dual mining different crypto-algorithms and post the results.

So when dual mining be a little conservative so you allow the rest of the OS to operate, keep an eye on temperature and be aware of power usage until you prove out both(CPU & GPU) configurations and then you can lean into it more. Dual mining pushes these system to the extremes with no problem. I have spent a lot of time tuning. It is why I posted my configurations for the coins I have mined; to give people an idea where to start and save them some trouble.

What coin(s) were you mining? Obviously XMR with xmrig but were you also mining XMR on the GPU? Also, thought I remember there being versions of xmrig that were CPU only, GPU only and also dual CPU/GPU capable so be aware, that wouldn't be good. Though I might be thinking of xmrstake or one of the other dedicated XMR miners. You might want to give multi-cpuminer a try if you still have problems with xmrig. I have used xmrig but not on ARM or while dual mining on any architecture. None of the ARM SBC's can use Hugh Pages, that I'm aware of, so there should be similar performance on ARM devices regardless of the CPU miner. Lastly, This is a new frontier for ARM SBC's so keep in mind you are on the sharp edge of extreme system utilization. Let everyone know how it works out.
hominoid
hominoid
 
Posts: 188
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 Spada » Mon Mar 19, 2018 3:21 pm

None of the ARM SBC's can use Hugh Pages, that I'm aware of, so there should be similar performance on ARM devices regardless of the CPU miner.


I have huge pages enabled on my XU4:

Code: Select all
root@Miner_1:~# sudo sysctl -p
vm.nr_hugepages = 839
root@Miner_1:~#
root@Miner_1:~# cat /proc/cpuinfo  | grep ARM
model name      : ARMv7 Processor rev 3 (v7l)
model name      : ARMv7 Processor rev 3 (v7l)
model name      : ARMv7 Processor rev 3 (v7l)
model name      : ARMv7 Processor rev 3 (v7l)
model name      : ARMv7 Processor rev 3 (v7l)
model name      : ARMv7 Processor rev 3 (v7l)
model name      : ARMv7 Processor rev 3 (v7l)
model name      : ARMv7 Processor rev 3 (v7l)
root@Miner_1:~#
root@Miner_1:~# cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"
NAME="Ubuntu"
VERSION="16.04.3 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.3 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
root@Miner_1:~# uname -a
Linux Miner_1 4.14.0+ #1 SMP PREEMPT Wed Nov 15 21:41:32 UTC 2017 armv7l armv7l armv7l GNU/Linux
root@Miner_1:~#


More information on Verium Mining and Huge Pages on XU4:

https://wiki.vericoin.info/index.php?ti ... _hugepages
Spada
 
Posts: 18
Joined: Tue Oct 18, 2016 1:23 am
languages_spoken: english
ODROIDs: C2, XU4

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

Unread postby Radium78 » Mon Mar 19, 2018 5:35 pm

How does it work? I never get huge pages activated by the usuall commands. Is it only working with verium miner?

Iam mining bytecoin currently. I will give a try to xmrig-stak this evening. Maybe it will work with the newest arm-compute package.

Might be a good idea to increase the swap file, when using dualmining. I am a littlebit worried by so many memory flushing from the mali gpu.

But the gpu performance isn't bad. Around 24H/s for Cryptonotes is almost the same for cpumining only with xmrig (~28H/s with 8core). CPUminer-multi is slower and close the same as SGMiner.

8 and 7 core plus gpu has failed yesterday. I will try also to use the little cores only incl. GPU next few days. And, if it works maybe a throttled down big core test. I guess it wont be a temperature issue, cause it crashes to fast. A power issue is, what it is most look like or a memory issue.
Last edited by Radium78 on Mon Mar 19, 2018 6:03 pm, edited 1 time in total.
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 Spada » Mon Mar 19, 2018 5:47 pm

It's working with Verium miner and it's OS/kernel dependent, so I see no reason why it shouldn't work no matter what you are mining. That output that I've pasted is from an XU4 mining Verium.

See the below link, it may help you (see 'Setup the Image'):

https://wiki.vericoin.info/index.php?title=Odroid
Spada
 
Posts: 18
Joined: Tue Oct 18, 2016 1:23 am
languages_spoken: english
ODROIDs: C2, XU4

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

Unread postby Radium78 » Mon Mar 19, 2018 7:04 pm

Spada wrote:It's working with Verium miner and it's OS/kernel dependent, so I see no reason why it shouldn't work no matter what you are mining. That output that I've pasted is from an XU4 mining Verium.

See the below link, it may help you (see 'Setup the Image'):

https://wiki.vericoin.info/index.php?title=Odroid


Thats the point. I can put the hugepage settings into /etc/sysctl.conf but it doesn't matter.
Is this Image an optimized ubuntu 16.04.?
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 Spada » Mon Mar 19, 2018 7:17 pm

It's optimized for Verium mining.

According to Vericoin/Verium wiki:

Code: Select all
Odroids Official Images are of course very well made. The newest Ubuntu Mate 16.04.3 (20171212) which was release after birtys image even has hugepages enabled.


I haven't tried it, so I cannot confirm it, but the 20171212 release (official release, not optimized) should have it:

https://odroid.in/ubuntu_16.04lts/
Spada
 
Posts: 18
Joined: Tue Oct 18, 2016 1:23 am
languages_spoken: english
ODROIDs: C2, XU4

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

Unread postby hominoid » Tue Mar 20, 2018 12:49 am

Spada wrote:I have huge pages enabled on my XU4:

What are you swapping to? Do you have a SSD or HD setup for your rootfs and swap? Most SBC's are SDCard or maybe emmc, I've worried about using these devices with a swap partition. I've also kept to standard kernels and image releases for development, testing and deployment to the community at large for easy duplication by a wide range of users. I'm not aware of any HK image using a swap partition. Sounds like your using @birty's image? I PM'ed @Birty when I got sgminer going originally and he had indicated he had been working on getting OpenCL running as well, haven't heard from him since. Early on I'd had tried to get zram running to free up more memory but got distracted by other things and haven't revisited it, he might be using it.
Radium78 wrote:But the gpu performance isn't bad. Around 24H/s for Cryptonotes is almost the same for cpumining only with xmrig (~28H/s with 8core). CPUminer-multi is slower and close the same as SGMiner.

8 and 7 core plus gpu has failed yesterday...I guess it wont be a temperature issue, cause it crashes to fast. A power issue is, what it is most look like or a memory issue.

What kind of cooling are you using at what CPU frequency? I have seen system reboots within seconds under extreme loads. I would not be so fast as to rule out temperature without monitoring it. I use watchtemp.sh when testing configurations under kernel 4.x. You might need to go to a 1 second interval instead of 2. I would also try just a couple of threads on the xmrig side just to verify things work first. Your using a lot of system resource so memory is a good second choice IMO.
Radium78 wrote:Iam mining bytecoin currently.

This is on the GPU using sgminer-5.5.6-ARM-RC1 or the CPU's? I want to keep track of what has been used/tested on sgminer-arm to verify each crypto-algorithm. Regarding performance, Xmrig I believe has assembler optimization, I removed the INTEL assembler in cryptonight.c and used c code instead of ARM assembler to maintain a CPU agnostic release. It definitely is one area for optimization but I wasn't ready to tackle the Armv7 and Armv8 difference yet.
watchtemp.sh
Code: Select all
#!/bin/bash
z=0
echo "T, Freq4,   Freq5,   Freq6,   Freq7,   T4, T5, T6, T7, TGPU"

while true :
do
     fa=`cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq`
     fb=`cat /sys/devices/system/cpu/cpu5/cpufreq/scaling_cur_freq`
     fc=`cat /sys/devices/system/cpu/cpu6/cpufreq/scaling_cur_freq`
     fd=`cat /sys/devices/system/cpu/cpu7/cpufreq/scaling_cur_freq`
     s1=`cat /sys/devices/virtual/thermal/thermal_zone0/temp`
     s1t=$(($s1/1000))
     s2=`cat /sys/devices/virtual/thermal/thermal_zone1/temp`
     s2t=$(($s2/1000))
     s3=`cat /sys/devices/virtual/thermal/thermal_zone2/temp`
     s3t=$(($s3/1000))
     s4=`cat /sys/devices/virtual/thermal/thermal_zone3/temp`
     s4t=$(($s4/1000))
         g1=`cat /sys/devices/virtual/thermal/thermal_zone4/temp`
     g1t=$(($g1/1000))

     echo $z, $fa, $fb, $fc, $fd, $s1t, $s2t, $s3t, $s4t, $g1t
     sleep 2
     (( z += 2 ))
done
hominoid
 
Posts: 188
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 » Tue Mar 20, 2018 2:49 am

Spada wrote:It's optimized for Verium mining.

According to Vericoin/Verium wiki:

Code: Select all
Odroids Official Images are of course very well made. The newest Ubuntu Mate 16.04.3 (20171212) which was release after birtys image even has hugepages enabled.


I haven't tried it, so I cannot confirm it, but the 20171212 release (official release, not optimized) should have it:

https://odroid.in/ubuntu_16.04lts/


Yes, it is enabled, but not used by xmrig. I don't know the reson why. xmrig wrotes "huge page available, disabled". The use of VeriumMiner image is waste of time if not mining verium. It's full configurated and it seem there ist some virtual image runnig and blocking 1.76G of the memory.
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 » Tue Mar 20, 2018 3:28 am

Am I mistaken thinking this requires a swap partition?
hominoid
 
Posts: 188
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 » Tue Mar 20, 2018 5:30 am

hominoid wrote:
Radium78 wrote:But the gpu performance isn't bad. Around 24H/s for Cryptonotes is almost the same for cpumining only with xmrig (~28H/s with 8core). CPUminer-multi is slower and close the same as SGMiner.

8 and 7 core plus gpu has failed yesterday...I guess it wont be a temperature issue, cause it crashes to fast. A power issue is, what it is most look like or a memory issue.

What kind of cooling are you using at what CPU frequency? I have seen system reboots within seconds under extreme loads. I would not be so fast as to rule out temperature without monitoring it. I use watchtemp.sh when testing configurations under kernel 4.x. You might need to go to a 1 second interval instead of 2. I would also try just a couple of threads on the xmrig side just to verify things work first. Your using a lot of system resource so memory is a good second choice IMO.
Radium78 wrote:Iam mining bytecoin currently.

This is on the GPU using sgminer-5.5.6-ARM-RC1 or the CPU's? I want to keep track of what has been used/tested on sgminer-arm to verify each crypto-algorithm. Regarding performance, Xmrig I believe has assembler optimization, I removed the INTEL assembler in cryptonight.c and used c code instead of ARM assembler to maintain a CPU agnostic release. It definitely is one area for optimization but I wasn't ready to tackle the Armv7 and Armv8 difference yet.
watchtemp.sh


Okay, it is a temp issue. I reduced the frequency from core 4-7 to 1600M and it works for a long time. I use the XU4Q passive cooling with external 92mm silent cooler (1 for 2 XU4Q) running on 5volts. Need to tune up to 12volt ;-)
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 » Wed Mar 21, 2018 2:11 am

hominoid wrote:Am I mistaken thinking this requires a swap partition?


I dont think so. I've install swap with 1G and thats what I get wenn I want install Hugepages:

Code: Select all
root@MN2:~# sysctl -w vm.nr_hugepages=839
sysctl: cannot stat /proc/sys/vm/nr_hugepages: No such file or directory


XMRIG tells me always teh same:
Code: Select all
[2018-03-20 17:53:35]  * VERSIONS:     XMRig/2.5.0 libuv/1.8.0 gcc/5.4.0
[2018-03-20 17:53:35]  * HUGE PAGES:   available, disabled
[2018-03-20 17:53:35]  * CPU:          Unknown (1) -x64 -AES-NI
[2018-03-20 17:53:35]  * THREADS:      8, cryptonight, av=3, donate=0%, affinity=0xFF
[2018-03-20 17:53:35]  * POOL #1:      +++
[2018-03-20 17:53:35]  * POOL #2:      +++
[2018-03-20 17:53:35]  * COMMANDS:     'h' hashrate, 'p' pause, 'r' resume


HUGE PAGES: available, disabled means huge page available but mem allocation failed. I will try birty-Image. Maybe he does something diffrent, otherwise I guess XMRIG will not support huge pages with ARM-processors. With Win it's working but only when run as admin or UAC disable.


EDIT: Okay tested Birty Image
It works with huge pages, but there is no speed up when using cryptonight. Always the 28H/s with 8cores @ 1.4Ghz/1.9Ghz.
Iam just wondering of 1.76G memory are blocked. Installing XMRIG was a mess because of running out of memory failures. Could only add a swap to not fail installation.
Also a negative side effect is, the XU4 runs very slow without cpu load. Giv'in up dual mining with birtys image, SGMINER will reserve at least about 600M RAM. In this configuration, that will never work.
It looks like birty has run a virtual image to realize the huge page. U can adjust huge page in /etc/sysctl.conf, but ist doesn't take any effect on the memory usage. Same is for "sysctl -w vm.nr_hugepages=xxx. It works but does not take any effect after reboot. So waste of time, don't know if the speed will cut of by overloaded memory....
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 » Thu Mar 22, 2018 8:57 am

The only system I've personally seen an improvement by using hugh pages is an Intel dual Xeon E5-2660v2 64GB server I run with 40 threads. It was definitely swapping and by using hugh pages I gained approximately a 13% improvement. I have other 32 core servers with 32GB that saw no improvement but they don't need to use the swap space. Could never get it running on any of the SBC's and I don't think running swap on an SDCard or emmc is a long term practical solution anyway. @birty might be getting his performance bump from reducing the kernel size so an extra thread can be used. It might not have anything to do with hugh pages. It is an area I was going to look at for the XU4 but too many other projects I want to spend time on. I think cooling and possibly reducing the kernel size are the best approaches that might help the XU4. Zram might be worth looking at as well. I have a different cooling approach that I'm going to explore when I get some free time.

One other point I'll mention in case your not aware, cryptonight is cache intensive so there is an optimal point based on CPU cache size, not on thread count or memory amount. A lot of people report lower hash rates when you exceed it, even if running more threads. But, 28h/m is a could number IMO. Also FYI, from my testing so far I have found the Mali-T628 in general can perform about on par with the CPU across different crypto-algorithm's.
hominoid
 
Posts: 188
Joined: Tue Feb 28, 2017 3:55 am
Location: Lake Superior Basin, USA
languages_spoken: english
ODROIDs: C2, XU4, MC1, N1

Next

Return to Projects

Who is online

Users browsing this forum: No registered users and 4 guests