Topic: KanoPool kano.is lowest 0.9% fee 🐈 since 2014 - Worldwide - 2432 blocks - page 2087. (Read 5352140 times)

Reading through all that makes me WANT a beer. LOLOL.

I just am happy that you work on the issues and know what's going on. Staying active and involved with the system is all we can ask for .
I do the same with my sites and Firearms Forum, so I know what you go through. LOL

Thanks and try to get some sleep. (Where ever you live.)

Really...now that's what I call a good pool op. Nice! Sounds like ya caused yourself more work. Sorry, but hey, it's part of the learning curve, right?

I'll still take that beer!

Thanks......cheers!

Ah no - I don't think a donation would be appropriate.

Firstly a tl;dr
I'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 know
I 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.

For all of your hard work and dedication, I moved another 1TH over to this pool.  Partially in anticipation for our luck to swing back positive.

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!!

Thank you for all of your hard work Kano.  We greatly appreciate it.  And thanks for sending payments out.

Ha! you know, my best miner threw a leg outa bed too, im back to running the crappy "new r-box" that cant get over 70GH/s, so you're not alone brother!
i think ive worked mine to be the usb to serial converter, im hoping i can talk to it via rs232, once i work out what the pinout is..

Payouts 355952 and 355968 sent
1a40b42d2552f992117aa9f2f6138a58eec25428dadedc51aded9c895fc1c190
7f17f8a0d2f59292e58789ca70b53d8cb4e77d9670aae1bbea4ae6267d995f23
(not confirmed yet)

Yeah it's been havoc on the pool today - sorry about that

I managed to cause all sorts of problem with the database that has only finally reloaded fully a few hours ago.
It would have been all OK but unfortunately, in the process of that I managed to kill the pool a number of times also by using up more than all the ram on the server (48GB )
The side effect of fixing those 3 shifts has, unfortunately, messed up a few shifts at the end, a number of hours ago, due to memory problems, killing ckpool too often and causing everyone to failover, locking up ckdb and disk space problems.

Glitches have now been sorted out.
There's a few commits to ckdb in git revolving around fixing the shift problem and also fixing problems caused by the changes.

Wow, I did a lot of solo mining this morning (failover while Kano is down)!  Unfortunately, I wasn't lucky.  I'm glad to see this pool up again!

The shifts in question look much better now BTW.

My miners have been failing over all morning (here in UK) but as my failover is solo.ckpool its not so bad. (maybe I get lucky)
 I think they are mining on Kano pool at the moment.

I imagine not much sleep for Kano, again.  

(Unrelated to pool maintenance)
All my miners and home server just went offline.  Power company must be messing with the lines again.  Yesterday my modem needed a forced reset and I lost a whole day.  Lets hope everything comes back up correctly when they turn everything back on.  Fingers crossed.

EDIT: everything came back up.  phew

Mine have already switched over to the failover please get it back up so I don't have to give more money to eligius, they are on a week-long backlog for payments.

Yeah I have been watching it all morning.  they must be updating some of the code and updating the database.  My miners still say the pool is alive so its all good.(I hope) 

Whoa. Pools on a meltdown.

Ended up causing pretty much constant ckpool failures due to ckdb eating up all the ram
ckdb was using more than total ram and ckpool can't be allowed to swap since mining definitely should not be getting disk swapping delays

I added in a fix to the problem (seeing a problem happen always helps to make you think hard and fast about how to fix it)
So it's been reloading again from scratch the 1.5 days of data for the last half hour and should be done in about an hour, without all the problems ckdb caused before.

AWWWW....no freakin' way...oh, yes way...I just bricked my S3+. Crap...there goes my main miner. Sorry...gonna be in limp mode until I get a break-out board.

edit; not that I was top of the leader board anyway.

edit2; aww...crap, I think I really did it! Thought I'd try a trick...no luck. Switching to that forum...but I am screwed!!!

Anyone paying attention to the shift data - yep there's now (temporarily) an empty one in there too.
But code seems all ok and ready to roll back the shares/rewards back to yesterday and get it to reprocess them all again.
Will do that soon then post if/when ckdb is finally all back to ok (which might still be a while)
Should be done before the payout is due so there should be no delay when they reach 101.

I'm crossing my fingers for some more bright green!

It is a block party! I'll bring the beers!


Not sure what the server returns as the last block found after a reset, but the app just checks the last known block found stored on your device compared to the servers last block found when it checks for an update.

SO you can run into a few issues. 

If you set your update interval to several hours, and the server actually finds multiple blocks between checks it will only report 1 block found.


Also if your phone happens to pull api data when the server is offline/restarting it will report 0's for all the hash rates. Hence the rate warning. (When I get a chance to learn about ckpool and how it handles these exceptions, I can also handle these exceptions more gracefully in the app.)

I'm also still working on all the promised features, but several other projects are also keeping me busy.

Cheers and party hard!

A 0.080 CDF block ... nice ... only 3hrs until it popped   ... with confirms

Not seen a bright green label since 23rd April.