KanoPool since 2014 🐈 - PPLNS and Solo 0.5% fee - Worldwide - 2435 blocks

[The Demon Slick]

I'm curious about the monthly stats, 4th column, "expected". It's been at 3.03 for 4 days now. Is it only going to update when we hit a block,  like the way may didn't show until a block? Surely in 4 days our expectations would rise.

[1713427115]

1713427115

[1713427115]

1713427115

[LunEm]

Block-yeah!
Ing-yeah!
Party-yeah!

Block-ing-party-yeah!


 

[rifleman74]

I'm curious about the monthly stats, 4th column, "expected". It's been at 3.03 for 4 days now. Is it only going to update when we hit a block,  like the way may didn't show until a block? Surely in 4 days our expectations would rise.

Yes, when we hit the next block (assuming in the next 24 hours), it'll jump the expected to 4-5+...part of the reason why Feb looks so "good" is that we never found a last block during the end of that month, so the expected never changed.  

[The Demon Slick]

I'm curious about the monthly stats, 4th column, "expected". It's been at 3.03 for 4 days now. Is it only going to update when we hit a block,  like the way may didn't show until a block? Surely in 4 days our expectations would rise.

Yes, when we hit the next block (assuming in the next 24 hours), it'll jump the expected to 4-5+...part of the reason why Feb looks so "good" is that we never found a last block during the end of that month, so the expected never changed.  

Ah. That's illuminating thanks. I hadn't caught the Feb thing. That's April too then a little bit if I understand correctly.
Edit- no just one day for April

[swanny88]

I'm curious about the monthly stats, 4th column, "expected". It's been at 3.03 for 4 days now. Is it only going to update when we hit a block,  like the way may didn't show until a block? Surely in 4 days our expectations would rise.

Yes, when we hit the next block (assuming in the next 24 hours), it'll jump the expected to 4-5+...part of the reason why Feb looks so "good" is that we never found a last block during the end of that month, so the expected never changed.  

6 blocks are expected already since the first one was 300 percent unless we hit a block very shortly it will be two 300 percent blocks. 

[nazzer]

The only thing that's wrong, is that THIS BLOCK NEEDS TO DIE!

I'm expecting a lot of 100% blocks after this!

I don't think Kano could argue with the veracity of this comment.

I've got good news and bad news ...

The bad news: we're always expecting blocks at 100% from "now"

However, I've got good news too!

1) We always expect blocks at 100%
2) Over time, we expect to be at 100%


MINE ON!

[kano]

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)

Code:

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)

[kano]

I'm curious about the monthly stats, 4th column, "expected". It's been at 3.03 for 4 days now. Is it only going to update when we hit a block,  like the way may didn't show until a block? Surely in 4 days our expectations would rise.

Yes, when we hit the next block (assuming in the next 24 hours), it'll jump the expected to 4-5+...part of the reason why Feb looks so "good" is that we never found a last block during the end of that month, so the expected never changed.  

Ah. That's illuminating thanks. I hadn't caught the Feb thing. That's April too then a little bit if I understand correctly.
Edit- no just one day for April

It's the first block for every month.
It's not a mathematical anomaly caused by some specific choice - it's random.

The Monthly table is the blocks found during that month.

[Experimenter]

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.

Yes, I read the description you posted some time ago, and I fully agree - it's a great way to see if a miner went offline for any reason. But it won't let me see if a miner lost some power (i.e. due to a failed hash board).

