I have a question about the pool API. The workers data contains w_hashrate5m / w_hashrate1h / w_hashrate24hr fields. I thought that's the average hashrate for 5m / 1h / 24h respectively. But I guess I am not exactly right about it. I just faced a situation when my hashing power went down due to a network connectivity. I saw the hashrate numbers declining quickly, and all of them - including the 24hr rate - went to 0. When network issue was sorted out, the numbers were back to their normal values again - including the 24h value.
I understand the 5m / 1h numbers to change fast when my machines are down. But why does the 24h also drops so quickly ? I didn't measure exact duration of the downtime itself, but it was somewhat around 4 hours. So I expected the 24h hashrate value to reduce by ~20% only...
P.S. I'm just looking for a more-or-less reliable way to get informed when any of my miners are not hashing properly. Right now I have a script calculating the total hashrate (based on 'w_hashrate5m' numbers from the API) and comparing it to a pre-defined value. I also found some very good hints from Kano
here - will look into adding that check as well.
Last Share (w_lastshare) for a worker.
If it's more than 120 seconds old then the miner isn't sending shares to the pool any more.
It's a unix timestamp - and the 'current' time of the data is 'STAMP'
So if ((STAMP - w_lastshareacc:NNN) > 120) then workername:NNN needs looking into
Shares are like blocks, only there's a lot more of them.
The worker should average about 18 shares per minute or 3.333 seconds per share.
So using the CDF table (the lower end of the table)
0.99995460007024 1000.000% 1 in 22026.5
0.99999385578765 1200.000% 1 in 162754.8
0.99999998477002 1800.000% 1 in 65659969.2
0.99999999996225 2400.000% 1 in 26489113602.6
1.00000000000000 3600.000% 1 in 4503599627370496.0
... a side note to a person on another pool that recently reminded people of his lack of knowledge here in the past ... LOOK! it's not linear
A 1000% share is 33.33 seconds and expected 1 in 22026.5 x 3.333 seconds = 73421 seconds = or about 20.4 hours
So there's not much point looking for a 1000% share since it will happen on average a bit more than once a day per miner.
A 1200% share is 40 seconds and expected 1 in 162754.8 x 3.333 seconds = 542516 seconds = or about 6.3 days
So there's not much point looking for a 1200% share either
A 2400% share is 80 seconds and expected 1 in 26489113602.6 x 3.333 seconds = about 2798 years
Now there is an interesting thing to look at that number
If you have 2798 miners, then you'd expect it once per year.
If you have 2798*12 miners, then you'd expect it once per month
etc.
A 3600% share is 120 seconds ... and probably never gonna happen no matter how many miners you have
(4503599627370496.0 x 3.333 = about once every 475 million years)
So if you go for 120 seconds you're sure to know that - given some SPS variance vs 3.333 seconds - any worker that's not submitted a share for 2 minutes (120 seconds) is not submitting shares properly.
(if you have only one proxy or miner connected to that worker)
