Crypto Currency Mining

[m00se]

I would like to try mining crypto currency on my N2. So far I have tried Magi and Vericoin. In both cases the wallet fails to compile. In Magi, xCPUARCH=aarch64 is not recognized and other ARM types fail. The install script I found for verium failed to create veriumd after a bunch of compiler errors.

What am I doing wrong?

[meveric]

could be that you need arm64 as xCPUARCH and not aarch64

also a comment like:

The install script I found for verium failed to create veriumd after a bunch of compiler errors.

What am I doing wrong?

Is not really helpful... it's like... "My computer shows an error and doesn't work, what am I doing worng?"
You might actually want to show the "bunch of compiler errors" so people can tell you how to fix them.

[m00se]

"arm64" returns the same error that "aarch64" does:

g++: error: unrecognized command line option ‘-msse2’
makefile.unix:186: recipe for target 'obj/checkpoints.o' failed

Here are a couple of errors from the Verium compiler.

bignum.h: In constructor ‘CBigNum::CBigNum(int64)’:
bignum.h:86:35: error: ‘BN_init’ was not declared in this scope
CBigNum(int64 n) { BN_init(this); setint64(n); }
^~~~~~~
bignum.h:86:35: note: suggested alternative: ‘BN_print’
CBigNum(int64 n) { BN_init(this); setint64(n); }
^~~~~~~
BN_print



In file included from main.h:8:0,
from txdb.h:8,
from checkpoints.cpp:10:
bignum.h: In member function ‘void CBigNum::setint64(int64)’:
bignum.h:165:37: error: cannot convert ‘CBigNum*’ to ‘BIGNUM* {aka bignum_st*}’ for argument ‘3’ to ‘BIGNUM* BN_mpi2bn(const unsigned char*, int, BIGNUM*)’
BN_mpi2bn(pch, p - pch, this);
^
bignum.h: In member function ‘uint64 CBigNum::getuint64()’:
bignum.h:170:50: error: cannot convert ‘CBigNum*’ to ‘const BIGNUM* {aka const bignum_st*}’ for argument ‘1’ to ‘int BN_bn2mpi(const BIGNUM*, unsigned char*)’
unsigned int nSize = BN_bn2mpi(this, NULL);
^

[meveric]

g++: error: unrecognized command line option ‘-msse2’
makefile.unix:186: recipe for target 'obj/checkpoints.o' failed

this means somewhere it sets the option -msse2 which is only valid for x86/amd64 processors not for ARM processors and therefore need to be removed.
Check the different make files involved for example that makefile.unix you list here... and remove the -msse2 entries.

Here are a couple of errors from the Verium compiler.

bignum.h: In constructor ‘CBigNum::CBigNum(int64)’:
bignum.h:86:35: error: ‘BN_init’ was not declared in this scope
CBigNum(int64 n) { BN_init(this); setint64(n); }
^~~~~~~
bignum.h:86:35: note: suggested alternative: ‘BN_print’
CBigNum(int64 n) { BN_init(this); setint64(n); }
^~~~~~~
BN_print



In file included from main.h:8:0,
from txdb.h:8,
from checkpoints.cpp:10:
bignum.h: In member function ‘void CBigNum::setint64(int64)’:
bignum.h:165:37: error: cannot convert ‘CBigNum*’ to ‘BIGNUM* {aka bignum_st*}’ for argument ‘3’ to ‘BIGNUM* BN_mpi2bn(const unsigned char*, int, BIGNUM*)’
BN_mpi2bn(pch, p - pch, this);
^
bignum.h: In member function ‘uint64 CBigNum::getuint64()’:
bignum.h:170:50: error: cannot convert ‘CBigNum*’ to ‘const BIGNUM* {aka const bignum_st*}’ for argument ‘1’ to ‘int BN_bn2mpi(const BIGNUM*, unsigned char*)’
unsigned int nSize = BN_bn2mpi(this, NULL);
^

