Quote from: PttnMe on September 26, 2018, 01:58:40 PM

For Bounty Hunters: I am now willing to donate 1000 RIC for the person who fixes this rieMiner issue elegantly. This offer will expire on October 8 2018 at 00:00 Zurich Timezone. It is currently about the price of one beer, but remember how much a pizza cost years ago... And who knows if this is just 2 lines to change, but I am currently too busy to look. After this deadline, the bounty will be reduced to 250 RIC and remain valid until the new wallet is officially updated, or until January 1 2019 at 00:00 Zurich Timezone if gatra never comes back.

Note that this bug is present since fastrie/xptMiner. Obviously, there must be no performance loss, you should benchmark before and after and compare before submitting the fix. And by elegantly, I mean, inter alia, a fix that is not just a workaround (you could for example compute 2 sieves and imitate the launching of 2 instances with less threads, but this is not worth any bounty).

The fix must also make Testnet mining work properly with any sieve size (in my 2700X, only about 25% of the CPU is used when mining at difficulty 304 using 16 threads!).

A couple thoughts. This sounds like the sieve might not be providing enough work to keep all the threads busy checking primes. You could try increasing the number of sieveWorkers. SieveSize could also possibly play a role. Things like memory cache usage become important. I'm not sure about the 2700X architecture but it's possible that the sieve workers need to be not just in different threads but different cores or specific cores in order to optimize performance.

As difficulty decreases, the sieve must perform faster and faster. At some point the sieve will be memory bandwidth limited and it still will not be fast enough to keep the prime checks going at 100%. At this point the only way to increase total system performance is to decrease the number of primes in the sieve. It's possible that the testnet difficulty is at this point.