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

[pavlidmavrom]

ok i got it. thanks for your answers .

[Avitoprime]

First of all, thank you Kano for such a wonderful pool. I'm here since January and haven't had any problems till some days ago. I have two S7s. They both do 5Th/s in bitmain monitor. So in total 10 Th/s. And it was 10Th/s on kano.is But few days ago my speed droped about 1 Th/s on kano.is But in monitor it is still showing 10Th/s total. Where could be the problem?
P.S. the speed dropped on 22 Feb

[727miner]

First of all, thank you Kano for such a wonderful pool. I'm here since January and haven't had any problems till some days ago. I have two S7s. They both do 5Th/s in bitmain monitor. So in total 10 Th/s. And it was 10Th/s on kano.is But few days ago my speed droped about 1 Th/s on kano.is But in monitor it is still showing 10Th/s total. Where could be the problem?
P.S. the speed dropped on 22 Feb

Try rebooting them, some tend to slow down after time.

[Legacy2005]

diff bug strikes again? what diff you running on the machines?

rebooting may work as well.

[clgrissom3]

Block by dance191!  That would be his 4th on the Acclaim Board!  Way to go!

[-ck]

Sorta kinda dumb question...but I figured this was the place to get a concise answer. There were some code changes recently, and since then I've noticed all my machines, 6 S3s and one S2, have gone to 1.042 diff as a pool-assigned value. Seems(?) a bit high for an S3, at least. Should I reset these manually to something like 400? Or wait and see? The rewards are down slightly, which doesn't seem to match any change in the pool hash rate. Is there a relationship there?

-ck knows about this,said he will fix shortly. Was a bug he introduced.
He said go manual until his fix is in.

The fix is in the code awaiting a pool restart. Kano rightly tries to limit the number of restarts to pull in new changes, although when the code is stable miners barely notice the restarts. However there was some instability in the newer code pulled in a couple of weeks ago and we always feel bad when there is any interruption to mining whatsoever. You have to understand how hairy it is restarting a production server with almost 10k clients connected concurrently. While I do lots of testing of code before deploying it, some code issues you can only see in production due to the nature of the load it's exposed to. Having said that I'm trying to find a nice stable point where there is no requirement for further pool restarts any time in the near future. The current pool code on the current server hardware could now easily handle 20x as many miners, though continuous improvements in the database code to keep up as the load increases will need to be implemented. Database restarts for upgrades don't affect mining so they're a lot easier and safer to perform at regular intervals.

[kano]

... and since we just found another block ...

I'll plan the restart to include the Worker Diff fix in 35 minutes - when the minute hand next hits 30

This will be one of those quick ckpool restarts with only very few miners affected.
Most miners will just see a cgminer reconnect.

There will also be a CKDB restart much later today to add in the code to track high diff shares in the database.
I've been checking this manually using the logs, but of course having the code do it is better
I'll post again when I push that update and am ready to restart CKDB, it's early morning here now, that update will be this afternoon.

[wolfen]

Sorta kinda dumb question...but I figured this was the place to get a concise answer. There were some code changes recently, and since then I've noticed all my machines, 6 S3s and one S2, have gone to 1.042 diff as a pool-assigned value. Seems(?) a bit high for an S3, at least. Should I reset these manually to something like 400? Or wait and see? The rewards are down slightly, which doesn't seem to match any change in the pool hash rate. Is there a relationship there?

-ck knows about this,said he will fix shortly. Was a bug he introduced.
He said go manual until his fix is in.

The fix is in the code awaiting a pool restart. Kano rightly tries to limit the number of restarts to pull in new changes, although when the code is stable miners barely notice the restarts. However there was some instability in the newer code pulled in a couple of weeks ago and we always feel bad when there is any interruption to mining whatsoever. You have to understand how hairy it is restarting a production server with almost 10k clients connected concurrently. While I do lots of testing of code before deploying it, some code issues you can only see in production due to the nature of the load it's exposed to. Having said that I'm trying to find a nice stable point where there is no requirement for further pool restarts any time in the near future. The current pool code on the current server hardware could now easily handle 20x as many miners, though continuous improvements in the database code to keep up as the load increases will need to be implemented. Database restarts for upgrades don't affect mining so they're a lot easier and safer to perform at regular intervals.

Thanks -ck, I know how production code can be a bear.
Glad you figured it out, you are the MAN.
Always nice to get the warm and fuzzy explanation.
I have complete confidence in you sir.

