| |||||||||||||
The leap second bugThe leap second bugPosted Jul 4, 2012 6:27 UTC (Wed) by butlerm (subscriber, #13312)In reply to: The leap second bug by cmccabe Parent article: The leap second bug
CLOCK_MONOTONIC is of little use in clustered systems, unfortunately.
(Log in to post comments)
The leap second bug Posted Jul 4, 2012 10:03 UTC (Wed) by cmccabe (guest, #60281) [Link]
Well, CLOCK_MONOTONIC is useful for timeouts. And timeouts are often quite useful in a distributed system.
Having your 1 second mutex timedwait last for an hour because someone set the wall clock time back an hour, on the other hand, is not useful. Having your 1 second wait take 2 seconds because of a leap second is not useful.
Assuming that wall-clock time is properly synchronized across all nodes in a distributed system is usually not a good idea. It introduces operational complexity and more things to go wrong. And even the best maintained, properly synchronized clocks aren't usually really all that synchronized.
What we have here is a bad default, unfortunately. Most timeouts should not be in terms of wall-clock time-- ideally, none, except for calendar programs and similar.
The leap second bug Posted Jul 5, 2012 3:03 UTC (Thu) by dirtyepic (subscriber, #30178) [Link]
GPS sats are generally synchronized to somewhere ~10ns, but the receivers have to operate in UTC time and use a delta that's broadcast with the nav message which cycles every 12.5min. This is where I thought a leap second could have the chance to mess with phase tracking. It turns out that I was wrong though and there are failsafes built in to specifically prevent that from happening. Yay learning.
|
|||||||||||||