Mining speed drop since 2.4.0

[BarryJohnson01]

Version 2.4.0 Linux 64 bit, GuldenD commandline version on Linux server.

Hashing speed dropped from around 6 mh/s to around 5 mh/s. Watched it for a few days but it never got back into the 6 range.

i have two identical servers. The other still runs 2.3.12 and regularly touches 6.4 mh/s as usual.

barry.

[ghost]

Same here.

GuldenD 2.4.0
Linux 64 bit
Debian 10
Dual Xenon 40 cores
128GB memory
Started in terminal,
setgenerate 38 32 4096

Best_reported usually around 13.6 with GuldenD v. 2.3.12

Best_reported now around 11.4 with 2.4.0

Martin Beek.

[ghost]

But, don't bother Barry. People are being ignored here since April 2020.

The developer(s) of Gulden feel hurt every time they are criticized or feel attacked by users posting issues, so just let hope one of their besties runs into the same problems and we'll hopefully get an update. That's the way it seems to work.
And don't forget, you are just a miner... They don't need and want you anymore...

[BarryJohnson01]

I don't want to comment on that. I'd like to keep the focus on the technical issue.
Here is my setup:

• Gulden 2.4.0 daemon Linux 64 bit version
• CentOS
• 16 core Intel Xeon processor, 32GB memory
• executed with: ./Gulden-cli -datadir=./datadir setgenerate true 14

Mind, i have two identical servers with a comparable load. Server 1 runs 2.4.0, and server 2 still runs 2.3.12 and the difference is significant, and way over 1 mh/s.

Just my two cents.

[mjmacleod]

Hi barry,

You likely need to adjust the amount of arena setup threads you use, its a new feature in this release and the optimal settign is different for every machine type.

If your hashrate has dropped its likely that yours is too high, I'd recommend trying it at "num cores/2" and then monitoring how that goes

[mjmacleod]

But, don't bother Barry. People are being ignored here since April 2020.

The developer(s) of Gulden feel hurt every time they are criticized or feel attacked by users posting issues, so just let hope one of their besties runs into the same problems and we'll hopefully get an update. That's the way it seems to work.
And don't forget, you are just a miner... They don't need and want you anymore...

Please keep your childish emotional outbursts off this github, final warning.

[mjmacleod]

As far as I'm concerned based on other user reports adjusting the number of arena setup threads to an optimal point restores performance to pre-update levels (for machines where it doesn't improve performance, on a lot of machines it does)

I'm pre-emptively closing this issue as resolved. Should you still be seeing significant differences after playing with these settings then please reopen with additional information.
Ideally use the "bench_sigma" tool so that we can isolate various network variables out of the equation.

[BarryJohnson01]

Hello Malcolm.

I've experimented for two days, with both v. 2.4.0 and 2.4.1 on different machines, and I was allowed to use a server from my employer (debian 10, dual xenon 40 core, 96gb). I've tried all thinkable combinations of the setgenerate parameters with no difference in the results. What I have noticed is, that 37,38, and 39 cores (e.g. setgenerate 38 24) make no difference in mining speed! But that could be machine specific.
The main issue remains noticeable ; a sharp decrease in mining speed between 2.3.x and 2.4.0 on Linux Debian 10.

I had my boss look trough the code and he had one remark: the use of MilliSleep(100); on line 1301 of miner.cpp
For a headless dameon installation Millisleep(10) or 20 would be sufficient and could result in a higher mining speed.
Do you agree?

Thanks for your time and help

Barry Johnson.

[mjmacleod]

the use of MilliSleep(100); on line 1301 of miner.cpp
For a headless dameon installation Millisleep(10) or 20 would be sufficient and could result in a higher mining speed.
Do you agree?

That particular loop isn't actually doing the mining but is only periodically polling the mining to get stats on how fast it is, and to see whether it has found a block etc. (The actual mining is taking place in a thread thats fired off in the loop above that).

So unfortunately this would not impact mining speed in any way...
Well not entirely true, if it were e.g. 10 ms instead of 100ms it might actually slow down mining a bit, though OTOH would mean that (in some cases) you might broadcast a block you have found up to 90ms faster; but ultimately its likely to be inconsequential so its unlikely to be the issue.

Could you try running the bench_sigma command from 2.4.1 tarball as well as an older tarball and post the results for comparison?

[mjmacleod]

You can see the complete changeset in terms of mining here 79e3e6b#diff-bb5b3a14dcd1a6cfc03368e1ee23dda2e6bc94b8de6f8e7be7f8f5d616f9c40e

As you can see its really quite minimal, basically just adding an extra setting that can be tweaked, so its somewhat baffling that it would have the effects described, I don't of course doubt that it can be true, performance optimisation can be tricky at times...

That said, its quite possible that there is something more complex at play, e.g. other parts of the code are slowing down mining by taking up more resources etc.; so its a bit of a multidimensional problem to consider.

Any additional information you can provide (e.g. the bench_sigma) results, would therefore be very valuable in this regard.
Also are these machines running SSDs or regular harddrives? etc.

[mjmacleod]

2.4.3 release is now also out, which disables some (not specifically mining related) code that may have an impact on performance, please update to that and advise of results there (the results of bench_sigma would additionally still be useful)

[BarryJohnson01]

I’ll get back to you as soon as I can. I was in a car accident last Thursday . All is okay but I’m hospitalized for another week.😡

[mjmacleod]

Sorry to hear, please take all the time you need, theres certainly no rush on this.

[mjmacleod]

Closing as fixed for now, if anyone still feels they have mining speed reductions please reopen with additional information (as discussed in comments above)