Topic: KanoPool kano.is lowest 0.9% fee 🐈 since 2014 - Worldwide - 2432 blocks - page 1698. (Read 5352367 times)

Пoздpaвляю Фeндep c пoчинoм  Congratulations Fender a first block

Double Block Party on 

Nothing better Then back to back blocks!!!

Restart complete

Oh and just in case anyone didn't realise, only ckdb means no miners were affected at all.

DB restart, maybe? Did not see Kano post a notice and no stats on website.....

Just checking

Let me know if it is working well, I've not touched my S2 for a really long time

There was a reconnect about 3 hours ago (03:45:32 UTC)
It only lasted for 2 seconds
That should have only meant a reconnect in your miners.

kano i added your firmware to my antminer s2 just a min ago i like the layout of it better

anyone having issues with DE

It's magic I tell ya!

Heh well the next block - 399390 - was an interesting one
Confirmed the last 2 payouts: 399279 and 399289

But what actually happened was (of course) that 399289 came due at block 399389, I did the payout, got it into the pool work, then less than 60s later we got a block to confirm them both!
Nice timing.

It also means that the payout caused the block, but of course you can't predict that in advance

Thanks kano for all your hard work.
We are all trying to get that next block for the team.

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:
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:
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.

Great block run overnight!  I'm all for Kano's changes re: the website.  Let's see how they shake out!

i had it set to just under 24 mins or was it 26  .. whatever the default logout value is for php.. just keep it under that and you wont have to keep loggin in..

"It depends on the server configuration or the relevant directives (session.gc_maxlifetime) in php.ini. Typically the default is 24 minutes (1440 seconds), but your webhost may have altered the default to something else." 
http://stackoverflow.com/questions/9904105/php-sessions-default-timeout

Best Regards
d57heinz

I would like to know if 5/6/7/10 fixes the problem lets us know.

:facepalm: @ the person renting huge rental on NH/WH and raising up the prices again. SMH.

Thanks guys for the perspective and recommendations - I have set it to 5/6/7/10 minutes. Hope it would not trigger anymore  bans.

I actually only check the site every few hours as it's mentally draining to watch live stats IMO.

5minutes is the lowest I'd even consider an auto refresh if I needed to actually watch it.

yeah  you are correct.

we make 1 to 8 blocks a day.

so 1 every 10 minutes would be 6 per hour and 144 a day.

since 8 into 144 = 18  even a 10 minute refresh time is 18 looks for each block  on a day where we make 8 blocks.

A good way of looking at refresh rate is how often do we do 2 blocks under 10 minutes?   since if you look every 10 minutes the most that happens is there is one block.

I believe of all 550 plus blocks  three times we did 2 in 10 minutes or less.

So even a ten minute refresh works.