Following up on my earlier tracing of offsets and difficulty, here's a new graph:
http://www.cs.cmu.edu/~dga/crypto/ric/diff_offset_2014_03_18.pngLooks like within a few days, the low-primorial miners will mostly be gone.
Supercomputing alluded to this, but I think it'll be interesting to see what happens with coprimes (offsets relative to the primorial) other than the first. The ypool miner and mine both use only the first (+97 for 2310, and +16057 for big primorials). But a00k's uses a different coprime for each worker. I'm not sure I see a fundamental advantage to using the coprimes unless we start exhausting the 256 bit nonce space with large primorials and need to search more densely, but it seems like something to keep in mind.
I'll see if I can add a coprime-detector to my analysis code for some graphs next week. That should also provide a better signature of the miner used to mine the block - interesting stuff.
All these primorial optimizations are assuming that all 'coprimes' as you say (I'm not sure it's the correct term, I'd call them 'remainders' since they are the remainder of the first prime of the sextuplet modulo the primorial) are equiprobable (ie sextuplets are distributed evenly amongst different remainders). It's logical to assume that, but I think it's not proven to be true. Some may give better performance than others - and it could be a big difference.
The safest approach would be to choose one at random and switch every few minutes or something. And of course the best would be to research if they are truly the same or not.
Some of you people thought your were mining this for the money? while you were distracted, I made you do science! ha!
I may be wrong if I missed something, and I completely agree with gatra.
a00k seems to be doing a lot of unnecessary work just to get to this:
Base_Target = {Current Target}
Sextuplet = 7273427997146573527660308536800543291038744551505285967246716372557017 <---- Static Sextuplet Origin (different for each thread)
Primorial = 179#
Then do something like this:
Remainder = Target % Primorial
Remainder = Primorial - Remainder
Target_Offset = Remainder % Primorial
Target_Offset = Target_Offset + Sextuplet
Target_Offset = Base_Target + Target_Offset
Then your sieve array will represent:
Target_Offset + Primorial + Primorial + Primorial + ...
or
Target_Offset + (k * Primorial)
Not yet got into the point.... but I'm calling mines coprimes obviously because not requiring them to be primes.
COPRIMES= { n | n, n+4, n+6, n+10, n+12, n+16 are relatively primes to P# }
I guess we can easily get many such 32-bit numbers, without obtaining them from true prime sextuplets... ??
Show Posts
