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

[ZACHM]

Wow I didn't notice the second block.  ZACHM's monitor only notified me of the first (or at least I only received the first email) so I hadn't checked the site yet.  When I saw the thread and I immediately headed to blocktrail and sure enough.  Go go kano's ckpool

Hey that's right, didn't get two emails for the double block. Just one. I just happened to poke the pool front end and was freaked out by the second block.
Was more fun that way.

Yeah, I'm looking into this right now, I'm not sure why we did not get two emails.
At first I thought the blocks were too close together, but they were about 10 minutes apart so that should have been fine.

OK, I figured out what I did.
Earlier when I was making sure the Dropped Worker notification was set to only notify for about 30 minutes, I added a line to the code to make sure it was comparing notifications time of the same timezone. This resulting in the new blocks being added to the database with the wrong timestamp and therefore the part that checks if there is a new block was seeing those blocks as being in the future and not comparing the newest one to the one before it.

I think I got it all straightened around now.

I hate date/time stuff, I really should just switch everything over to UTC like Kano has, and just use the new STAMP feature he added to the API... It is on the todo list.

[kano]

...
I hate date/time stuff, I really should just switch everything over to UTC like Kano has, and just use the new STAMP feature he added to the API... It is on the todo list.

linux - "# info date"

28 Date input formats
*********************

First, a quote:

     Our units of temporal measurement, from seconds on up to months,
     are so complicated, asymmetrical and disjunctive so as to make
     coherent mental reckoning in time all but impossible.  Indeed, had
     some tyrannical god contrived to enslave our minds to time, to make
     it all but impossible for us to escape subjection to sodden
     routines and unpleasant surprises, he could hardly have done better
     than handing down our present system.  It is like a set of
     trapezoidal building blocks, with no vertical or horizontal
     surfaces, like a language in which the simplest thought demands
     ornate constructions, useless particles and lengthy
     circumlocutions.  Unlike the more successful patterns of language
     and science, which enable us to face experience boldly or at least
     level-headedly, our system of temporal calculation silently and
     persistently encourages our terror of time.

     … It is as though architects had to measure length in feet, width
     in meters and height in ells; as though basic instruction manuals
     demanded a knowledge of five different languages.  It is no wonder
     then that we often look into our own immediate past or future, last
     Tuesday or a week from Sunday, with feelings of helpless confusion.
     …

     —Robert Grudin, ‘Time and the Art of Living’.

Yeah I actually thought 'now' was already in the API ...
when I noticed this missing the other day, I added 'STAMP' in immediately.

[ZACHM]

Hi Zach,

I'm curious...

Will the 7 day average, 14 day average, 30 day average and 60 day average on "Rewards" be brought back to the monitor?  

I'm assuming its away for now because you may be doing some work on it [Maybe cause the math was wrong or something]?

Yes, I am working on something....
And yes the math was wrong too.

Check it out now, a little rough for now, but it is working.
You can choose a start date and end date and see your rewards for that duration, with a total BTC, average Hashrate, and average BTC/THs/Day.

Yeah I actually thought 'now' was already in the API ...
when I noticed this missing the other day, I added 'STAMP' in immediately.

When you posted that the other day I thought the same thing "Wasn't that already there?"
So I checked my code that gets the info and nope I was adding in the timestamp myself.

[kano]

I'm curious, given the pool has increased in size almost 4X over the past couple weeks, does this shift development priorities for "working on thing X" to "working on thing Y"?  Is there more incentive to work on certain aspects of the pool given it's growth, or are development priorities such that they area independent of pool size?  Since I am just a "dust miner" I expect my perspective of what should be done with the pool would be much different than someone running 100+ TH, just wondering if development has a similar experience.
...

Well growth means I've gotta make sure it keeps working with the higher work load.

I did already do something about that only 2 weeks ago.
https://bitbucket.org/ckolivas/ckpool/commits/de3be722cdb60eaaa59d67372afa90f68c205036

but that was the results of work done a month ago.
https://bitbucket.org/ckolivas/ckpool/commits/c7f03c2a331f111696f0e8163f295461711e8eb5