There are some "was not declared in this scope" errors which normally means an header file was not loaded correctly or does not exist.

Seems your entire software was not made for arm and therefore might not work.

[m00se]

meveric - Thanks for the tip on removing the msse2 directive. In makefile.unix there is a clause that looks for xCPUTYPE of armv6l or armv7l. If either of those is true then the msse2 instruction is excluded. I added "aarch64" to the list, which solved that problem. It then ran in to syntax errors having to do with a space between a literal and a string macro. Fixed that in four or five files. Now I have errors that resemble the errors from Verium - "invalid use of incomplete type 'BIGNUM...". This appears to be a problem between fibering, boost, and the installed version of openssl. Which leads me to believe either I'm trying to compile old code or this wallet depends on older system components. Sigh.

[hominoid]

...Now I have errors that resemble the errors from Verium - "invalid use of incomplete type 'BIGNUM...". This appears to be a problem between fibering, boost, and the installed version of openssl. Which leads me to believe either I'm trying to compile old code or this wallet depends on older system components. Sigh.

You are correct, there are several dependency issues for the Verium wallet on 18.04, specifically boost and openssl. I worked on it for awhile but there was just to many in regards to boost and all its various libraries. I was working on an XU4 so it was just easier to go back to 16.04. If solo mining verium is what you want to do you could run your wallet on another machine (windows or Linix 16.04) and point your N2 at it.

Since the crypto crash I have been running BOINC when my machines are sitting idle which Gridcoin use as POW. Just need to load the boinc-client from whatever distribution your running and join a pool. It has the added value of helping scientific research in the field of your choosing. Many BOINC projects support Linux ARM7 and ARM8 (seti@home, universe@home and einstein@home for physics and astronomy, TN-Grid for genetics, LHC@home for the CERN particle accelerator, etc). It is a lot better use of the watts then the do nothing algorithms of most crypto coins IMO.

[m00se]

Hi Hominoid,

I'm giving BOINC a try. I have it mining SETI@HOME at the moment and seems to be working well. Looks like it takes between 8 and 9 hours to complete one unit of work. However, I'm unclear on the Gridcoin wallet - I have downloaded all of the blocks, but it still says "out of sync". I'm running it in investor mode per (most) of the directions I found.

[m00se]

Correction - 7:46 per unit estimated.

[hominoid]

Hi Hominoid,

I'm giving BOINC a try. I have it mining SETI@HOME at the moment and seems to be working well. Looks like it takes between 8 and 9 hours to complete one unit of work. However, I'm unclear on the Gridcoin wallet - I have downloaded all of the blocks, but it still says "out of sync". I'm running it in investor mode per (most) of the directions I found.

Great, the times can vary depending on the project, and even within a project, from a couple of hours to a couple of days. You can always abort any job that is to long for your situation. Not sure about your wallet issue but it might be that you need to wait until the next superblock on the blockchain. I thing that is when new addresses(wallets) are announced. It happens about once a day, so be patient. You should not have to post a beacon or stay online, just check back. A couple of other things that might be helpful.

You can manage more than one bonic-client from a single boinc-manager. On the boinc-client edit /var/lib/boinc-client/remote_hosts.cfg and uncomment and change the IP address to the boinc-manger's address. Then in the boinc-manager you can select the remote boinc-client from the menu File>Select Computer. The first time you have to type the host name and then it will appear in the drop down menu moving forward. I mange many headless machines using this method.

If you want to change the project for a pool machine, detach it first from within the host entry in the pool interface and then resync that boinc-client from within the boinc-manager; aftewards the project will be removed from the machine. If you forget to do that before deleting it within the pool host page, add the project back to the host, save the change and then detach, save and then re-sync the client from the boinc-manger.

I'm sure you figured this out already but for anyone else that might want to try it, every pooled boinc-client has to be added in the boinc-manager by using the menu Tools>Use Account Manager after selecting the remote boinc-client. Projects added otherwise are not pooled and are running solo and not accumulating pool credit.
Have fun...

