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

Get in there! Feels good to get one at 1.08% diff!

Thanks for explaining this.

Firstly, ckdb is a memory resident DB.
The postgresql backend is simply the permanent storage that is only read on a restart and written to with all the permanent data.

ckpool logs all it's data to hourly logfiles (about 1-1.5GB each at the moment) as well as sending it to ckdb.

A ckdb restart reloads the permanent storage DB, then using the info there, it goes and reloads the log files from where the DB was up to.
It can currently reload the log files about 50 times faster than they fill up, so a 1hr log file often takes less than a minute.
It obviously only needs to look in the last 1 or 2 log files since the down time is always very short
It is sometimes 2 logfiles since it may happen just around the time of the log file change over.

At the same time, it has been getting all the new incoming data from ckpool queued up.
When it hits a match in the log file vs the 1st incoming queued message from ckpool, it knows it has all the data it needs from the log files.

At this point everything is back to working - but out of sync.
It then has to sync/catch up on all the data queued in ram, that was transferred from ckpool while ckdb was reloading the log files.
That sync number is the number it shows on the bottom left of the web site
That number also grows whenever ckdb gets behind processing the data from ckpool, usually due to DB write delays.

Currently the reload takes from 3 to 5 minutes and the sync usually only takes a minute or two after that to get back down to zero.

Hi Kano, when ckdb is down, does ckpool keep data in memory until ckdb comes back up and then send all kept data for ckdb to persist?  Or does it keep it in a file and you have to manually transfer data to ckdb?

Not that it's important, I was just wondering. 

I'm not sure what the confusion is, but there was no pool outage.
As it says, uptime is 14hrs.
As I said, it was a ckdb restart.
The pool is made up of 2 parts:
1) ckpool that you mine to that handles all of that on the mining side
2) ckdb that gets all the data and deals with it on the data storage and web side.
An outage of 1) affects the miner.
An outage of 2) doesn't.
Great idea that hey

Is the pool down?
EDIT: Looks OK now .... had 0's all over

Thank you! 

Payout 347282 sent
38f91ec09a55d34e334a7b1858852f707c3f2df0bf8749f786783e8ebb95d489
and confirmed

It's a bit more complicated but the short answer is yes... sort of.

The long answer is that with PPLNS sometimes your payout may be well below the 100% PPS equivalent and other times it may be well above (due to variance).  If you switch over to WestHash when the payouts are going to be averaging well below BTC/TH/day then you benefit.  If you switch when your payouts are going to be well above then you lose out on the higher PPLNS payouts.  Since you can't predict the future then you don't know in advance when those good times will be coming.  In theory the good switches and bad switches should average out thus allowing you to switch at a lower value (e.g. 0.0109) and benefit in the long run (just as with a PPS pool).  This assumes that both pools can be treated as closed systems with no other interaction (more on that in a moment).  In practice they didn't average out for me and I lost BTC0.19 before I accepted that others were right to recommend a higher threshold than I used.

About closed systems-- I can't prove this has a significant effect (I only have 4 weeks of data doing PPLNS alongside WestHash-- which is way to short to make conclusions from), but my intuition says that you can't quite treat the two pools as completely closed systems.  The reason is that there are times when WestHash's rental rate is low enough and this pool is also having a block drought that other miners will decide to rent with a fixed rate from WestHash to mine here.   That alone isn't enough to switch over your miners, but if WestHash has a rush on some altcoin while those rentals are busy mining here then it might result in an increased rental rate high enough to pull your miners off this pool just as a bunch of TH is being tossed here to bust the block.  It could start raining blocks here just a couple days after you have most of your attention over there.  At least, that is what happened to me on multiple occasions when I had the p= set too low.  Can I prove this interaction actually is significant and not just anecdotal-- no, I can't.  It is up for debate how much the rental mining here increases the rate on the later altcoin mining at WestHash (the switch may have been inevitable anyway).  Still, this interference means that there is more going on than simple averages and thus it's "complicated."  There is potential for bias toward missing the better payouts here... or maybe not.  I can't tell for certain, but it didn't look pretty when I ran my own numbers for a lower p=.  I figure that by using a higher p= that it makes the (possible) issue mostly irrelevant.  I would much rather ride the variance here than risk losing the rewards here because I was chasing a rental for some altcoin of questionable benefit over there.

I'm actually considering bumping it up even more than 0.0115 or just breaking the habit.  Profit switching with PPLNS just doesn't seem to be worth it compared to doing so with PPS, but I don't care for the PPS pools out there right now so I keep my miners here.

Well we worked out the cause so it will be fixed in a later release/restart.

--disregard--   I fixed

ID10T error 

Well I restarted the mining process on the .p.. workers to get them use the set diff and I changed it by 1 for the .n.. workers. Only the .o.. workers used the set diff automatically after pool restart.
But all good now 

Yep it worked ok for stonebone's '.p..' and '.o..' workers but not the '.n..' workers
Back on the todo list

Yeah, about 2:10 AM EST, I'll need to figure out a way to handle no response for situations like a restart.

Yep setting it to the same value means it does nothing.

Looking into the logs ...

Probably the ckpool restart or the ckdb restart last night?
During ckdb restart the web is unavailable for a few minutes and during the actual shutdown/restart there's no response at all.
(which equates to various replies from the web server)

ckpoolmonitor.zachmonroe.com is currently not working for most users, I'm not sure what happened, but almost everyones apikeys were erased because the site thought they were invalid. Users will need to log in and put their apikeys back in.

Sorry about the inconvenience.

Yep, same here .... had to go in and "trick" the pool by changing the min diff by a unit (as OK'ing the previous one was also not being applied).
On a positive side, looks like the reported speed is more reflective of what cgminer api reports the 5s speed as ....

Since the pool restart, min diff settings for my workers are not respected anymore (except for 1).

Bug or feature? 

Done