Quote from: gigawatt on August 17, 2013, 03:44:57 PM

Quote from: cabin on August 17, 2013, 02:00:33 PM

With the fractional difficulty reaching a high level a useful optimization might be the "Sieve depth", represented as nBits in this line of code from prime.cpp

lpsieve = new CSieveOfEratosthenes(nSieveSize, nBits, mpzHash, mpzFixedMultiplier, pindexPrev);

Right now it it is searching for 9 chains, but increasingly these are going to be discarded because of the fraction test. It might be best to search for 10 chains now. I added a -h parameter to the pool miner as described below and it was quite effective at searching for the desired length of chain:

https://bitcointalk.org/index.php?topic=257623.msg2820614#msg2820614

I propose -h 10 might be the best until the diff reaches 10.5 or so.

This chart also shows it being very difficult to find chains using the existing miners when the fractional part is high:
http://192.241.170.170/

I support this idea. Although, to my knowledge all that will affect is the roundPrimorial which you can crank up by jacking with roundSievePercentage.

So should we make roundSievePercentage higher or lower, it's currently 70% at my configs. Does this also depend on what kind of CPU we're using?