[mad_ady]

Glad to see people are investing time in boinc. I've been crunching numbers for them on my work pc for 13 years...
And before that, in the early 2000s I remember seti at home had a nice fft graph I would watch scroll by, waiting for the illusive green men.

[m00se]

Great, the times can vary depending on the project, and even within a project, from a couple of hours to a couple of days. You can always abort any job that is to long for your situation. Not sure about your wallet issue but it might be that you need to wait until the next superblock on the blockchain. I thing that is when new addresses(wallets) are announced. It happens about once a day, so be patient. You should not have to post a beacon or stay online, just check back. A couple of other things that might be helpful.

I'm learning My first couple of completed units were done directly through BOINC without a pool... so no gridcoin for those. That has been corrected. The units that completed took a little over 7 hours each. I think my wallet issue is that it hasn't finished downloading the blockchain yet. I downloaded the zip file, which brought me to block 1440841. I believe there are something like 1.6M blocks, so it has a little way to go yet. It kept getting "stuck" and I assumed each time it does that it was done, but that was before I saw the total count.

[m00se]

Glad to see people are investing time in boinc. I've been crunching numbers for them on my work pc for 13 years...
And before that, in the early 2000s I remember seti at home had a nice fft graph I would watch scroll by, waiting for the illusive green men.

I remember the screen saver Ahhh, the good old days. I didn't find any little green men either.

[m00se]

Is it possible for an admin or moderator to fix my typo in the subject?

[hominoid]

@m00se, you might be able to correct the topic typo yourself by editing your first post, not sure.

@mad_ady, that must be what I'm doing wrong, I've been looking for purple ones

[m00se]

@hominoid - That worked. Thanks!

Can you confirm the current number of blocks in Gridcoin?

[hominoid]

So just for clarity...anyone wanting to mine Gridcoin using boinc:

1. Signup at www.grcpool.com
2. Load the GUI boinc-manager on a host

Code: Select all

sudo apt install boinc-manager

For each remote boinc-client you have repeat the following steps:

