On October 8th, Scavenger 1.6 was announced, which is pretty exciting for us miners using Linux on a 32-bit ODROID-XU4! Not only does the 1.6 update add support for 32-bit machines using ARM7, but it also has NEON support! Scavenger 1.6 can be downloaded on the PoC-Consortium GitHub page here.
Previously, I had started a little work on a few projects that might have sped up my mining rig, including porting Blago’s miner, adding NEON support to creepMiner and porting the original Scavenger to a 32-bit version. I had even started building my own miner in C++, but only gotten as far as setting up a decent system for terminal output and cURL based comms. I just haven’t had the time to get back to any of these projects due to my day job keeping me busy. Anyway, long story short — it looks like the PoCC folks have added JUST what I’ve been after!
If this miner truly does show a decent improvement, I may (if funds allow) be able to add on some extra drives to the lil’ ODROID system.
Setting up Scavenger 1.6.0
Looking at the wiki page for Scavenger, they only have Raspberry Pi and Android focused builds. Do these apply to the ODROID-UX4? Running the following command via the terminal gives a little info:
cat /proc/cpuinfo
... processor : 7 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 120.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x2 CPU part : 0xc0f CPU revision : 3 Hardware : ODROID-XU4 Revision : 0100 Serial : 0000000000000000
This is just the last processor. there are 8 cores in the ODROID-XU4 and they’re all listed here. You can see that it may work with the same build for the Raspberry Pi 2/3 that they have listed:
– scavenger-1.6.0-armv7-unknown-linux-gnueabihf-cpu-only.tar.gz – e.g. for Raspberry Pi 2,3
Let’s start by downloading that version and testing if it will work on the ODROID. The link is on the releases page under 1.6.0 and it’s labeled scavenger-1.6.0-armv7-unknown-linux-gnueabihf-cpu-only.tar.xz.
Decompressing the package reveals two files and a test_data folder.
Scavenger Config
The first thing I’m going to do is look at the config.yaml file and update it with my info.
I am not solo mining at this time, so it’s safe to remove the first three lines:
account_id_to_secret_phrase: # define accounts and passphrases for solo mining 10282355196851764065: 'glad suffer red during single glow shut slam hill death lust although' 1796535821016683299: 'stand rude those door invite reflection anywhere lace safe hidden fur horrible'
Next, I’ll include my plot_dirs:
plot_dirs: # - 'test_data' - '/media/odroid/Seagate1/Plots' - '/media/odroid/WD1/Plots' - '/media/odroid/WD2/Plots' - '/media/odroid/WD_Old/Plots'
I’m going to set up the url parameter to point to the pool that I’m using. If you have questions about Pools and Reward Assignments, head over to the Burst Wiki Page on the subject. For my settings, I’ll use the 0-100 Cryptoguru pool: 0-100-pool.burst.cryptoguru.org:8124
url: 'http://0-100-pool.burst.cryptoguru.org:8124'
After that, I’m going to skip down the config file a bit until I come to the target_deadline piece. I’m going to update that with the recommended TD from the Bust Pool Quick Info tab. At the time of wring this, if I enter 21TB I should have a target deadline of 7717889. This should give me a good starting point. It would however be nice if Scavenger had a dynamic target deadline option.
target_deadline: 7717889 # default u32::MAX
The rest, I’m going to leave as defaults. Here’s my entire config file:
plot_dirs: # - 'test_data' - '/media/odroid/Seagate1/Plots' - '/media/odroid/WD1/Plots' - '/media/odroid/WD2/Plots' - '/media/odroid/WD_Old/Plots' url: 'http://0-100-pool.burst.cryptoguru.org:8124' hdd_reader_thread_count: 0 # default 0 (=number of disks) hdd_use_direct_io: false # default true hdd_wakeup_after: 240 # default 240s cpu_worker_thread_count: 4 # default 4 (0=GPU only) cpu_nonces_per_cache: 65536 # default 65536 cpu_thread_pinning: false # default false gpu_platform: 0 # default 0 gpu_device: 0 # default 0 gpu_worker_thread_count: 0 # default 0 (=CPU only) gpu_nonces_per_cache: 262144 # default 262144 gpu_mem_mapping: false # default false target_deadline: 7717889 # default u32::MAX get_mining_info_interval: 3000 # default 3000ms timeout: 5000 # default 5000ms send_proxy_details: true # default false console_log_level: 'info' # default Info, options (off, error, warn, info, debug, trace) logfile_log_level: 'warn' # default Warn, options (off, error, warn, info, debug, trace) logfile_max_count: 10 # maximum number of log files to keep logfile_max_size : 20 # maximum size per logfile in MiB show_progress: true # default true show_drive_stats: false # default false benchmark_only: 'disabled' # default disabled, options (disabled, I/O, XPU) # Low noise log patterns console_log_pattern: "{({d(%H:%M:%S)} [{l}]):16.16} {m}{n}" logfile_log_pattern: "{({d(%Y-%m-%d %H:%M:%S)} [{l}]):26.26} {m}{n}" # More detailed log patterns #console_log_pattern: "{d(%H:%M:%S.%3f%z)} [{h({l}):<5}] [{T}] [{t}] - {M}:{m}{n}" #logfile_log_pattern: "{d(%Y-%m-%dT%H:%M:%S.%3f%z)} [{h({l}):<5}] [{T}]-[{t}] [{f}:{L}] - {M}:{m}{n}"
Initial Testing – Success!
I kind of expected this to fail… since I haven’t had great luck with anything but creepMiner 1.7.18 lately, but YES it works “right out of the box”. Despite a stall at the start (which I’m attributing to the hard drives waking up) it’s all looking pretty good!
I like how they’re pointing out both the speed for each plot file and the total speed. You an see from the screenshots above, that my total round time is 42.624 seconds, which is below my goal of 60 second AND below the average with creepMiner (72 seconds) by quite a bit. This is looking VERY promising for adding additional drives to the ODROID-XU4.
I’ve run a few more rounds, and the total times & average read times are as follows:
42.642s @ 133.77MiB/s
54.640s @ 104.40MiB/s
54.778s @ 104.14MiB/s
57.014s @ 100.05MiB/s
DNF – block 5551447 finished before I could get a time
56.171s @ 101.55MiB/s
49.546s @ 115.13MiB/s
45.151s @ 126.34MiB/s
56.197s @ 101.51MiB/s
51.188s @ 111.44MiB/s
46.033s @ 123.92MiB/s
That’s the first 10 rounds, and it’s important to note that even though none of the round times match the first one so far in terms of that 133MiB/s speed, they’re fluctuating up and down a bit. I would attribute this to which sectors on the hard drive are being searched.
I did also get an error in there for block 551454:
code: 0 message: {"errorCode":"1005",'errorDescription":"Submitted on wrong height"}
Looking up that block on the Block Explorer, that make sense. The block generation time was 39 seconds, so it stands to reason that between my 3 second polling of the pool wallet that the block was won by someone else.
Comparison to creepMiner
I’ve been using creepMiner ever since I set up the ODROID (see this article) and have been in constant search (when I have time) of something that might allow me to expand beyond the 4 external drives that are on there now. Even with OpenCL (see this article), the creepMiner setup just can’t read and process the scoops at the speed of Scavenger. creepMiner version 1.8 is even worse, since Creepsky added in some logging features that a single board computer like the ODROID-XU4 just can’t keep up with.
Conclusion
So there you have it. Scavenger does indeed live up to the PoCC claims of being the fastest Burst Miner out there! .. at least for me on this setup. It doesn’t quite live up to their claims of being two and a half times faster than creepMiner 1.7 however.
There may still be some room for adjustment in the settings of the miner. Looking at my resources on the ODROID, I still have some CPU and memory to spare. If anyone reading this has tried different settings, go ahead and post them in the comments below and I’ll give them a try.
All-in-all, this is indeed a nice miner. Nice work PoCC crew! I’m glad to see such high quality software still being released.
The overlap check also alerted me that I’m an idiot and overlapped my last plot on the USB2.0 drive with one of my earlier plots. I removed that from the system for now. It didn’t seem to speed up the round too much. I wonder if it already ignores overlapped plots, or if it’s just a warning.
Leave a Reply