search

fireworm71 / veriumMiner

veriumMiner for solomining and pools
Other
59 stars 36 forks source link

Memory problem with verium miner #16

Open laxduke opened 6 years ago

laxduke commented 6 years ago

I have been using verium miner v1.4 for some time now. I have noticed strange behavior with "more then enough" RAM with the system. Freshly installed Windows 7 on HP Proliant DL360G7 with 2 x Xeon X5650 and 48GB of DDR3 Registered with 20 threads in command line was making ~2400H/m. BIOS defaulted and flashed with latest HP SPP DVD. Another HP Proliant DL360G7 with 2 x Xeon X5660 and 12GB of DDR3 Registered RAM is making 3350h/m??? After this comparison i started to look to my other machines and found out that if i have "too much" free RAM, things slow down. So i pulled out extra RAM from first DL360 and reduced it to 12GB and hash went up to very stable 3487h/m. Is it possible that there is some instruction that is going through whole ram space and back and something is waiting for this information. My optimum calculation is 512MB of RAM for 1 thread on CPU. Can anyone reproduce the problem?

darkwolfultima commented 6 years ago

this is not an issue with the miner, but the memory configuration of the server.

look at memory and instruction set specs here: https://ark.intel.com/products/47922/Intel-Xeon-Processor-X5650-12M-Cache-2_66-GHz-6_40-GTs-Intel-QPI

you should fill all memory channels (not slots) and use the fastest supported memory to maximize memory bandwidth which will have a significant effect on hashrate.

refer to this table for how much memory to use: How much memory is be used per thread?

1way : 128MB -> nr_hugepages = 65.
SSE4 (3way) : 384MB -> nr_hugepages = 193.
AVX (3way) : 384MB -> nr_hugepages = 193.
AVX2 (6way) : 768MB -> nr_hugepages = 386.
ARMv7 (3way) : 384MB -> nr_hugepages = 193.
ARMv8 (3way) : 384MB -> nr_hugepages = 193.

issue can be closed @fireworm71