stratum-mining-litecoin
stratum-mining-litecoin copied to clipboard
moopless
Stratum Shares out of Order
Seeing issues when fast block finding rates apply. Then stratum caching is not inserting rows in the proper order and shares become out of order killing the payout process:
| Time | ID | Block Height | Amount | Share ID | Shares | Finder | Share Type |
|---|---|---|---|---|---|---|---|
| 885 2013-07-11 17:14:36 | 47 | 43 | 50 | 9912 | 41 | [1] TheSerapher | startum_solution |
| 886 2013-07-11 17:14:36 | 40 | 44 | 50 | 9905 | 0 | [1] TheSerapher | startum_solution |
AS you can see Share ID of block 43 is 9912 and for 44 it's 9905. Hence the process is not finding any shares using SQL id > 9912 AND id <= 9905.
Only having this when running testnet and finding blocks fast. Not an issue with pushpoold which is not using a share queue before writing them out.
This probably explains where the missing 'Y' shares are, I've seen this multiple times, so I'm thinking if the
DB_LOADER_REC_MIN = 10 # Min Records before the bulk loader fires
DB_LOADER_REC_MAX = 50 # Max Records the bulk loader will commit at a time
are both set to 1 this should more or less disable the shares caching? would this have a negative impact on performance? I'm currently testing this on one of my live pools that I've had trouble with unknown finders to see how it goes.
This may not be the database queue. I would advise lowing the two settings @obigal mentioned above to see if there are different results.
I think this may actually be a deeper seeded issue. The rate at which the blocks are found in this case is abnormal. In a real pool it is very unlikely that we should be finding multiple blocks within the same second, so stratum-mining was not designed to handle something like this. It may be that the this has been submitted in multiple threads and the second thread added the share to the queue after the first.
@TheSerapher Do you have stratum debug logs for one of these events? I want to see how close they are submitted. Can you try to reproduce it with the changes made in #37 and send me the debug log?
A little while back added some code to instantly notify the miners of the new blocks when one was found, which may be accelerating the pace to which miners can submit blocks and causing issues. With pushpool are you seeing the same frequency of blocks (ms apart)? I would expect it to be slower (in the order of ms to s) as pushpool commits the share to the db before it allows for getwork to update the clients (I think).
No sorry, it's been too long ago. I will test that branch out at some point, need to get my hashing power back up so I can reliably reproduce it.