3. Load boinc client software (There is also a boinc-client-opencl but I have not found any current projects that support Mali GPU's)

Code: Select all

sudo apt install boinc-client

4. To manage multiple boinc-clients with a single GUI boinc manager set the IP address of the boinc-manager host for each boinc-client

Code: Select all

sudo vi /var/lib/boinc-client/remote_hosts.cfg

5. Set RPC password or not

Code: Select all

vi /var/lib/boinc-client/gui_rpc_auth.cfg

6. Start the boinc-manager. IMO it is easier to use the Boinc Manager's advanced view when setting up clients. menu View>Advanced View. Select the boinc client using the menu File>Select Computer, type the host name the first time, cancel out of the automatic project selection dialog box and then goto the menu Tools>Use Account Manager. Type in the pool URL www.grcpool.com as the account manager when prompted. Use the same login and password that you use for your pool login. This will add the boinc client in your pool's host page.

7. Goto the pool and select your new host and add the project(s) for that client and save.

8. Goto back to the boinc manager and select the boinc client, if not already selected, using menu File>Select Computer and then select the Project Tab. You should have a new menu entry under the menu Tools. Select the menu Tools>Synchronize with grcpool.com
This should add the project(s) you added in the pool host interface to the boinc client. It will automaticly download the appropriate application and data for the project(s) and start to run the assigned jobs.

9. repeat steps 3-8 for each boinc client.

Notes:
Do NOT Add a project from the boinc-manager for a client unless you don't want it to pool mine. All projects for pool credit are added, detached and removed through the pool host interface. re-synchronize a boinc client after project changes by selecting it in the boinc manager and then use the menu Tools>Synchronize with grcpool.com

Unlike normal boinc operation, you do NOT need to create a login at each projects web page.

For each boinc client set resource preferences under menu Options>Computing Preferences.

And finally, do NOT plan on getting rich. It will most likely cost you money depending on your KW Cost. Just support scientific research and have fun with it; at least that's why I do it.

[hominoid]

@hominoid - That worked. Thanks!

Can you confirm the current number of blocks in Gridcoin?

Current GRC Block 1615118 at 20:03 EST

Gridcoin Useful Links
Gridcoin Block Explorer
Gridcoin Projects List
Gridcoin Projects White List
Gridcoin Projects Status
BOINC Projects and usable CPU/GPU Architectures

[Northstar]

I would like to try mining crypto currency on my N2. So far I have tried Magi and Vericoin. In both cases the wallet fails to compile. In Magi, xCPUARCH=aarch64 is not recognized and other ARM types fail. The install script I found for verium failed to create veriumd after a bunch of compiler errors.

What am I doing wrong?

Which scrypt have you take for verium?
The problem with verium wallet for 18.04 is the gui version. This one is compatible with Ubuntu 16.04, but you can run it in docker on your 18.04.
The non-GUI wallet version run on 18.04.
when you run only 1 N2 for verium, it is better you mine on Pool.
Have your N2, 4 or 2gb RAM?

[m00se]

@Hominoid - That's the best Gridcoin/BOINC guide I've seen anywhere. Thank you!

@Northstar - I downloaded the current project for Verium. When it didn't compile I deleted the whole thing. I might revisit Verium in the future, but I'm going to run BOINC for now. My N2 is the 4GB model.

[m00se]

So which is the better miner - N2 with six cores or the XU4 with eight somewhat slower (I assume) cores?

[hominoid]

So which is the better miner - N2 with six cores or the XU4 with eight somewhat slower (I assume) cores?

The Odroid-N2 is going to out perform the Odroid-XU4 due to more powerful CPU, GPU, more memory and better thermals. In prior run of BOINC seti@home of about 2 weeks approximate RAC values of:

Odroid-XU4 20,000 (A15@1.8Ghz, A7@1.5Ghz)
Odorid-N2 35,000 (A73@1.8Ghz, A53@1.9Ghz)

Keep in mind RAC is based on a 30 day average so this doesn't show full potential just a comparison. Cluster 2 and 4 are Odroid-XU4's with cluster c4n0-c4n2(MC-1@1.8Ghz) running the same project and time duration as the Odroid-N2 and N1, all hosts CPU only, all actively cooled (N2 Cooling). This is from a few days ago before project change ups. I was running c4n3 at either 1.7Ghz or 1.6Ghz, I don't remember.

Screenshot_2019-05-27_17-01-00.png (79.93 KiB) Viewed 1648 times

[m00se]

Does the GPU make any difference in the N2?

[hominoid]

For boinc, no projects I'm aware of use a Mali GPU. They are recognized as OpenCL capable but each project is different on what hardware they support. Right now if a project supports an OpenCL GPU its AMD, NVIDIA and INTEL only. You can dual GPU/CPU mine other crypto currancies using the N2 and Mali G52 as demonstarted in the N2 cooling link above. There is also a comparison of the Mali G52 and other Odroid Mali GPU's mining to get a comparative idea of performance.
If you are going to use the GPU make sure the command clinfo reports your GPU correctly.

Code: Select all

sudo apt install clinfo

If it says "0 devices" try the following commands. The Ubuntu Minimal image, and others, usually do not have the icd file setup for Mali GPU's.

Code: Select all

sudo mkdir -p /etc/OpenCL/vendors
sudo echo "libOpenCL.so" > /etc/OpenCL/vendors/mali.icd

For the N2 clinfo should look like this:

Code: Select all

hominoid@odroid-n2:~/$ clinfo
Number of platforms                               2
  Platform Name                                   ARM Platform
  Platform Vendor                                 ARM
  Platform Version                                OpenCL 2.0 git.c8adbf9.122c9daed32dbba4b3056f41a2f23c58
  Platform Profile                                FULL_PROFILE
  Platform Extensions                             cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_fp16 cl_khr_icd cl_khr_egl_image cl_khr_image2d_from_buffer cl_khr_depth_images cl_khr_subgroups cl_khr_create_command_queue cl_arm_core_id cl_arm_printf cl_arm_thread_limit_hint cl_arm_non_uniform_work_group_size cl_arm_import_memory cl_arm_shared_virtual_memory
  Platform Extensions function suffix             ARM

  Platform Name                                   Clover
  Platform Vendor                                 Mesa
  Platform Version                                OpenCL 1.1 Mesa 18.2.8
  Platform Profile                                FULL_PROFILE
  Platform Extensions                             cl_khr_icd
  Platform Extensions function suffix             MESA

  Platform Name                                   ARM Platform
Number of devices                                 1
  Device Name                                     Mali-G52
  Device Vendor                                   ARM
  Device Vendor ID                                0x72120000
  Device Version                                  OpenCL 2.0 git.c8adbf9.122c9daed32dbba4b3056f41a2f23c58
  Driver Version                                  2.0
  Device OpenCL C Version                         OpenCL C 2.0 git.c8adbf9.122c9daed32dbba4b3056f41a2f23c58
  Device Type                                     GPU
  Device Profile                                  FULL_PROFILE
  Device Available                                Yes
  Compiler Available                              Yes
  Linker Available                                Yes
  Max compute units                               2
  Max clock frequency                             750MHz
  Device Partition                                (core)
    Max number of sub-devices                     0
    Supported partition types                     None
  Max work item dimensions                        3
  Max work item sizes                             384x384x384
  Max work group size                             384
  Preferred work group size multiple              8
  Preferred / native vector sizes                 
    char                                                16 / 4       
    short                                                8 / 2       
    int                                                  4 / 1       
    long                                                 2 / 1       
    half                                                 8 / 2        (cl_khr_fp16)
    float                                                4 / 1       
    double                                               0 / 0        (n/a)
  Half-precision Floating-point support           (cl_khr_fp16)
    Denormals                                     Yes
    Infinity and NANs                             Yes
    Round to nearest                              Yes
    Round to zero                                 Yes
    Round to infinity                             Yes
    IEEE754-2008 fused multiply-add               Yes
    Support is emulated in software               No
  Single-precision Floating-point support         (core)
    Denormals                                     Yes
    Infinity and NANs                             Yes
    Round to nearest                              Yes
    Round to zero                                 Yes
    Round to infinity                             Yes
    IEEE754-2008 fused multiply-add               Yes
    Support is emulated in software               No
    Correctly-rounded divide and sqrt operations  No
  Double-precision Floating-point support         (n/a)
  Address bits                                    64, Little-Endian
  Global memory size                              3887726592 (3.621GiB)
  Error Correction support                        No
  Max memory allocation                           971931648 (926.9MiB)
  Unified memory for Host and Device              Yes
  Shared Virtual Memory (SVM) capabilities        (core)
    Coarse-grained buffer sharing                 Yes
    Fine-grained buffer sharing                   No
    Fine-grained system sharing                   No
    Atomics                                       No
  Shared Virtual Memory (SVM) capabilities (ARM)  
    Coarse-grained buffer sharing                 Yes
    Fine-grained buffer sharing                   No
    Fine-grained system sharing                   No
    Atomics                                       No
  Minimum alignment for any data type             128 bytes
  Alignment of base address                       1024 bits (128 bytes)
  Preferred alignment for atomics                 
    SVM                                           0 bytes
    Global                                        0 bytes
    Local                                         0 bytes
  Max size for global variable                    65536 (64KiB)
  Preferred total size of global vars             0
  Global Memory cache type                        Read/Write
  Global Memory cache size                        131072 (128KiB)
  Global Memory cache line size                   64 bytes
  Image support                                   Yes
    Max number of samplers per kernel             16
    Max size for 1D images from buffer            65536 pixels
    Max 1D or 2D image array size                 2048 images
    Base address alignment for 2D image buffers   32 bytes
    Pitch alignment for 2D image buffers          64 pixels
    Max 2D image size                             65536x65536 pixels
    Max 3D image size                             65536x65536x65536 pixels
    Max number of read image args                 128
    Max number of write image args                64
    Max number of read/write image args           64
  Max number of pipe args                         16
  Max active pipe reservations                    1
  Max pipe packet size                            1024
  Local memory type                               Global
  Local memory size                               32768 (32KiB)
  Max number of constant args                     8
  Max constant buffer size                        65536 (64KiB)
  Max size of kernel argument                     1024
  Queue properties (on host)                      
    Out-of-order execution                        Yes
    Profiling                                     Yes
  Queue properties (on device)                    
    Out-of-order execution                        Yes
    Profiling                                     Yes
    Preferred size                                2097152 (2MiB)
    Max size                                      16777216 (16MiB)
  Max queues on device                            1
  Max events on device                            1024
  Prefer user sync for interop                    No
  Profiling timer resolution                      1000ns
  Execution capabilities                          
    Run OpenCL kernels                            Yes
    Run native kernels                            No
  printf() buffer size                            1048576 (1024KiB)
  Built-in kernels                                
  Device Extensions                               cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_fp16 cl_khr_icd cl_khr_egl_image cl_khr_image2d_from_buffer cl_khr_depth_images cl_khr_subgroups cl_khr_create_command_queue cl_arm_core_id cl_arm_printf cl_arm_thread_limit_hint cl_arm_non_uniform_work_group_size cl_arm_import_memory cl_arm_shared_virtual_memory

  Platform Name                                   Clover
Number of devices                                 0

NULL platform behavior
  clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...)  ARM Platform
  clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...)   Success [ARM]
  clCreateContext(NULL, ...) [default]            Success [ARM]
  clCreateContext(NULL, ...) [other]              <error: no devices in non-default plaforms>
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT)  Success (1)
    Platform Name                                 ARM Platform
    Device Name                                   Mali-G52
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU)  Success (1)
    Platform Name                                 ARM Platform
    Device Name                                   Mali-G52
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM)  No devices found in platform
  clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL)  Success (1)
    Platform Name                                 ARM Platform
    Device Name                                   Mali-G52