i.e. the answer being that, although I suspect ckdb could handle that 10% network limit I've mentioned I would prefer the pool not to exceed, there's still more changes I've determined that will allow it to be 2 or 3 times higher and thus no issue of being borderline if we ever did grow that much.
Those changes are in the 'when I have enough time to do them, but sooner rather than later' arena, since they are more significant.

Other changes, that I've discussed with some people, are driven by the 'expansion' of the pool into different areas.

Though, sometimes it's as simple as someone mentioning something, that I agree needs changing, and that's easy to change, and I'll go change it

If it requires a lot of time to change, currently it wont be happening unless it's urgent.

[sorry2xs]

has this pool ever had back to back in its history 

[clgrissom3]

My fastest miner S7 is doing a SHARE RATE of 3.93THs and a HASH RATE of 4.90THs , why does that differ ?

What is what and is that normal ? my slower miners does not have that big difference.

https://i.imgur.com/GqJLH8F.jpg

This copy of S7 is overclocked to 750 Mhz, it have no X-ed CPUs in the status box.

You have to also remember your hash rate is cyclic and is never a fixed rate.  It's pretty difficult to take a snapshot set of numbers and say it should be a certain way.  That's why the hash rate chart is always something like this...

[citronick]

Kano, CK,

The SG node is still down however ping works. I am sure you guys are investigating - do help report once you get to the bottom of it.
Also, let me know if you need any help from my end since I am in SG.

TMT

Yeah SG went down at 2016-01-05 16:37:51 UTC - sorry about that, I've not yet setup the alerts to wake me up on those new nodes.
I will make sure I do that today.

I restarted it at 2016-01-05 19:22:48 UTC (23min ago) and it's showing now back up to 135THs

Thanks for the updates Kano.

The failover and failback was smooth with the S7 Dec FW for my S7 farm.
The FO/FB strategy of SG then USA, you advised yesterday was spot on.

[kano]

has this pool ever had back to back in its history  

That's the 4th time.

Code:

417	391920	25.22205742	2016-01-05 20:36:31+00	+36 Confirms	1,312,920,015	1.264%		0.013	1
416	391919	25.24137507	2016-01-05 20:26:11+00	+37 Confirms	46,387,923,153	44.655%		0.360	2

373	386503	25.06369915	2015-12-03 08:47:23+00	Matured		164,438,893	0.226%		0.002	45
372	386502	25.29834705	2015-12-03 08:45:32+00	Matured		55,359,736,580	76.124%		0.533	46

195	348800	25.06881192	2015-03-23 05:23:47+00	Matured		418,861,892	0.897%		0.009	223
194	348799	25.04422785	2015-03-23 05:11:45+00	Matured		102,227,698,277	218.821%	0.888	224

118	340929	25.22390379	2015-01-29 01:00:36+00	Matured		2,148,002,491	5.204%		0.051	300
117	340928	25.03951343	2015-01-29 00:24:46+00	Matured		97,668,003,042	236.640%	0.906	301

Still no '3' in a row

[bctmke]

has this pool ever had back to back in its history 

Yep most recently was

373   386503
372   386502

[bctmke]

Aww Kano beat me to it!!

[PPOC]

has this pool ever had back to back in its history  

That's the 4th time.

Code:

417	391920	25.22205742	2016-01-05 20:36:31+00	+36 Confirms	1,312,920,015	1.264%		0.013	1
416	391919	25.24137507	2016-01-05 20:26:11+00	+37 Confirms	46,387,923,153	44.655%		0.360	2

373	386503	25.06369915	2015-12-03 08:47:23+00	Matured		164,438,893	0.226%		0.002	45
372	386502	25.29834705	2015-12-03 08:45:32+00	Matured		55,359,736,580	76.124%		0.533	46

195	348800	25.06881192	2015-03-23 05:23:47+00	Matured		418,861,892	0.897%		0.009	223
194	348799	25.04422785	2015-03-23 05:11:45+00	Matured		102,227,698,277	218.821%	0.888	224

118	340929	25.22390379	2015-01-29 01:00:36+00	Matured		2,148,002,491	5.204%		0.051	300
117	340928	25.03951343	2015-01-29 00:24:46+00	Matured		97,668,003,042	236.640%	0.906	301

