just a ? and maybe a sort of a heads up to kano in case it is an issue that you are not aware of..
for the last 2 weeks I happened to notice that any time a block is found on the network and then the pool starts working on a new block. I have noticed the time it takes for the pool to start on the new work is some times as much as 5 mins behind.
for instance block number 499476 found by slushpool at 2017-12-15 13:31 and then they instantly started working on block 499477 and working on it for almost 5 mins before the time kano pool switched and started the new work on trying to work on block 499477
sometimes its only about 15-20 seconds difference that the pool takes to switch on to a new block and get to work and figured that was just normal time its taking for other pools to switch work after another pool finds a block.. But over 4 mins seems like a real long relay time.
so incase that is longer then it should take I figured I would say something to let you know so if it is a problem you could see what the cause might be. Tho if not then I guess its no biggie and you would know its not any thing that could cause any issue with the pool missing out on the big race to find a block before any other pool ever did.
I had noticed the same thing. Kano assured me that the Pool immediately goes to work on the new work for the new block. No delays. He would know since he has the tools to monitor the hash on each block. He explained to me that many Internet providers use proxies for websites and they are not always updated properly. I pushed the I believe button because he would know since he is monitoring the back end. Now with that said... timing in this game is everything. Ensure that you mine to the fastest ping Pool node for your location. In my case, it is the NYA with a 14ms ping.
MINE ON!!! KANO-SAN has got our back!!
True I know if there is anyone thats can be trusted to even know what he's talking about as far as how things work its Kano. and if something was anything that could cause problems with the pool or cause it to have worse luck hitting blocks it would be in his interest and every one mining to find and fix and bugs or issues that were found if there was a problem with anything.
and glad to know that delay in the time shown from the time new work started on block and new work is not a real problem. Tho now that I thing about it some more and knowing how the info pages are also on a different server than the actual pool its self I can see how it would have to lag behind a bit on what ever data that needs to go from one place to another to be displayed.
So going through the logs for that specific block:
499476
000000000000000000a90fdd34d539c9a25a56355a245708ff855f9e3245e98b
Pool log:
[2017-12-15 18:31:22.912+00] Block hash changed to 000000000000000000a90fdd34d539c9a25a56355a245708ff855f9e3245e98b
Mining monitor - when it saw the block change.
It's in the USA and connects to every mining node (not in china) no some may take a fraction of a second longer,
The last one (pool 1) is in singapore and I guess the connection from the USA to there and back to the USA was a little slow for that one
But the times there show when the work change, sent from the main server, arrived at the monitor, after going via the node.
[2017-12-15 18:31:22.953] Stratum from pool 10 detected new block at height 499476
[2017-12-15 18:31:22.956] Stratum from pool 0 requested work restart
[2017-12-15 18:31:22.960] Stratum from pool 11 requested work restart
[2017-12-15 18:31:22.963] Stratum from pool 7 requested work restart
[2017-12-15 18:31:23.004] Stratum from pool 4 requested work restart
[2017-12-15 18:31:23.012] Stratum from pool 8 requested work restart
[2017-12-15 18:31:23.012] Stratum from pool 6 requested work restart
[2017-12-15 18:31:23.045] Stratum from pool 9 requested work restart
[2017-12-15 18:31:23.220] Stratum from pool 2 requested work restart
[2017-12-15 18:31:23.238] Stratum from pool 5 requested work restart
[2017-12-15 18:31:23.376] Stratum from pool 3 requested work restart
[2017-12-15 18:31:25.727] Stratum from pool 1 requested work restart
So basically it's all OK for that block, so I'm not sure what the cause was for you seeing it minutes later.
Also note that the web site shows the time in the bottom left and right in tiny letters - check what it says there also next time you see this.
The left is the web server UTC and the right is what your browser thinks the current time is.
i.e. you may be seeing a cached copy of the web site and it would show the server time in the past.
The web server itself doesn't use any caching or cloudflare or anything like that since firstly, cloudflare is a security risk (you have to give them your SSL certificate and thus trust every employee of every company that has access to their servers) and secondly, the code/server is configured to handle the load pretty well without the need for that.
i.e. the web server doesn't take minutes to send you the data, it's immediate, and the data it uses is immediate.
The timeouts that sometimes occur, might cause a delay since the web page is made up of 2 requests, the header and the content.
That would be extremely rare, since the timeout would have to occur right between the 2 requests.
But the web page content would be all wrong, so you'd know about that happening.
The timeout itself can mean everyone for up to about 30 seconds or so after it may show timeout messages with nothing else, but not pages with out of date information.
