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

The Party goes on 

Just finished bottling my beer and - BLOCK!

Good to see this pool is growing Ready for another block party.

noticed that ck has done it & that's why i suggested it. thx for the hardwork. keep it up !

K pool will defo have my support, i brought 2 friends in already & will bring more + some added hashpower soon.

... and another post

Anyone using the API, I've added a new data item "STAMP"
This is the pool epoch 'now' timestamp when the data was generated.

If, in your app/web/whatever, you do comparisons like "How long ago was the last block" or "How long ago was my last share" then you should use "STAMP" for now, not the device/web site time.

The main reason being that devices are far from accurate and "STAMP" will always be accurate.
Also, of course, the data is accurate as at "STAMP", so assuming anything about the data after the "STAMP" point in time will not be correct.

The API has the information that zach uses (and apps can use) and that's how he gets it.
Notifications are done by apps and web sites, coz there are major issues using email if you depend only on it and email stops working ...

Not sure what you mean about the 'chart' bit, you'll need to explain that separately.

The 5Nd calculation is still not available since it would have to update that information in real time with every share that arrives.
It's not impossible, but not something I've wanted to change yet since it will have performance implications.

I'm not sure if you've noticed, but all the worker information in the API and web site is accurate to the second.
ckdb does shift processing and locks out everything for 4 seconds each time it does this (but that also includes DB IO), so I don't want it calculated regularly at intervals and thus being stale information. It would have to be tracked in real time with each share arriving.
It's on my todo list, but I've no idea when I'll do it.

-ck has already done the necessary work, I'm in the process of setting up servers ... but as usual other things happen, but it's getting there

Good point.  Any inclination here Kano to put a second (or third) server in a different country?

With the speed of ckpool having devices in other countries *shouldn't* be an issue so i could see it be something not very high on your priority list (or not on it at all).

Kano,

A few comments as a Newbie to CKPool.  Note: I am coming from Slush's.  I am learning the system daily and reading the forum as well to bring myself abreast of the more experienced users.  I do not know what I do not know.  Are the following suggestions possible / already suggested / or not in the scope of your vision?

* ACTION: Can this be added to CKPool?   http://ckpoolmonitor.zachmonroe.com/userhashrate_workers.php
   REASON:  I had a miner go down yesterday and because of zachmonroe, I was aware of the issue and could address the issue.  
   Here are the features great features:
  - Email notifications of low hashrate
  - Chart by miner and total.
  - Block Found email
  - Worker Offline email

* ACTION:  Measure by hashrate for the total and individual miner(s) in 5 min, last hour, last day to show efficiency of the miner?
   REASON:  This would easily give the user information as to how their total or individual miners are performing

* ACTION: Can a measurement device be added to measure where I am in total toward the 5Nd?  Recommendation:  Add a ____% right under the Hash Rate on the Header.
   REASON: I only know where my total "Your %" is, after a block is found.  I had seen another person taking 20TH/s to mine with solo.ckpool for a day or two.  I may want to do this as well and would then like to know where my total TH/s rate is in comparison to my other miners.

There are GREAT features to CKPool!  I am really liking it along with the Moderator here online with us users that is transparent with us.  Thanks Again.

just started (imho, it's still in it's infancy stage), hang on to it, keep the heads low, good support & teamwork is VERY important & enjoy the profits.

far way to go but it's always good to see a steady growth.

payouts received.

kano me want you to get bz alarm going off more frequent & sending more payouts. let's make it happen.

i am willing to put in some donation if you are willing to setup a asia server (sg or hk) as backup or secondary server. just saying & if you are keen & have the time to do it.

Ive got some more s7, s on the way. Hopfully we get lucky and hit a 20 block in a row wonder

Payout 391442 sent
7ccc651f79b018634b04831f9a0e46bf23ef67dc4634f080caa6f29e9f824cb0
and confirmed

--

tl;dr; follows

This is commented in various places in ckdb.c

The postgresql database is a permanent store of everything, however share information is only updated after the end of each shift.
ckdb doesn't read postgresql at any time except during a restart, since ckdb is "the database"
ckpool sends everything to ckdb (of course) but also logs everything it does to hourly log files

There's also a guaranteed unique set of 2 sequence numbers and 2 id numbers on every message, that are verified and checked for missing numbers ... which it reports 'very loudly' if that happens and there's a ckdb command to check the status of that at any time also.

When I stop ckdb, it simply closes down and exits (which actually takes a few seconds, 6s this last time)

ckpool then starts complaining about "Where's ckdb?!"

Restarting ckdb opens it's connection to ckpool and starts queueing all incoming messages, (ckpool is happy again) then reloads the whole contents of the database into ram (which took in this last case 6m 34.569s to load everything)

Next it then redoes what it did from that reloaded db point onwards by finding the appropriate ckpool log file and reading from that one forward to the end of the log files (that are of course also growing)
During this process it also truncates the queued data if it starts to overlap.
Once it's finished the log file reload (took 13m 19.957s to process almost 3hrs of log files), it then processes the queue.
This is one bit I need to look more into coz the first file took the expected 3.5min but the 2nd file blew out to 7.5min and the 3rd 33% full file took 2.5min (i.e. same ratio as the 2nd one)

The queue took 0m 32.041s to get back down to zero and then all the restart was complete.
This process simply puts ckdb into the state it should be 'now'

One point in this that I will need to be more diligent about when I do restarts - is to time them to just after the shift database update.
It looks like it was just before a shift end that I restarted this time so it had to reload a full extra file (the first 3.5min) and that seems to have caused the slower reload of the 2nd and 3rd files (it's usually only 2 files)
The shift end point is somewhat variable and it's also another 13-15min after that, that it updates the database.
So making sure it is just after a db update will of course mean the reload log file start point will be a full shift further forward.

No worries, current network hash rate is around 720PHs, so we're running close to 1% of total.  Plenty of room to grow within kano-san's parameters.
Now, let's crack a block already!

But possibly a short term rental to shake out a block?

https://bitcointalksearch.org/topic/m.13431812

Really?

Such is the nature of luck and statistics.  We'll get there.

Remember Kano will only let us grow so large before he stops allowing new miners (if I recall his goal is 10% of the network).

Yeah that's a failover from somewhere else that happens on and off

i see only: CKPool:     8,383.89THs

it's bad luck all around the blockchain, last block was 1h ago
and the last 6blocks were done in 3h!!!

Good news hashrate is increasing but with increasing hash rate we need to find many blocks too ..Hope we will get it