Still no '3' in a row

I'm predicting that when we get to 15-20 TH, we will hit 3 in a row within 30 days.

[Mikestang]

You have to also remember your hash rate is cyclic and is never a fixed rate.  It's pretty difficult to take a snapshot set of numbers and say it should be a certain way.  That's why the hash rate chart is always something like this...

Excepting that the line shown as "average" is not the average of that cyclic rate, the average should be about through the middle of the cycles.  Or is that median value?  Mode, mean, median, average... statistics are not my strong suit.

[kano]

Having instability on the SG node at the moment.
Hopefully everyone using it has their failover set to the main node.
-ck is looking into a fix for the problems.

We'll have the Tube proxies up and running on the DE and SG nodes once this is sorted out, also.

[kano]

You have to also remember your hash rate is cyclic and is never a fixed rate.  It's pretty difficult to take a snapshot set of numbers and say it should be a certain way.  That's why the hash rate chart is always something like this...

https://i.imgur.com/UqluWlO.jpg

Excepting that the line shown as "average" is not the average of that cyclic rate, the average should be about through the middle of the cycles.  Or is that median value?  Mode, mean, median, average... statistics are not my strong suit.

Coz he didn't show the left of the graph that is below the line.

Here's the code
https://bitbucket.org/ckolivas/ckpool/src/1c2376ce40661950b125dc031795b760945dfe16/pool/inc.php?at=master&fileviewer=file-view-default#inc.php-32
(you'll find that in the web page when you view the graph)

[yslyung]

SG had a dip, now seem to be up again.

have not set to main as failover, will do later, tied up atm. thx for looking into it. FIX FIX FIX.

btw where the block ? me hungry

[kano]

SG had a dip, now seem to be up again.

have not set to main as failover, will do later, tied up atm. thx for looking into it. FIX FIX FIX.

btw where the block ? me hungry

Yeah any outage will be very short - less than a minute.

I just managed to have it happen on the DE node also, that one was 32 seconds.
It's memory related so takes quite a while before the problem can cause a failure so don't expect it happening often (or again even) until it's fixed.

--

Payout 391877 sent
58068c471f825ed7edfa03ecaa6e4f1eab8abb7b8728b5692b035630f9e4e2a0
and confirmed

--

Edit: SG and DE fix in place and all swapped over smoothly.
You should rarely see a failover on the SG or DE nodes when ckpool restarts cleanly.

[ryen123]

Getting lots of such frequent messages from cgminer while connected to SG node.

"Accepted untracked stratum share from pool 0"

"Lost x shares due to no stratum share response from pool 0"

[kano]

Getting lots of such frequent messages from cgminer while connected to SG node.

"Accepted untracked stratum share from pool 0"

"Lost x shares due to no stratum share response from pool 0"

Before the problems I mentioned or after?

https://bitcointalk.org/index.php?topic=789369.msg13462455#msg13462455

[ryen123]

Getting lots of such frequent messages from cgminer while connected to SG node.

"Accepted untracked stratum share from pool 0"

"Lost x shares due to no stratum share response from pool 0"

Before the problems I mentioned or after?

https://bitcointalk.org/index.php?topic=789369.msg13462455#msg13462455

I'm seeing these messages now (ongoing). Full of such messages.

Edit: Restarted my miner. Seeing SG node dead. Mining on main node.

[kano]

Getting lots of such frequent messages from cgminer while connected to SG node.

"Accepted untracked stratum share from pool 0"

"Lost x shares due to no stratum share response from pool 0"

Before the problems I mentioned or after?

https://bitcointalk.org/index.php?topic=789369.msg13462455#msg13462455

I'm seeing these messages now (ongoing). Full of such messages.

Edit: Restarted my miner. Seeing SG node dead. Mining on main node.

What actually are you mining with and what's your username - (PM me if you want)
There's only a few users on the SG server that make up the ~135TH on there.

If you are running linux then do the following 2:

Code:

mtr --report sg.kano.is
mtr --report stratum.kano.is

Also if you swap to the main pool stratum.kano.is does that make any difference?