ICD loader properties
  ICD loader Name                                 OpenCL ICD Loader
  ICD loader Vendor                               OCL Icd free software
  ICD loader Version                              2.2.11
  ICD loader Profile                              OpenCL 2.1

[m00se]

@Hominoid As always, thank you for the info. I tried Boinc on my HC2. Running on all eight cores was a bad idea - temp spiked to 236 degrees F. I may move it to a location with better ventilation and try again. It "idles" at about 120 in it's present habitat.

[mad_ady]

@m00se: You should limit big core frequency to 1600/1400MHz. It has big impact on temperature. High temperature will also throttle the cores.

[hominoid]

I agree with @mad_ady and you might want to consider a fan on that HC2 heatsink as well. Everything I'm running boinc on is actively cooled.

[m00se]

The N2 is around 140F with all six cores running at default frequency. Do I need to limit the frequency? I limited the big cores on the HC2 - I'm only running two BOINC processes on it. Temp is around 150F at 1.5Ghz. Temp was int the mid 140s running one BOINC process at 1.8Ghz.

[hominoid]

I think your fine on the N2 and the HC2 at those temperatures. I'll clock my XU4's to run 24/7 at 70c(158f) or lower and that is fairly conservative IMO. Just keep a watch on them as ambient temperatures fluctuate. If you want to run them harder you can add cooling.

