...
I would like to know if 5/6/7/10 fixes the problem lets us know.
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:
0.98889100346176 450.000% 1 in 90.0
0.99987659019591 900.000% 1 in 8103.1
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:
0.99999862904091 1350.000% 1 in 729416.4
0.99999998477002 1800.000% 1 in 65659969.2
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.
My auto-refresh settings, the windows are set at 1min (workers page) and 5 minutes for the other 3.
I had to do a faster refresh for the workers page because all my rentals are monitored there too.
I will stick to these numbers to comply with kano access rules, so that I wont get banned.
Appreciate any comments or recommendations.
