Thank you for all of your hard work Kano. We greatly appreciate it. And thanks for sending payments out.
Yes, many thanks kano...and what are your donation links? We know you and ck are hard at it. You should put those up from X2X. It's more beers for your beach cooler!! I'll take another. Can't do much until I get a break-out board so I can get this s3+ back up, so pass me a beer too. lol
Good work & good luck!!
Ah no - I don't think a donation would be appropriate.
Firstly a tl;drI'm adding in 0.5% to the next payout to over compensate the shares lost in the "4kooq felli" shift
(I was too tired to write this last night ... so it's here now)
Now the details for anyone who wants to knowI guess I should expand on what I said - the disk space issue in the middle of the last full reload took out about 2/3 of a shift of shares towards the end of the problems.
When ckdb reloads data it records the data all again in the disk logs.
So since I reloaded 1.5 days worth of data multiple times over a few hours it quickly spiralled up and filled the log disk.
In my exasperation dealing with the problems I caused doing such a large reload multiple times and making the pool restart so many times, I missed spotting that happening.
I have a daily process to deal with this, but it doesn't happen at the particular time I was doing the reloads.
Well, at least now the code can handle a reload of almost any size due to sorting out how to deal with that ram problem when it happened
(that's what the last commit solves with the 250000 check in it)
But I need to pay attention to the disk space if I ever do a reload that big again multiple times (it was OK the first time ...)
Anyway, what it effectively means is that about 2/3 of the shares in shift "4kooq felli" wont be in the next payout (you'll notice your total there is about 1/3 what it should be)
ckdb only writes summaries to the permanent DB, after a shift completes, so it can get them back on a restart, and then reloads from the logs all shares after the permanent DB contents
In this case I reverted (deleted) the DB shares back 1.5 days to make it redo the calculations - but all the 1.5 days of data was in the logs so that was ok to do - but the new data generated during the time of the "4kooq felli" shift never made it into the permanent DB nor the disk logs due to running out of ram and disk and having to be killed before ckdb finished the shift and wrote it to the DB (the DB disk never ran out of space)
What this means is that the next payout in the next blocks after that shift will probably include one extra shift back before the problem to make up the 5N (this of course will happen with any future blocks found up to 5N after the "4kooq felli" shift)
So the effect on the payouts will be that some will get a small fraction more due to that and some will get a small fraction less.
The amount more or less depends on the ratio of mining you did in that shift vs every other shift in the next payouts that includes that shift.
If your ratio is the same then your payout will be the same, if your ratio is higher in that one shift than all other shifts you've mined in, then your payout will be down a bit, and the reverse, if your ratio in that shift was lower than all other shifts you mine in then your payout will be up a bit.
Overall, it wont have a big affect on anyone unless they were unlucky enough to only mine in that shift and never in any other shift for the past week
(which I doubt would be anyone)
My fix for it will be that I will add my proportion of the pool fee (0.5% or ~0.125BTC) into the next reward and distribute it to everyone.
That should compensate the small adjustment loss for anyone who did actually lose anything and everyone who gained from the missing shift data will get a little bit more also (and I guess could call it thanks for sticking around during the problems yesterday and still mining)
The amounts involved will be very small but the amount I'm adding should more than compensate for it
At the moment a total shift is worth very roughly the amount I'm adding but (as I've said above) you wont actually lose a shift of reward you'll just have it distributed to your other shares and that distribution will either be a little bit more or a little bit less than you'd expect based on your ratio of shares in the "4kooq felli" shift vs your ratio of shares in the payout.
To give an over estimate example to show the difference:
If you average 10TH/s for the payout but for only for that "4kooq felli" shift did 11TH/s i.e. 10% extra mining only in that one shift
and assume 150 shifts in a payout (there's more than that)
The normal payout without the missing shares would be avg*reward/pool
What you should have got would be (avg*(1+(0.1/150))*reward/pool
So your reward should have been 0.07% higher if you had the outrageous bad luck of only mining 10% more in that single shift
... and just in case it wasn't obvious ... where did the missing 0.07% go?
To all the other miners - and that would only be a tiny positive effect for them.
If that 0.07% continued on for 5 payouts that's 0.35%
I'm adding in 0.5% to the next payout.
I doubt anyone would even be close to a 10% difference (I'd expect even less than 1% for everyone) and lowering the 10% number of course lowers the amount you missed out.
How I'll do it will be to simply increase the Miner Reward for the next payout.
So anyone not wanting it, you'll get it anyway since it's way easier to just make that one adjustment than trying to handle each miner differently.
