3 ms·
Distributed systems design aside, the core of the problem is that they relied on ntp (as they probably should), and in their case ntp was not working properly.
by flavien_bessede 13y ago
Distributed systems design aside, the core of the problem is that they relied on ntp (as they probably should), and in their case ntp was not working properly.
- devicenull 13y agoAnd this is precisely why a thing that is not monitored is not actually a thing.
- olefoo 13y ago> "A thing that is not monitored is not actually a thing." That should be on a cross-stitch sampler on the wall of every NOC.
- specialist 13y agoNice. Much stronger than the "you can only manage what you measure" adage I learned from accounting.
- globalpanic 13y agoEven if NTP had been working properly, you would not have clocks synchronised at the level of individual ticks - only to the level of time intervals. If two updates happened at roughly the same time, and fell into the same time interval, there would be no way to tell which one happened before the other. A paper by Cilia et al on timing of composite events in distributed event-based systems using NTP deals with this issue.
- Dylan16807 13y agoBut this is not a problem in many situations. Whereas successor writes failing within an entire 30 second span is a pretty big problem.
- scottdw2 13y agoThe key take away from the article SHOULD be: don't rely on ntp if you don't have to. There are people who have to. They run their own atomic clocks, and worry about things such as precision delivery of nuclear ordanance. Then there's you. You should use vector clocks, with a builtin conflict resolution mechanism based on domain knowledge. That's the point of the article.
- donavanm 13y agoNtp is good. Assuming that time is coordinated, much less monotonically increasing, is a bad plan. Just the other week i got paged in the middle of the night because a clock moved backwards.