Just had a question I was just poking around looking at my graphs for shift work checking on my miners, and I notice today at 00:47:54 I lost about 1 ths figured I lost connections for a second but then I notice on the pool hash rate the same dip at the same time were the pool lost like 2 PHS. Is that something with the connection to the pool or maybe reboot? Just wondering if my drop in hash rate and the pools was due to the same issue.
Sometimes its a connection or reboot issue. Sometimes the graph can look skewed if more than one block is found by the network seconds apart. Those kinds of dips show what it can really take to get everyone here mining on the same page after getting shot with a blank
Short network blocks do affect the shift graphs, but usually only by a sizeable amount around the time we also find blocks.
The nodes do drop off and back on again straight away sometimes, so in those cases there'll be a 5 minute failover and fail back for miners connected to the node.
These show pretty clearly on the Pool Graph - but the graph itself is a little misleading - the width of the gaps doesn't correctly represent the amount it has gone down (or up) since the points are the average middle point of each shift.
If you have your second pool set to a different kano.is node, then you should see little if no effect on your hash rate unless both nodes do it at the same time - which is of course pretty rare.
The failover of 5 minutes (which is what cgminer is hard coded to do - yeah it's too long for ckpool ... ... ...) means about a 10% drop for that shift for any miners that
don't have another kano.is node as backup, so that explains the drop level also.
In the long run it's not really a lot, and it's just caused by design flaws in ckpool.
That's something that I've already done changes that make it resolvable, that I'll finish off after I've done the accounting code.
... and on the subject of the accounting code
Soon after I get back I'll update KanoDB to add all the new account types and settings that I completed before I left, but hadn't done enough testing on it before I left, so I wasn't wanting to push a bunch of change live as I got on a plane
This has to do with the cloud changes I've mentioned before that I'm working on.
The problem has come up with the cloud design that I need the accounting code in place anyway.
So since the accounting code was next on the todo list, and I need it to finish the current todo item, cloud mining, that means account is what I'll be working on as soon as I test the current changes and get them live, once I'm back.