Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
No, with that taskset command you can run 24 threads. It runs one on every second core. It's because 2 cores on those AMD's share the cache memory so cores 0 and 1 access the same memory.Thanks for your input. I was just wondering if this was what I was supposed to do.
Sent from my LG-H815 using Tapatalk
Try that taskset setup first with 24 threads. then if you want a higher hash rate use 32 threads without the taskset command.
Also you can test as was suggested with running the miner 8 times eg. once for each NUMA node. You can do it with taskset or numactl. In my case this didn't bring any benefit but it may be because of my motherboard etc.
With the taskset command I found that the hash rate hovered around 450 h/s and the - t 32 produced around 1000 h/s. That's nowhere near the projected value of 1500 to 1600 hash (double that of Jim's, theoretically). Perhaps it's something I'm overlooking. With 47 threads it only increased to 1100 h/s so I think you guys are correct in saying the maximum amount of threads that can be run efficiently will be around 36.
Last edited:
I'd look into your BIOS settings. I get 1100 with 3 6234's without NUMA settings and without Turbo core enabled in BIOS.
More threads = more cache misses and more RAM access. What sort of memory configuration does that beast have? One or two DIMMs per CPU may (?) be strangling the system bandwidth.
So I tried updating my BIOS, turns out I need an active HP warranty to download the BIOS from their website. These BL685 G7s are quite old, so I think the warranty on them ran out. This is real frustrating. Trying to find a workaround now. 1.1kh/s for 4 CPUs is really unacceptable. Tried a lot of stuff like shutting off power saving options, running on even/odd cores. I think the only real solution I haven't tried is updating the bios.
I ended up downloading a torrent of this: Service Pack for ProLiant | Hewlett Packard Enterprise
Last edited:
I fired up a dual 6238 DL385G7 last night (2012 BIOS), compiled xmr-stak, and sure enough under ubuntu 16.04 the fastest I could squeek out was around 500H/sec using 12 threads on even cores. xmr-stak under windows 10, I can get 670/h with the SAME exact config.
however, if I run 2 extra threads on each cpu, so 1, 5, 13, 17 on low power mode, I jump to 830H/sec. ONE more on either CPU, and I drop back down to 750H/sec.
So it seems for me, with HT off, Windows with 16 threads, 8 regular and 2 low power on each CPU is the magic number.
I will say on Linux I was getting MALLOC errors, even though I was running as root and had large pages set. Go figure.
It's been sitting awhile now and over time looks like 844H/sec.
however, if I run 2 extra threads on each cpu, so 1, 5, 13, 17 on low power mode, I jump to 830H/sec. ONE more on either CPU, and I drop back down to 750H/sec.
So it seems for me, with HT off, Windows with 16 threads, 8 regular and 2 low power on each CPU is the magic number.
I will say on Linux I was getting MALLOC errors, even though I was running as root and had large pages set. Go figure.
It's been sitting awhile now and over time looks like 844H/sec.
Hmm interesting. I might just switch to Windows then. Which version are you running?
Sent from my LG-H815 using Tapatalk
Hm so past few days I've tried windows server and win 10 but none of them seem to have the drivers for my switch located at the back of my c7000 enclosure. I switched back to Linux and compiled xmr-stak-cpu and let it auto configure. Strange thing is that my hash rate is still hovering around the 1.2 to 1.3kh mark for 4x 6238 opterons. Nowhere near the projected 1.6kh. I've tried pirating the bios and stuff but it's still not up to scratch. This is what my hash rate report looks like. If any of youse have any idea what's going on please let me know?
Sent from my LG-H815 using Tapatalk
Sent from my LG-H815 using Tapatalk
Joel,
One more thing about the 61xx G34 Opterons. When running in quad socket systems, the CPU sets aside 1MB per 6-core die for a cache snoop buffer.
See AMD's 12-core "Magny-Cours" Opteron 6174 vs. Intel's 6-core Xeon
With Monero being so cache sensitive, this might be a significant issue.
There may (?) be a bios option to disable this. (Or enable it if it's off.) If so, try it both ways...
One more thing about the 61xx G34 Opterons. When running in quad socket systems, the CPU sets aside 1MB per 6-core die for a cache snoop buffer.
See AMD's 12-core "Magny-Cours" Opteron 6174 vs. Intel's 6-core Xeon
With Monero being so cache sensitive, this might be a significant issue.
There may (?) be a bios option to disable this. (Or enable it if it's off.) If so, try it both ways...
Yo greg I'm running 6238. The 61xx series was too shit.
Sent from my LG-H815 using Tapatalk