DeroStorm 1.5.10 - rigs with more than eight cards

Two bugs that only appear on a mining rig, and neither of them was visible on a desktop. Kernels, hashes and hashrate are unchanged from 1.5.8 — 142,600 H/s on an RTX 5080, 175,400 with the CPU beside it — and this release exists because 1.5.9 shipped a HiveOS package before anyone had thought hard about what a HiveOS box actually looks like.

A twelve-card rig was mining on eight of them and said it was mining on twelve

maxGPUs was 8. --gpu=all took every device the driver reported, so on a rig with more cards than that it started a worker per card, and the workers past the eighth hit a bounds check and returned immediately. The count the console reported came from the map those workers had already been added to.

The result: four cards idle, four error lines in a log nobody reads, and a headline figure claiming twelve GPUs. The hashrate looked low and nothing said why.

Three changes:

• maxGPUs is 16. The comment above it always said the nonce tagging allows it — GPUs take byte 47 in the range 0xf0..0xff — and 8 was simply conservative. Sixteen covers essentially every rig; past that the tagging scheme itself has to change, and that is not a quiet fix.
• --gpu=all trims to what the miner can address rather than handing out indices that are going to fail.
• SetGPUs refuses an out-of-range device before it is counted, so a card that is not being mined can never be reported as one that is.

--gpu=0,1,2,16 now says "16" is not a device index between 0 and 15 instead of starting something doomed.

The CPU thread default was a desktop default

The miner picks logical CPUs − 1 mining threads. That is right for a desktop and wrong for a rig, and DeroStorm's own measurements say so: every card needs a host thread to feed it, and a CPU miner competing with that feeder costs more than it earns. On a four-thread rig carrying six cards the old default started three CPU miners, starved six GPU feeders, and burned power to add a rounding error.

h-config.sh now sets --mining-threads to CPUs − cards fed − 1, floored at one:

rig	threads
4 CPUs, 6 GPUs	1
2 CPUs, 8 GPUs	1
12 CPUs, 6 GPUs	5
16 CPUs, 1 GPU	14
32 CPUs, 8 GPUs	23

Cards fed, not cards installed — it reads --gpu=off and --gpu=0,1 out of the extra arguments, because reserving a thread for a feeder that will never exist is the same mistake in the other direction. --mining-threads in the flight sheet still wins.

What was measured, and what could not be

The block count needs no tuning: the suffix kernel plateaus at four resident blocks per SM and stays flat above it — 134,209 H/s at 336 blocks against 134,214 at 672 and 133,597 at 1,344. The default is already the plateau.

Linux hashrate could not honestly be tuned here, and the package README says so. Every Linux figure available to this session was taken under WSL, which virtualises the GPU: four runs of the same binary read 136.4, 122.2, 117.1 and 137.6 KH/s, a 15% spread, against 5% for the same binary on Windows. That noise is the virtualisation, not Linux, and tuning against it would have been fitting to nothing. HiveOS runs on bare metal and should sit closer to the Windows figure — the last honest measurement of that gap, at 1.4.1, was about 2.5%. Numbers from a real rig are worth more than anything this session could produce.

Unchanged

Hashes, kernels and hashrate. gpu/hash_parallel_test.exe matches all 512 reference vectors, go test ./cmd/derostorm/ is green, three interleaved --bench --gpu=all runs read 175.4 / 175.0 / 176.1 KH/s, and the HiveOS package was tested end to end from the published archive: flight sheet to config, run, per-card stats with temperatures and PCI bus mapping, and a clean stop that removes the stats file so a stopped rig reads as stopped rather than frozen.