That's why I would like to check for the hashrate, as (under the normal conditions) the hashrate is expected to be at about the same level - at least it shouldn't drop significantly. Hence, my question of whether I understand the meaning of w_hashrate5m / w_hashrate1h / w_hashrate24hr properly (I guess I don't).

[kano]

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.

Yes, I read the description you posted some time ago, and I fully agree - it's a great way to see if a miner went offline for any reason. But it won't let me see if a miner lost some power (i.e. due to a failed hash board).

That's why I would like to check for the hashrate, as (under the normal conditions) the hashrate is expected to be at about the same level - at least it shouldn't drop significantly. Hence, my question of whether I understand the meaning of w_hashrate5m / w_hashrate1h / w_hashrate24hr properly (I guess I don't).

Yeah the ckpool hash rates are not really a point in time thing ... so relying on them to detect problems isn't highly reliable.

If you have a lot of miners, and don't have any reliable direct miner monitoring software, it's best to look at the workers page once in a while
and then click on the 2 different sortings at the top
"Last Share" and "Hash Rate"
and see what's at the bottom.

You can also use the "Shift Graph" to see how a single worker is performing over time.

[Shazam!!!]

Big Welcome to our new members!!! If anyone would like to help Spread the word and, spark the interest of potential new members,
here's a few Kano Pool Signature Banners:

How to add it:

Go to profile>forum profile information>paste in signature box>change profile button>enjoy!

note: be sure to copy everything correctly. Results vary depending on forum rank.

Ex:
Try Kano Pool

Code:

[b][url=https://kano.is/]Try Kano Pool [/url] [/b]

Ex:
I Mine at Kano Pool

Code:

[b]I Mine at [url=https://kano.is/]Kano Pool [/url] [/b]

Ex:
The Best BTCitcoin Pool in the World: Kano Pool

Code:

[b]The Best [btc]itcoin Pool in the World: [url=https://kano.is/]Kano Pool [/url] [/b]

[fenderltd]

Not much, but added another S9 today. Going to be interesting when summer really hits here in Texas!   
Current temps are high of 76  on one, and 84 another. Need some more 6 inch duct to bring the 84 down to in the 70's!

Now lets gets some freakin BTCLOCKS BTCABY!!!

[fenderltd]

Big Welcome to our new members!!! If anyone would like to help Spread the word and, spark the interest of potential new members,
here's a few Kano Pool Signature Banners:

How to add it:

Go to profile>forum profile information>paste in signature box>change profile button>enjoy!

note: be sure to copy everything correctly. Results vary depending on forum rank.

Ex:
Try Kano Pool

Code:

[b][url=https://kano.is/]Try Kano Pool [/url] [/b]

Ex:
I Mine at Kano Pool

Code:

[b]I Mine at [url=https://kano.is/]Kano Pool [/url] [/b]

Ex:
The Best BTCitcoin Pool in the World: Kano Pool

Code:

[b]The Best [btc]itcoin Pool in the World: [url=https://kano.is/]Kano Pool [/url] [/b]

Thanks BTCro, I changed mine but only can do the basic one I guess!

[yxt]

I am legendary, can you do something bigger

[AerialGopher]

I vote for a pool re-start.

[ccgllc]

I vote for a pool re-start.

And what pray tell would you expect that to accomplish?  Besides causing all of us to fail over to our backup pools that is?

[maddadata]

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.

Yes, I read the description you posted some time ago, and I fully agree - it's a great way to see if a miner went offline for any reason. But it won't let me see if a miner lost some power (i.e. due to a failed hash board).

That's why I would like to check for the hashrate, as (under the normal conditions) the hashrate is expected to be at about the same level - at least it shouldn't drop significantly. Hence, my question of whether I understand the meaning of w_hashrate5m / w_hashrate1h / w_hashrate24hr properly (I guess I don't).

Yeah the ckpool hash rates are not really a point in time thing ... so relying on them to detect problems isn't highly reliable.

If you have a lot of miners, and don't have any reliable direct miner monitoring software, it's best to look at the workers page once in a while
and then click on the 2 different sortings at the top
"Last Share" and "Hash Rate"
and see what's at the bottom.

You can also use the "Shift Graph" to see how a single worker is performing over time.

I have successfully used the shift graph to diagnose problems w/my farm.  I had a psu that melted the breakout board and I noticed a 2/3 hashrate drop on that worker when ambient temps were warm during the day.  also had an airflow issue on one worker during warm ambient temps causing a hashboard shutdown.  checking the worker page gave me cause for concern...but not panic, but the shift graph gave me solid evidence there was something wrong.  In both cases the pool stats were enough for me to diagnose a problem if I could interpret the data right.  When my psu went down I saw that worker drop by 2/3 of both hashrate and share rate, then followed up by downward line on the shift graph, bottoming out at 1/3 of normal hash for that machine.  A "long share" would not cause this type of data.  sure enough (i use hp server psus...2 per machine) the breakout board chernobyled on the "2 hashboard" psu.  fresh psu...and all good.  Same deal w/my s9 when it sucked a leaf...combo of rising ambient temps, then share rate/hashrate drop and worker graph drop on the shift graph.  There's a pattern in the data that you can use to diagnose problems purely from Kano's stats, but you gotta interpret it right!    

[BSGMiner]

I vote for a pool re-start.

And what pray tell would you expect that to accomplish?  Besides causing all of us to fail over to our backup pools that is?

Lol. Some superstition that's been floating around for a while that it brings a block. Hehe

P.S. New sig: Kano Pool Blocks... No restart required.

[rifleman74]

I vote for a pool re-start.

And what pray tell would you expect that to accomplish?  Besides causing all of us to fail over to our backup pools that is?

Lol. Some superstition that's been floating around for a while that it brings a block. Hehe

P.S. New sig: Kano Pool Blocks... No restart required.

It did work rather well back in September/October.    Within an hour of restart, block was found.


MINE ON WITH KANO-SAN!

[AerialGopher]

I vote for a pool re-start.

And what pray tell would you expect that to accomplish?  Besides causing all of us to fail over to our backup pools that is?

Lol. Some superstition that's been floating around for a while that it brings a block. Hehe

P.S. New sig: Kano Pool Blocks... No restart required.

If you look back in history.  Everytime there has been long blocks, and then a "restart" for one reason or another there has been a block found very shortly after, and the near 100 % will continue for a while.

I have seen this numerous times since December that this happens almost like clock work.


YES, saying that it does nothing, becuase of probability, can be an accurate statement, but when this happens too often, there is more to this than just probability.


I dont remember the date, but a while ago, Kano said he needed to do a pool restart due to a logging issue, and then the double restart cuased another issue, and he found why in the code this issue happened.  after that, blocks were normal again, near 100 %  but prior to that there were long blocks.. like now.

Persoanlly, I think there is an issue in some detail yet to be discovered, that after the pool runs for an extended period of time, or so many shares, blocks are not found as near 100% as they should. ( when you use "probability" alone )