[m00se]

I thought of another issue on the HC2- I don't want to cook my Ironwolf. I now have it running three Boinc processes at 1.1 ghz. I may push it a little harder, but I want to keep the disk at 45C.

[m00se]

I notice that I can limit CPU time in the BOINC app. Is there any advantage/disadvantage to this vs reducing the clock on the CPU? On my HC2 I'm currently limiting CPU time in the BOINC manager and running the CPUs at full speed. My logic is that if something else needs the CPU it can get maximum performance if needed.

Also, do you run more than one project at a time or focus on just one per host?

[Toggleton]

The CPU TIME is AFAIK if it set to 75% it goes like 3sec work - 1sec idle... It think it was made for Laptops to not overheat.
Boinc does run at a low priority/high nice, so normaly if something needs CPU power, it can take it without problem.

[m00se]

The CPU TIME is AFAIK if it set to 75% it goes like 3sec work - 1sec idle... It think it was made for Laptops to not overheat.
Boinc does run at a low priority/high nice, so normaly if something needs CPU power, it can take it without problem.

That's exactly what I'm using it for - to prevent overheating on the HC2. I was just curious which is the better method - letting BOINC manage it's CPU use or reducing the clock on the CPUs, which has the down side of also "throttling" other services.

[mad_ady]

CPU frequency scaling (ondemand) will probably keep the cores still high if there is just a second in load pause. You can run boinc at times of day where you don't expect user load (at night) and lower/raise top frequency with a cron job during that time.

