The Demon Slick
Newbie
Offline
Activity: 182
Merit: 0
|
|
May 07, 2018, 08:17:43 PM |
|
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.
|
|
|
|
LunEm
Newbie
Offline
Activity: 41
Merit: 0
|
|
May 07, 2018, 08:30:20 PM |
|
Block-yeah! Ing-yeah! Party-yeah! Block-ing-party-yeah!
|
|
|
|
rifleman74
Member
Offline
Activity: 658
Merit: 21
4 s9's 2 821's
|
|
May 07, 2018, 08:43:18 PM |
|
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
Newbie
Offline
Activity: 182
Merit: 0
|
|
May 07, 2018, 08:53:40 PM |
|
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
Newbie
Offline
Activity: 103
Merit: 0
|
|
May 07, 2018, 08:58:58 PM |
|
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
Member
Offline
Activity: 238
Merit: 11
|
|
May 07, 2018, 10:16:27 PM |
|
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!
|
Vega 56 | Vega 64 | RX580 | GTX1070 | 1050Ti | S9 | L3+
|
|
|
kano (OP)
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
May 07, 2018, 10:18:39 PM |
|
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)
|
|
|
|
kano (OP)
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
May 07, 2018, 10:20:42 PM |
|
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
Jr. Member
Offline
Activity: 76
Merit: 2
|
|
May 07, 2018, 10:37:33 PM |
|
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 (OP)
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
May 07, 2018, 11:24:41 PM |
|
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!!!
Full Member
Offline
Activity: 350
Merit: 158
#takeminingback
|
|
May 07, 2018, 11:42:28 PM |
|
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 [b][url=https://kano.is/]Try Kano Pool [/url] [/b] Ex: I Mine at Kano Pool [b]I Mine at [url=https://kano.is/]Kano Pool [/url] [/b] Ex: The Best BTCitcoin Pool in the World: Kano Pool [b]The Best [btc]itcoin Pool in the World: [url=https://kano.is/]Kano Pool [/url] [/b]
|
Click these links to learn some truth about Big Corporate mining pools stealing your money and centralizing BTCitcoin!!! Help support the BTCitcoin community!!! Mine your BTCitcoin at a non-Corporate pool!!! BTC: 1ShazamjsPnpWDNnk3n2tAiKGMdXaSjay
|
|
|
fenderltd
Newbie
Offline
Activity: 24
Merit: 0
|
|
May 08, 2018, 12:18:00 AM |
|
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
Newbie
Offline
Activity: 24
Merit: 0
|
|
May 08, 2018, 12:19:21 AM |
|
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 [b][url=https://kano.is/]Try Kano Pool [/url] [/b] Ex: I Mine at Kano Pool [b]I Mine at [url=https://kano.is/]Kano Pool [/url] [/b] Ex: The Best BTCitcoin Pool in the World: Kano Pool [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
Legendary
Offline
Activity: 3528
Merit: 1116
|
|
May 08, 2018, 12:33:54 AM |
|
I am legendary, can you do something bigger
|
BTC | Kano Pool | ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ | | ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ | | ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ |
|
|
|
AerialGopher
Jr. Member
Offline
Activity: 196
Merit: 4
|
|
May 08, 2018, 02:01:22 AM |
|
I vote for a pool re-start.
|
|
|
|
ccgllc
Copper Member
Full Member
Offline
Activity: 658
Merit: 101
Math doesn't care what you believe.
|
|
May 08, 2018, 02:13:02 AM |
|
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?
|
Mined for a living since 2017. Dabbled for years before that. Linux admin since 0.96 kernel and Slackware distributions on (4) floppies...
|
|
|
maddadata
Newbie
Offline
Activity: 85
Merit: 0
|
|
May 08, 2018, 02:20:21 AM |
|
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
Member
Offline
Activity: 490
Merit: 16
1xA921 + 1xA741 + Backup-->1xA6 ;)
|
|
May 08, 2018, 02:31:22 AM |
|
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.
|
The BTCest mining pool (<1% fee): KanoPool***PPLNS rewards averaged over the 5Nd to reduce variance***
|
|
|
rifleman74
Member
Offline
Activity: 658
Merit: 21
4 s9's 2 821's
|
|
May 08, 2018, 02:34:34 AM |
|
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
Jr. Member
Offline
Activity: 196
Merit: 4
|
|
May 08, 2018, 02:35:22 AM |
|
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 )
|
|
|
|
|