The JD staking wallet checks something like 30k outputs in 4 seconds.
I believe this means that you are missing 3 variations of hashes for each output per every 4 seconds?
I don't understand what you're asking, sorry.
The CLAM protocol has a time granularity of 16 seconds. Every 16 seconds it checks each of its unspent outputs to see if it can stake, then sleeps until then next 16-second "tick" of the clock.
If it takes you more than 16 seconds to check all your unspent outputs then you'll be missing out on staking opportunities, because you'll be falling further and further behind. JD is able to do all its staking work in 4 seconds and have a 12 second snooze before the next opportunity comes up.
I don't understand the bit about "missing 3 variations of hashes". There's only one hash per output per 16 seconds.
Now if JD was able to check all of its outputs in 0.001 seconds then it would probably have a lower orphan rate, since it is kind of a race. Maybe that's what you're referring to?
Again, I may be picturing this incorrectly in my head, so let me explain my reading of the code and see if it lines up with yours.
15 seconds is the future drift limit (which is I think what you are referring to when you say time granularity?).
https://github.com/nochowderforyou/clams/blob/master/src/main.h#L74inline int64_t FutureDriftV2(int64_t nTime) { return nTime + 15; }
and the search interval is 1 second.
https://github.com/nochowderforyou/clams/blob/master/src/main.cpp#L2603int64_t nSearchInterval = IsProtocolV2(nBestHeight+1) ? 1 : nSearchTime - nLastCoinStakeSearchTime;
The stake hashing is iterated by the search interval not the future drift.
https://github.com/nochowderforyou/clams/blob/master/src/wallet.cpp#L2108for (unsigned int n=0; n
The search interval appears to be one second after protocol 2, so that is why I am lead to the conclusion that if it takes 4 seconds to hash a set of outputs for one timestamp, then you have have skipped 3 timestamps that you could have tested. And of course this would only apply to very very large groups of outputs, for normal stakers this is a non issue.
I also can't find the relevant part of the code that tells it to pause looking for 16 seconds. I may be wrong, but I think there is no pause (a simple monitoring of the CPU consumption could give us a clue too). All I see is the normal minersleep parameter that is set at 500 milliseconds.
Again I could be totally wrong, and completely missing some of those parts of the code that you mention. The staking code is so all over the place that its hard to track down everything.