[Toggleton]

Also, do you run more than one project at a time or focus on just one per host?

I run LHC@home on my Odroids with Universe@home as backup with "Resource share" 0 it will only ask for work from the Backup if your main Project has no task to send/is down.
(If you use the grcpool on the page of the Host https://www.grcpool.com/account/hosts)

[hominoid]

I have been running one project per host and controlling temps by varying core frequency. @mad_ady's script odroid-cpu-control works great, if your not familiar with it already. I also combine it with pssh to control thermal groups using host files.

[hominoid]

Here are a couple of errors from the Verium compiler.

bignum.h: In constructor ‘CBigNum::CBigNum(int64)’:
bignum.h:86:35: error: ‘BN_init’ was not declared in this scope
CBigNum(int64 n) { BN_init(this); setint64(n); }
^~~~~~~
bignum.h:86:35: note: suggested alternative: ‘BN_print’
CBigNum(int64 n) { BN_init(this); setint64(n); }
^~~~~~~
BN_print



In file included from main.h:8:0,
from txdb.h:8,
from checkpoints.cpp:10:
bignum.h: In member function ‘void CBigNum::setint64(int64)’:
bignum.h:165:37: error: cannot convert ‘CBigNum*’ to ‘BIGNUM* {aka bignum_st*}’ for argument ‘3’ to ‘BIGNUM* BN_mpi2bn(const unsigned char*, int, BIGNUM*)’
BN_mpi2bn(pch, p - pch, this);
^
bignum.h: In member function ‘uint64 CBigNum::getuint64()’:
bignum.h:170:50: error: cannot convert ‘CBigNum*’ to ‘const BIGNUM* {aka const bignum_st*}’ for argument ‘1’ to ‘int BN_bn2mpi(const BIGNUM*, unsigned char*)’
unsigned int nSize = BN_bn2mpi(this, NULL);
^

I recently spent some time trying to solve the compile errors for the Verium wallet under 18.04. The easy fix for both the N2 and XU4 is to substitute the dependency libssl1.0-dev for libssl-dev.

Code: Select all

sudo apt-get install libssl1.0-dev

I compiled it successfully on the N2 and XU4 and then synced up with the blockchain and ran veriumd CLI for a few days with no problems on a dedicated headless XU4.

Code: Select all

sudo apt-get install build-essential libboost-dev libboost-system-dev libboost-filesystem-dev libboost-program-options-dev libboost-thread-dev libssl1.0-dev libdb++-dev libminiupnpc-dev libboost-all-dev libqrencode-dev freeglut3-dev git libcurl4-gnutls-dev libminizip-dev
git clone https://github.com/VeriumReserve/verium
cd verium/src
make -f makefile.unix