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

Interesting...I read all these notes about restarts, etc. and notice that none of my 6 S3s or my S2 even hiccup for any of them. They're all showing over 11 days of run time (the last time I shut down for a few minutes for cleaning). Maybe being out here in the middle of virtual nowhere has its advantages.

And...mahalo nui loa to droid...whomever he/she is...for the blocks. We're all on the same spaceship here.

 

Let me know if it is working well, I've not touched my S2 for a really long time

Great you ran him off.  

He was there around 480Ths

What is a DROID.TESTLAB who found 399427 and 399442 bloks, and why it is not in the pool statistics? https://kano.is/index.php?k=stats  

It was effectively all disabled from when I last posted but yeah there where a few IPs that didn't seem to clear properly.
Anyone else would be a bug at the moment in the event processing, but anyway that run last night (it's now morning here) gave me some real data to use to sort out what it needs to be.

I'll make the limit higher than this, and may need to make more brackets for counting limits, but seriously, if you are hitting the web site more than a few times a minute, you are wasting your and the web site's time.

There's 2 numbers that are relevant:

1) The 'ckpool' hash rates are only updated once per minute.
Most miner hash rates (specifically all Bitmain miners) are far from reliable even after an hour of mining, so the ckpool<->ckdb code is, by design, one hash rate update per minute, per worker.
At the moment, as the web site says, there's over 8100 workers on the pool and that means roughly 8100 updates transferred per minute between them, or about 135 updates per second. That's more than enough It's not a limiting issue, it's simply that the numbers are more than accurate enough as they are, and doing it even more often won't make them more accurate.
This of course also means that if you use hash rate to detect a problem with your miner, you won't get a better detection by polling any more than a few times a minute (and it's not possible to get a better result since the hash rate isn't a dynamic value no matter how we configured the pool)

2) if you poll the web/API to detect a miner failure on "Last Share", the actual probability of getting a 15s share is:
Expected average share 18SPM (18 shares per minute) so 3.3333 seconds average per share.
A 15s share would be the same as a 450% "Diff"
CDF for 450% (and 900%) is:
So, on average, one in 90 shares is actually expected to average 15s or more, or roughly 288 shares per day.
With 900% (30s) one in ~8100 shares is expected to average 30s or more, or roughly, 3 shares per day.
So any "miner failure" detection based on "Last Share" would average 3 false positives a day is you set the limit to 30s.
I'd suggest 45s minimum for that sort of detection.

Edit: actually to show the 45s and 60s numbers:
So on average, no share for 45s would average about once a month.
If you have 10 miners, then you'd average about 10 false positives a month.

Using 60s, on the other hand, you'd expect to average one false positive per miner per ... 7.4 years
So maybe I should say, anyone doing "Last Share" detection, should use 60s and rarely if ever get a false positive.

Well in case anyone DIDN'T notice that restart ...

Since we did so well before it, that indeed determined that the restart would be a shocker.

Pretty much everyone will have failed over.
Sorry about that. All is back OK now and the hash rate is rising again - now over 21PH and still heading back up.

Here's to hoping for lots of blocks caused by the worst full restart of all the nodes ever

Sorry Delaying the restart for 5 minutes - was just about to and we got a block
Restarts will be at 11:35 UTC

Sorry Delaying the restart for 5 minutes - was just about to and we got a block
Restarts will be at 11:35 UTC