[Improvement] Simplify multihash settings #209
Comments
|
Because 4 main threads will occupy physical cores and multihash thread will be assigned to logical core which is not effective. It's always better to run threads on physical cores only. So 3x 1MB scratchpad on first three physical (3MB of L2) and then 3*Multihash on last physical core (remaining 3MB of L2). |
|
No, it not like that. If i let it assign threads automatically it assigns 3 main threads and 2x multihash on all 3 main threads. And i may be wrong but to assign multihash you need to have main thread, so 3 main threads and 3x multihash on one more thread as you described will be 4 main threads and 4x multihash on one of them. |
|
Atleast it's what i assume it does. I see 3 main threads and hf=2 so there will be additional 3 2x multihash threads on those 3 main threads. [2018-11-05 19:57:22] * CPU: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz (1) x64 AES-NI ASM-INTEL |
|
Is max cpu usage set to 100? |
|
It was 99, chaned it to 100 and now it assigns only 4 main threads and no multihash ... [2018-11-05 20:10:54] * VERSIONS: XMRigCC/1.8.1 (based on XMRig) libuv/1.14.1 gcc/7.3.0 (RELEASE with TLS) |
|
Ok thats what i expected. The whole multihash auto adjustment is really basic implemented. It doesnt fill all the cache up with as much as it can. Only works if cache >= threads * scratchpadsize * 2 (or 3,4,5). So if all threads would fit in. |
|
Yeah, i think i seen that behaviour earlier, that's why i configure each miner's thread\multihash config manually, but that's pain in the ass with ~100 ish miners, even with CC. What do you think about my templates suggestion ? Too much work ? |
|
Template implementation like you described is a 0.5btc task. Basic template is already on the roadmap. But if you have 100+ different types of miners that isnt useful at all. So for this case improving the auto detect feature is more useful i guess. |
|
Looking back into your #206 and your problem is Windows :/ .. I have just 15 machines which need very different configs, too, and using Ansible to put pre-configured variants of config there. To switch pools --> use proxy. |
Oh, i seen your reply to #206 now. Yeah, basic template just for switching pools\algo will be great, maybe add miner's version dependence to assign another pool+algo to old version miners which is impossible to update yet for PoW change. |
|
In the light of addition of CN-Ultralight and it's ultra-tiny scratchpad - this stuff becomes even more useful. There's no way to say, assign multihash factors of 2x to 2 threads and 3x to other 2 threads. Other miners can do that, but not XMRig. xmr-stak for example has config for each core separately, but the way i suggested (only by 'threads' control, assuming 'multihash-factor' is set to 0\auto) must be easier to implement and use. |
|
Done with latest update https://github.com/Bendr0id/xmrigCC/releases/tag/2.0.0-beta1 |
Make 'threads' option controls both main threads and multihash threads.
If 'threads' is greater than CPU's logical threads count then miner adds additional multihash threads with the same mask\priority as main threads. I.e, first physical cores, then logical cores.
PS: One question about multihash. Why automatic settings with CN-Lite (1MB footprint) on 4-core CPU with 6 MB LLC is 3 main threads + 3 multihash threads ? In that case 4 main threads + 2 multihash threads yield better HR by my experience. Or i'm wrong here ?
The text was updated successfully, but these errors were encountered: