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

[bitwitt]

One of my worker instances is a collection of 30 U2's. It is stuck with the pool default Diff at 1.02k since the restart. I'm guessing that won't change till everything is back in sync?

Hmm ...
If you have a worker diff on the web site, then yes the sync will affect that.
If on the other hand, you don't have a worker diff specified, it will just take a while for ckpool to decide to change the diff.
Diff starts at 1024 by default.

Unfortunately, the auth part of the reload is taking quite a long time, so stats are still not up on the web site yet.
... that was the main problem, authorisation was taking too long so everyone was failing to authorise and repeat authorising.
That's ok for normal workers, but for the few big miners with thousands of connections, it wasn't able to deal with it, thus why the code change I mentioned above that will go in later today also.

Any updates?  I have some miners that have gone back to CK but others that have not.

It's times like this I don't envy you.  Thank you for your hard work.

[1714148402]

1714148402

[1714148402]

1714148402

[1714148402]

1714148402

[1714148402]

1714148402

[kano]

I set it on the website, to 46 I think but this instance is still mining at 1.02k even though failover returned to Pool 0 about 45 mins ago. Usually when I have to restart for reasons on my end, I get a couple minutes worth of rejected- share above target. But not this time, just kinda takes awhile to get one at 1.02k min.

Well the actual diff you are submitting shares does not affect the expected payout.
A lower diff just means you submit more lower diff shares so you get less variance in your accepted share rate.
However, over the length of a block (like the current one around 200%) it will make no noticeable difference.

[ZACHM]

It's times like this I don't envy you.  Thank you for your hard work.

Absolutely!

[kano]

One of my worker instances is a collection of 30 U2's. It is stuck with the pool default Diff at 1.02k since the restart. I'm guessing that won't change till everything is back in sync?

Hmm ...
If you have a worker diff on the web site, then yes the sync will affect that.
If on the other hand, you don't have a worker diff specified, it will just take a while for ckpool to decide to change the diff.
Diff starts at 1024 by default.

Unfortunately, the auth part of the reload is taking quite a long time, so stats are still not up on the web site yet.
... that was the main problem, authorisation was taking too long so everyone was failing to authorise and repeat authorising.
That's ok for normal workers, but for the few big miners with thousands of connections, it wasn't able to deal with it, thus why the code change I mentioned above that will go in later today also.

Any updates?  I have some miners that have gone back to CK but others that have not.

It's times like this I don't envy you.  Thank you for your hard work.

Well the only issues for the last hour should have been that you can't see the web site.
Mining dropped off twice much earlier but it should only have been the web site that was unavailable after the 2nd time.
Web is back up now (ckdb reload has completed properly) and ckdb is syncing with ckpool (that red number at the bottom left)
Once that reaches 0 (may take a while) all the web site should be up to date.

[bitwitt]

Well the only issues for the last hour should have been that you can't see the web site.
Mining dropped off twice much earlier but it should only have been the web site that was unavailable after the 2nd time.
Web is back up now (ckdb reload has completed properly) and ckdb is syncing with ckpool (that red number at the bottom left)
Once that reaches 0 (may take a while) all the web site should be up to date.



Thanks for the update. Time to round up  some wild miners, it reminds me of trying to find cattle when the pasture gate is left open.

[kano]

... the separation of ckdb and ckpool makes for some interesting results
We just found block 339142 ... awaiting a confirm.
The web will show it with the actual stats and time that it happened once the sync completes

Confirmed
https://blockchain.info/block/000000000000000008aed20f57154cd55c2519e64e65dc072ed61eefe4dc1675

[dmwardjr]

Thanks for your hard work in putting this pool together and for keeping it going!

BIG thumbs up!!!

[kano]

... and in case anyone didn't notice
We just found another one at 58.37% of expected (network diff)

[Digitalmocking]

... and in case anyone didn't notice
We just found another one at 58.37% of expected (network diff)

Yay, I felt a little silly joining right as the pool hit a +210% block, I felt like a bad luck charm.

[kano]

... and in case anyone didn't notice
We just found another one at 58.37% of expected (network diff)

Yay, I felt a little silly joining right as the pool hit a +210% block, I felt like a bad luck charm.

... and to really get that worry off your chest
We just found another one at 3.44%

Edit: so that makes 3 blocks, total under 300%

[Beachguy]

I love it when the pool gets blocks......like
bam-dee bam-BAM   

[ZACHM]

Nice to see the blocks coming again, that 27 hours felt like forever.

[kano]

Nice to see the blocks coming again, that 27 hours felt like forever.

It was only 210% - wait until we hit a 800% one day (maybe) then you'll be wondering why you were mining
(longest so far is 525%)

Meanwhile - I think that's a record
New block (awaiting confirm) by a user with 2.18THs!

Edit: confirmed

[OVRGRO]

damn greenegg barely missed out on winning that prize...

[xZork]

damn greenegg barely missed out on winning that prize...

just goes to show that anyone could of won! 

[Beachguy]

You just never know do you.
I think of it like to lottery and a miner is the price of entry.

[n3rvi0zz0]

hi, sorry if i disturb someone but, i dont have clever the payments, where the pool do the payments? im running my rig in ckpool im check the stats and 11th 10workers all correct but in the last 24h i didnt get any payment, im wait payments from the block  338977

please confirm me if im wrong i cant check stats

[kano]

hi, sorry if i disturb someone but, i dont have clever the payments, where the pool do the payments? im running my rig in ckpool im check the stats and 11th 10workers all correct but in the last 24h i didnt get any payment, im wait payments from the block  338977

please confirm me if im wrong i cant check stats

338977
https://blockchain.info/tx/cd38750a19285691bfc5e015f6a4db0b58a182f391aa57fc1a54027457f2fb2a

[n3rvi0zz0]

Many thanks kano, i found my wallet there, i have from this and from the 339142 last two still for confirmations rigth?

[kano]

The next payout, 339142, will be delayed a few hours.

Short version: testing code on test pool, awaiting that test result, then will restart ckdb on live pool and then can run payout.

Extra comment: these changes below are all ckdb related, so as usual should not affect your mining, just the usual data outages on the web site and delays syncing the web site while ckdb does it's reloading each time.

Long version:
During the drama yesterday I restarted ckdb in a 'restricted' mode (the -w option) where I can tell it to only load a limited amount of share info.
I set it to only load to block 338977 (currently ~12million records) which means that since the 339142 payout will extend back before the point when we found block 338977, I'll need to restart ckdb in full mode before I can do the payout.
Late last night (1:30am) I manually ran the markers code to reduce all the sharesummaries, older than payout 338977, to a small number of markersummaries, so a full restart of ckdb will have all the data needed (of course) but also not use up all the ram loading more than 50million sharesummaries, that's back down to about 15million (the conversion of sharesummaries to markersummaries is usually around 1000th i.e. 1 million sharesummaries averages out to be about 1000 markersummaries - the shift changes will convert 1,000,000 sharesummaries to about 10,000 markersummaries)
I also (late last night) copied the whole pool database to a test server that has the new updated ckdb shift code (that's now completed) and I am awaiting it to run fully on the test server to see there's no issues with that.
Once that's done, I'll restart ckdb on the live pool (but without the final shift changes) and do the 339142 payout.

Later today, I'll do the shift code update on the live pool - after the test server shows all things worked as expected.
I've been doing a lot of testing there already, but I think this last version should be all OK, and I wanted to test it on the full live db, copied to the test server.

This will be the implementation of the 50 minute shifts I've mentioned for a while, but finally got it ready to go.

Currently, payouts extend a bit beyond the 5N 500% PPLNS point I keep talking about. On average by half a shift.
Shifts currently are usually 30s so on average it's 15s of extra shares included in each payout.

The new shift will be (usually) 50 minutes, so on average the payout will extend half a shift, or 25 minutes extra, back past the 5N 500% PPLNS point.

So the payouts for the blocks after 339142 will use the new 50 minute shifts - and they will also be delayed (later) today until after I do the shift changes.

I'll update later as things progress.

P.S. whenever I say "today", "tonight", etc I am of course talking about my local time which is AEST or currently UTC+11/GMT+11
(and currently 9:30am 17-Jan)