[TTravis]

Thanks Kano.  Maybe this Diff fix will bring us some more luck.  I am glad I moved to your pool.

Tom

... and since we just found another block ...

I'll plan the restart to include the Worker Diff fix in 35 minutes - when the minute hand next hits 30

This will be one of those quick ckpool restarts with only very few miners affected.
Most miners will just see a cgminer reconnect.

There will also be a CKDB restart much later today to add in the code to track high diff shares in the database.
I've been checking this manually using the logs, but of course having the code do it is better
I'll post again when I push that update and am ready to restart CKDB, it's early morning here now, that update will be this after noon.

[dance191]

Block by dance191!  That would be his 4th on the Acclaim Board!  Way to go!

Thanks, but really all the credit goes to the pool operators!   I have found a couple blocks in almost as many days with ~ 320 TH/s, the luck here is really impressive...

On a side note, I am working on getting a lot speed pointed to this pool in a few weeks ~ few months.  There is no reason this pool shouldn't be one of the largest, it is just a matter of time.  Good job Kano & CK, you guys have created something really impressive!!!

[kano]

... and since we just found another block ...

I'll plan the restart to include the Worker Diff fix in 35 minutes - when the minute hand next hits 30

This will be one of those quick ckpool restarts with only very few miners affected.
Most miners will just see a cgminer reconnect.
...

Diff fix applied a few minutes ago.
Very tidy restart, only 7 users of the 887 didn't reconnect straight away.
All good.

[cavaliersrus]

awww no more 13TH/ 11Th anymore on the right hand side

[zOU]

4/6 workers not reconnected... i'll checked when I'm home in 90mn.

Hopefully they failed over to ck solo pool :p

[GigaBit]

All my machines are moved over now, all of them.
First thing I noticed right away is how much nicer it is on the miners themselves.
I've yet to test the fluctuation but I figure it'll be a bit off as long the S1's are running.
From what I saw, it's rather stable, except a reset but whatever.

Profit wise, I'll only know next week.
The miners sound much smoother already though, more unison, not as erratic like F2Pool... but it kinda sucks, I was making good coin there too, they got a on a block streak due to all the new hash power.
I take a bunch of of Asians got their miners already and went straight to F2Pool; Bitmain went right down, that's because they shipped a bunch; at least F2Pool fills their blocks 98% of the time.
Not every efficient use of my hashing power though, even with merge mining, just makes the whole thing clunky.
The beeping got annoying, this means hardware errors, pools with old code do this so I'm glad to be here!

[Mikestang]

Diff fix applied a few minutes ago.
Very tidy restart, only 7 users of the 887 didn't reconnect straight away.
All good.

I noticed the website only reports a single hash rate in the upper right corner now, what interval is it reporting?

[Real-Duke]

Diff fix applied a few minutes ago.
Very tidy restart, only 7 users of the 887 didn't reconnect straight away.
All good.

Works on my side, thanks 

[-ck]

All my machines are moved over now, all of them.
First thing I noticed right away is how much nicer it is on the miners themselves.

Welcome aboard. How much hashrate are you in total, if I may ask, and what miners are you running besides the S1s?

[kano]

Diff fix applied a few minutes ago.
Very tidy restart, only 7 users of the 887 didn't reconnect straight away.
All good.

I noticed the website only reports a single hash rate in the upper right corner now, what interval is it reporting?

The 5 minute value until the pool has been running for an hour.
Then both the 5min and the 1hr for all who've been mining non-stop for an hour.

[Aephyr]

I have two miners that won't reconnect to the pool. An s1 and s3. Happened about an hour ago. Not sure what the issue is, since my other 3 miners reconnected with no problem.

[kano]

Block by dance191!  That would be his 4th on the Acclaim Board!  Way to go!

Thanks, but really all the credit goes to the pool operators!   I have found a couple blocks in almost as many days with ~ 320 TH/s, the luck here is really impressive...

On a side note, I am working on getting a lot speed pointed to this pool in a few weeks ~ few months.  There is no reason this pool shouldn't be one of the largest, it is just a matter of time.  Good job Kano & CK, you guys have created something really impressive!!!

The more you bring over the closer we get to 10%
Sounds good

Heh, the credit goes to each little piece of miner hardware that finds it's block, but it is completely random of course.
But then the pool for making sure it gets out there on the rest of the bitcoin network as fast as possible