We have fixed a duplicate share bug in multicard rigs on the hiveon pool and possible other ethereum 1.0 stratum pools. The ~2% rejected shares are now ~0% in version 1.26 and this will improve the poolside speed..

T-Rex 0.19.9

* Add ability to execute custom scripts upon certain events with new parameters:
"--script-start"
"--script-epoch-change"
"--script-crash"
"--script-low-hash"
* ("ethash", "kawpow", "octopus") Add "--dag-build-mode" parameter to fine tune DAG build mode (mostly to help with various stability issues, see readme for details)
* Allow non-existent GPU indices passed in to "--devices" / "-d" parameter: the miner will display a warning message but will continue mining using the GPUs it could find)
* Cosmetic changes: improve error descriptions, display block number when mining solo at some pools (2miners)

Bug fixes:
* ("ethash", "kawpow", "octopus") Stability regression for Pascal GPUs
* Mining pool difficulty is not always updated in the summary report (https://github.com/trexminer/T-Rex/issues/131)

**NOTE**: if you experience stability issues when mining "ethash" right at the start or upon epoch change, e.g. some GPUs fail start with "GPU is idle" or "NVML: can't get GPU#" errors, try running with "--gpu-init-mode 1", it will force sequential GPU initialisation and reduce the load on your hardware (set to 2, 3, etc to indicate how many cards may be generating DAG in parallel)

Completely unreliable for a 7 card 30series rig with medium memory overclocks 3060Ti +800MHz, 3070 +700MHz and +800MHz, 3090 +350MHz... It cannot create the DAG reliably it will hang and crash miner. However if memory overclocks are reduced by 200MHz on each card it will create DAG why is this? It works perfectly with version 0.19.5 and 0.19.4 (these I have tested with these settings).

This is absolutely not a stable build for me... It just hangs unless used with an extremely low memory overclock.

The speeds make sense at these clocks.
I'm just wondering how you're able to even run these clocks so high in the first place. Is your rig in a freezer?

Even in assembly, we have very few control of the cache level. Just a few instructions: the movntdqa and some prefetchnt (nt == non temporal == no cache). JCE mostly let the CPU handle everything, except in "use_cache":false mode.

Progressing on assembly for multi-hash on AES-64 (the easiest to write).
I reach 79 h/s on Hexa-hash on CV-v7, which is very bad, but when using IPBC where the JCE multihash does marvels, i get some interresting results. More tests and optims to do.

Surprisingly, i didn't run out of registers in x64 with 6 hashes at the same time. But on 32 bits it will be terrible. I'll provide hexa-hash 32-bits for code symetry, but probably useless.

edit : i reach 1700 h/s on on IPBC my stock ryzen 1600 with JCE 0.26 and its multihash, with config multi
3+1+1+1+1+1+3+1+1+1+1+1
so 12 threads, two triple and ten simple. Curiously the double are less good...
That's the fastest combination I found. On CN-v7 still cannot beat the default 8x simple