Topic: KanoPool kano.is lowest 0.9% fee 🐈 since 2014 - Worldwide - 2432 blocks - page 1629. (Read 5352322 times)
March 12, 2016, 03:06:59 AM
Working a lot better now. I was 10TH short of where I should be running for a day now, speed back to where it should be. Fresh start is a better chance....
March 12, 2016, 02:50:14 AM
aww false hope. my block notification went off but it was a false positive from the restart.
You better get the coder to fix that 
March 12, 2016, 02:47:41 AM
aww false hope. my block notification went off but it was a false positive from the restart.
March 12, 2016, 02:43:58 AM
CKDB restart completed.
March 12, 2016, 02:19:38 AM
OK, so I finally found the bug that caused the crash in ckdb about a week ago.
I'll do a restart of CKDB in about 50minutes with that bug update.
As usual, no miners will be affected by the ckdb restart.
I'll do it at the first shift summarisation after 07:00 UTC (which should be around 07:20 UTC)
This will mean that I'll actually make the web event blocking code more active also after I've done the update.
Due to the fact that it could crash when I checked the events, I've only enabled a few 'major' event blocking items.
After this I'll enable the more noticeable event blocks - like too many access to certain pages and many others that have been disabled.
However, after the first time when I manages to lock out a lot of users, I'll use the info I worked out then to minimise that happening.
Sigh, greater than 500% ... ok lets see if a ckdb restart can help
Looks like it'll be about 7:30 UTC - about 10min from now. I'll do a restart of CKDB in about 50minutes with that bug update.
As usual, no miners will be affected by the ckdb restart.
I'll do it at the first shift summarisation after 07:00 UTC (which should be around 07:20 UTC)
This will mean that I'll actually make the web event blocking code more active also after I've done the update.
Due to the fact that it could crash when I checked the events, I've only enabled a few 'major' event blocking items.
After this I'll enable the more noticeable event blocks - like too many access to certain pages and many others that have been disabled.
However, after the first time when I manages to lock out a lot of users, I'll use the info I worked out then to minimise that happening.
Sigh, greater than 500% ... ok lets see if a ckdb restart can help
March 12, 2016, 02:13:00 AM
Sigh, greater than 500% ... ok lets see if a ckdb restart can help
If by chance there's a block found right after you may have opened a can of worms here.
March 12, 2016, 01:55:44 AM
Sigh, greater than 500% ... ok lets see if a ckdb restart can help
If by chance there's a block found right after you may have opened a can of worms here.
March 12, 2016, 01:30:17 AM
OK, so I finally found the bug that caused the crash in ckdb about a week ago.
I'll do a restart of CKDB in about 50minutes with that bug update.
As usual, no miners will be affected by the ckdb restart.
I'll do it at the first shift summarisation after 07:00 UTC (which should be around 07:20 UTC)
This will mean that I'll actually make the web event blocking code more active also after I've done the update.
Due to the fact that it could crash when I checked the events, I've only enabled a few 'major' event blocking items.
After this I'll enable the more noticeable event blocks - like too many access to certain pages and many others that have been disabled.
However, after the first time when I manages to lock out a lot of users, I'll use the info I worked out then to minimise that happening.
Sigh, greater than 500% ... ok lets see if a ckdb restart can help
I'll do a restart of CKDB in about 50minutes with that bug update.
As usual, no miners will be affected by the ckdb restart.
I'll do it at the first shift summarisation after 07:00 UTC (which should be around 07:20 UTC)
This will mean that I'll actually make the web event blocking code more active also after I've done the update.
Due to the fact that it could crash when I checked the events, I've only enabled a few 'major' event blocking items.
After this I'll enable the more noticeable event blocks - like too many access to certain pages and many others that have been disabled.
However, after the first time when I manages to lock out a lot of users, I'll use the info I worked out then to minimise that happening.
Sigh, greater than 500% ... ok lets see if a ckdb restart can help
March 12, 2016, 12:58:19 AM
This can't be right.... Last 5 Blocks 8.2hrs 100.8% 30.99% 30.99% 0.0210 322.72% Needs some refreshing maybe
Current one is at the top of every page (and it's not a block as such) March 11, 2016, 11:30:32 PM
This can't be right.... Last 5 Blocks 8.2hrs 100.8% 30.99% 30.99% 0.0210 322.72% Needs some refreshing maybe
Thats the time it took from the first of the five to the last not to current time
March 11, 2016, 11:26:57 PM
This can't be right.... Last 5 Blocks 8.2hrs 100.8% 30.99% 30.99% 0.0210 322.72% Needs some refreshing maybe
March 11, 2016, 10:11:29 PM
Juvia. ... pls send us blocks now!!!
Come-on Juvia --- don't let us down --- give us a string of blocks now!!!
I have something for Juvia let me find it.
Thanks to Juvia for getting me 25 lucky coins recently.... i am pulling out a few of her lucky BTCs from the vault and throwing 666th to the pool - game on!
March 11, 2016, 09:54:46 PM
I have 340th on Kano 24/7 let's do this
Looks like 24 hour 5nd
Looks like 24 hour 5nd
March 11, 2016, 09:21:13 PM
The infinity order is gone and I'm down to 0.0031 at the moment. When I was at 0.0032 it was overfilling my order to 85TH but now that I'm back to 0.0031 it suddenly is respecting my 50TH limit. I think I'll stay put next time and just let it stall rather than play that game.
March 11, 2016, 09:08:26 PM
pushing 1.5 PH here until my btc on nicehash runs out. gotta break this block.
edit: up to 1.5 PH that is... Not gonna pay more than 100% expected payout...
edit: up to 1.5 PH that is... Not gonna pay more than 100% expected payout...
March 11, 2016, 08:55:59 PM
Ok... I'm not happy about that infinity order at 0.0031. I had a nice comfortable spot near the top of the 0.0030 stack before that shut down my order (despite several others under me still having their orders filled).
I can't seem to understand the algorithm for priority in the order list. It drives me crazy sometimes when I have an order run to zero when there are hundreds of orders below me that are still running at 100%.
March 11, 2016, 08:49:08 PM
Ok... I'm not happy about that infinity order at 0.0031. I had a nice comfortable spot near the top of the 0.0030 stack before that shut down my order (despite several others under me still having their orders filled).
March 11, 2016, 08:41:11 PM
423 but last weeks still looks very good.
How long can a block go ? what is possible ? 666,666 was possible but how much longer over that ?
How long can a block go ? what is possible ? 666,666 was possible but how much longer over that ?
I read about an 800% block.
I just bumped to 225th
I lived one of those 800%+ blocks. It was on BitAffNet when I was new to mining and hadn't learned that lesson yet.
March 11, 2016, 08:38:42 PM
423 but last weeks still looks very good.
How long can a block go ? what is possible ? 666,666 was possible but how much longer over that ?
How long can a block go ? what is possible ? 666,666 was possible but how much longer over that ?
Theoretically it is possible for the pool to never solve another block. Just highly unlikely
Here's the CDF stats for percentages up to 1000% (with a few extras thrown in)
Code:
0.39346934028737 50.000% 1 in 1.6
0.63212055882856 100.000% 1 in 2.7
0.77686983985157 150.000% 1 in 4.5
0.86466471676339 200.000% 1 in 7.4
0.91791500137610 250.000% 1 in 12.2
0.93607213879329 275.000% 1 in 15.6
0.95021293163214 300.000% 1 in 20.1
0.96980261657768 350.000% 1 in 33.1
0.98168436111127 400.000% 1 in 54.6
0.99326205300091 500.000% 1 in 148.4
0.99752124782333 600.000% 1 in 403.4
0.99872735771441 666.666% 1 in 785.8
0.99908811803445 700.000% 1 in 1096.6
0.99966453737210 800.000% 1 in 2981.0
0.99987659019591 900.000% 1 in 8103.1
0.99995460007024 1000.000% 1 in 22026.5
So e.g. 100% 1 in 2.7 - 0.63 means that roughly you'd expect, on average, 37% of blocks to be over 100% and 63% to be under 100%0.63212055882856 100.000% 1 in 2.7
0.77686983985157 150.000% 1 in 4.5
0.86466471676339 200.000% 1 in 7.4
0.91791500137610 250.000% 1 in 12.2
0.93607213879329 275.000% 1 in 15.6
0.95021293163214 300.000% 1 in 20.1
0.96980261657768 350.000% 1 in 33.1
0.98168436111127 400.000% 1 in 54.6
0.99326205300091 500.000% 1 in 148.4
0.99752124782333 600.000% 1 in 403.4
0.99872735771441 666.666% 1 in 785.8
0.99908811803445 700.000% 1 in 1096.6
0.99966453737210 800.000% 1 in 2981.0
0.99987659019591 900.000% 1 in 8103.1
0.99995460007024 1000.000% 1 in 22026.5
or ... 1 in 2.7 blocks to be over 100%
Of course with numbers like 500% - 1 in ~148 - you'd need lots of multiples of 148 blocks to expect to be close to the expected value.
i.e. as the 1 in X gets larger, the sample size (block count) needs to be much higher to assume anything about current results.
Edit: this last bit, sample size, is related to the confidence interval.
March 11, 2016, 08:33:36 PM
423 but last weeks still looks very good.
How long can a block go ? what is possible ? 666,666 was possible but how much longer over that ?
How long can a block go ? what is possible ? 666,666 was possible but how much longer over that ?
I read about an 800% block.
I just bumped to 225th
Jump to: