Version 2.0.8 - November 11, 2011
- Make longpoll do a mandatory flushing of all work even if the block hasn't
changed, thus supporting longpoll initiated work change of any sort and merged
mining.
Donated 5BTC as I promised. Thanks for continuing to improve THE BEST miner out there.I was hoping your could clarification on the flushing "timeline".
Does it work like this:
1) LP arrives.
2) cgminer flushes any work in the queue (this work hasn't been worked so not worried about this)
3) cgminer loads queue w/ new work.
4) GPU continues to work on any data in its cycle (can't be interrupted, length based on intensity)
6) If GPU finds a share that share it considered stale and not submitted (SS increments by 1)
7) GPU begins work on new data
If so does enabling --submit-stale option cause it to work like this:
1) LP arrives.
2) cgminer flushes any work in the queue (this work hasn't been worked so not worried about this)
3) cgminer loads queue w/ new work.
4) GPU continues to work on any data in its cycle (can't be interrupted, length based on intensity)
5) If GPU finds a share that share will still be submitted. (If actually stale R increments by one otherwise A increments by 1)
6) GPU begins work on new data
The reason I ask is because it is possible the LP is from new transactions or NMC header change and the share is still valid for BTC.
I understanding using --submit-stale option will potentially increase rejects but if I understand this right.
SS + R should be equal regardless of if --submit-stale is used or not. Right?
It makes me think I should use -submit-stale. The only downside is that it increases potential workload for the server. The upside is that I may gain a few more accepted shares.
Thank you very much for your donation
Your interpretation is spot on. --submit-stale is fine since pools don't usually penalise you for submitting shares it rejects. It just increases your reject count.
Show Posts
)
