With the recent medalla clock chaos, it became apparent how important the time of the node is. And since this is no secret to the outside world, why not share it on eth2stats to raise awareness, and alert users?
Possible design:
- Client sends current timestamp (timestamp is put in the message after calling api methods etc.)
- Include system slot in the
/clients response data. 0 = not available
- Server substracts genesis time, then divides by slot time, to calculate the "system slot" (float64)
- Dashboard adds some visual marker on an entry if the system time is different than the eth2stats server time (do not compare to browser time, that adds even more latency). Alert users when nodes are having a bad time (no pun intended)!
- Show the color based on difference with expected time.
d = abs(server_time - client_time), d < 0.4: green, 0.4<=d<1.0: yellow, 1.0<=d<3.0: orange, d>=3.0: red.
- Dashboard shows a warning at the top if the median (bucket by second) time of all clients is too different from the server, as sanity check. The server itself may have an inaccurate time.
- Dashboard shows a warning at the top if the server time itself is inaccurate compared to browser (user) time.
Questions:
- Account for client-server latency: (maybe track server-client latency somehow, and adjust times with it). It's nice when all times can be compared better.
- How to deploy the feature on eth2stats.io main site, and which dashboard changes to make, to keep it compatible and not shake the current setup too much.
Related cleanup:
- clients are all sending genesis time over and over again (???)
- server needs to be configured with genesis time, timestamp option would be nice (more common in client api formats)
- no need to track genesis time per client (head root already signifies the difference in beacon state, genesis time is included in it)
I'm happy to implement all this if others like the idea, and agree on above design. Feedback welcome.
With the recent medalla clock chaos, it became apparent how important the time of the node is. And since this is no secret to the outside world, why not share it on eth2stats to raise awareness, and alert users?
Possible design:
/clientsresponse data. 0 = not availabled = abs(server_time - client_time),d < 0.4: green,0.4<=d<1.0: yellow,1.0<=d<3.0: orange,d>=3.0: red.Questions:
Related cleanup:
I'm happy to implement all this if others like the idea, and agree on above design. Feedback welcome.