-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clock sync detector should kill nodes #13
Comments
Do we need to reach a consensus between nodes of where the time is?
This would mean that one node with a lagging clock could kill all the others |
Probably want to check this on startup too. |
I would definitely be interested in any papers on loosely coordinating clocks. I'm sure there are some smart people who have already solved this better than I can think of. |
NTP is the prior art that comes to mind first, I want to think about whether it's appropriate for our use case though. |
The clock skew detector is also about message latency, not just clock sync. NTP is solving a subtly different problem. |
I'm reasonably confident that lagging clocks should result in unavailability; if we bias towards the future, you can wind up invalidating some of the weak-time-ordered claim semantics. |
When the clock-sync detector sees that the time delta has exceeded the buffer in skuld.task, it should nuke the node and log an informative message. Probably the safest thing for now.
The text was updated successfully, but these errors were encountered: