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

[aurel57]

Just canaan having power issues
(I'm sure it's tough work running >2.5PHs of miners)

I see thanks. I was trying to figure out where it was dropping from but I had not looked at the miners list in a while and was not sure what the top miners were throwing this way.

EDIT: It looks like we loss him.  I hope he gets it back up.

[scotty2u2]

Is there a record of payouts per TH per day with kano.is?

I currently use westhash/nicehash, and I'm trying to determine at what price to set my miner to switch over to kano... Or if i should just be using kano to begin with.

Cheers!

There is no site wide version of that but the pool stats table (that I added yesterday, but had to remove, and will be back soon) will give you a range history of pool luck.

Each account has a record of their hash rates per shift and payout calculated for each block found (Shifts, Rewards)

The payout is each time we find a block, and your exact payout in a block is (your shares)/(pool shares) * (99.1% of the block+txn)
Shares counted, for each block payout calculation, are the last 500% difficulty (which is currently ~64hrs)

It takes ~64hrs to ramp up to full pay and when you stop it ramps down over the ~64hrs after that.

The payout per day will vary based on pool luck after each share you submit.
The average expected payout over time is 99.46% PPS - but the daily amount will go up and down every day due to pool luck.
(the average block BTC for the 181 blocks found so far has been: 25.091BTC - so the payout average has been 99.46% PPS)

Restarted ckdb 15 minutes ago.
No miners were injured ... RSPCA made sure of it

Anyway, the Blocks page now shows some history stats as per my earlier post on the subject.
Corrected the Mean% and that of course corrects CDF[Erl] and Luck% since they are based off the Mean%

Nice job on the Block Statistics table, Kano! It looks great. 

[tlhIlwI]

Is there a record of payouts per TH per day with kano.is?

I currently use westhash/nicehash, and I'm trying to determine at what price to set my miner to switch over to kano... Or if i should just be using kano to begin with.

Cheers!

If you are referring to where to set your p= value then higher is better.  I don't really know the correct answer yet, but I do have some experience:

On my four miners I recently tried 102%, 104%, 106%, and 110%.  Despite WestHash having a great run of 110%-120% PPS for several days, by having my miners switch back and forth between WestHash and Kano I ended up earning less than if I had them just on WestHash or just on Kano during  that period (I estimated a loss of about BTC0.19 over 2 weeks).  I've since adjusted my miners to higher values (currently 108% [0.0115], 110% [0.0118], 112% [0.0120], and 115% [0.0125]).  WestHash has been in a drought lately so I don't really have any results for those numbers yet. 

For the most part I've concluded that profit switching on/off PPLNS to chase WestHash isn't really worth it, but it isn't a bad idea to keep around a high switchover just in case something like December (1000% PPS) ever happens again.

[tlhIlwI]

Nice job on the Block Statistics table, Kano! It looks great. 

Yes, very nice!

[aurel57]

Is there a record of payouts per TH per day with kano.is?

I currently use westhash/nicehash, and I'm trying to determine at what price to set my miner to switch over to kano... Or if i should just be using kano to begin with.

Cheers!

If you are referring to where to set your p= value then higher is better.  I don't really know the correct answer yet, but I do have some experience:

On my four miners I recently tried 102%, 104%, 106%, and 110%.  Despite WestHash having a great run of 110%-120% PPS for several days, by having my miners switch back and forth between WestHash and Kano I ended up earning less than if I had them just on WestHash or just on Kano during  that period (I estimated a loss of about BTC0.19 over 2 weeks).  I've since adjusted my miners to higher values (currently 108% [0.0115], 110% [0.0118], 112% [0.0120], and 115% [0.0125]).  WestHash has been in a drought lately so I don't really have any results for those numbers yet.  

For the most part I've concluded that profit switching on/off PPLNS to chase WestHash isn't really worth it, but it isn't a bad idea to keep around a high switchover just in case something like December (1000% PPS) ever happens again.

I agree and that is why I have my S5's that are on PPS set to .012 but my miners here on this pool I do not use on Westhash

[kano]

Nice job on the Block Statistics table, Kano! It looks great. 

Yes, very nice!

Having multiple low counts there (5/10/25) means they swing a lot with a single bad (or good) block.
I'll see how it goes for a few weeks and maybe use fewer low numbers and more larger numbers.

Anyone mathematically, C (and statistically) adept, feel free to check the stats code.
I'm pretty sure it's all correct but if anyone else wants to look over it I'd be grateful:
https://bitbucket.org/ckolivas/ckpool/src/8916a8e1d5caf90f2b8581f188aec7b5ae9f066e/src/ckdb_data.c?at=master#cl-2475

[obfuscated]

Thanks for the feedback all.


tlhIlwI, If I understand correctly, you mine with kano but set the p= value on your westhash entry to 0.0115?  So I'm assuming you find you get better payouts with kano atm.

Would you mind showing me your pool settings?


Based on ZACHM's chart, the 30 day average payouts on kano are slightly higher than westhash (currently 0.0101 BTC/TH/Day).  Does this mean I have to mine with kano for 30 days to see a benefit?  Sorry for my ignorance, I'm kind of new to this 

[kano]

Will be a ckpool udpate/restart in the next 5 minutes.

Done

[stonebone]

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

Bug or feature? 

[pekatete]

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

Bug or feature? 

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

[ZACHM]

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.

[kano]

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.

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)

[kano]

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

Bug or feature? 

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

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

Looking into the logs ...

[ZACHM]

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.

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)

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

[kano]

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

Bug or feature?  

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

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

Looking into the logs ...

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

[stonebone]

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

Bug or feature?  

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

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

Looking into the logs ...

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

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 

[kipper01]

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.

--disregard--   I fixed

ID10T error 

[kano]

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

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

[tlhIlwI]

tlhIlwI, If I understand correctly, you mine with kano but set the p= value on your westhash entry to 0.0115?  So I'm assuming you find you get better payouts with kano atm.

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.

[kano]

Payout 347282 sent
38f91ec09a55d34e334a7b1858852f707c3f2df0bf8749f786783e8ebb95d489
and confirmed