11 ms·
Handling Leap Seconds the OpenBSD Way
- takeda 11y agoSo basically... not handling it :)
- akerl_ 11y agoSometimes the only winning move is not to play
- deleted 11y ago[deleted]
- Buge 11y agoI'm not very familiar with ntpd, but this article doesn't cover what would happen if the half hour polling just happens to poll right during the leap second. If the code receives "59 minutes and 60 seconds" but doesn't expect that to be possible, I could imagine that being a problem.
- ams6110 11y agoI don't think it would see this. It would see "59 minutes and 59 seconds" and either see a one-second discrepancy with the local system clock on that poll, or on the next one.
- jjoonathan 11y agoUTC inserts the leap second by extending the last minute before midnight by one second and does indeed specify that this ought to be shown as, for example, "59 minutes, 60 seconds, 123 milliseconds." NTP doesn't seem to use the human-readable format for its timestamps though. My 30 second skim says it uses a variation on epoch time that extends from Jan 1 1900 rather than Jan 1 1970. UNIX epoch time inserts the leap second by waiting until 1 second after midnight and then jumping the counter back 1 second (which corresponds to a long 0th second rather than a long 59th second, but whatever, in spirit you are right) [1]. I see two potential sources for error: a 1s correction/drift proving to be "too much" for synchronization in a system that typically sees corrections or drifts far smaller, or 2. a well-meaning fool writes assert(s<=59) in some code that touches a correctly-handled UTC stamp during the leap-second :-) [1] https://en.wikipedia.org/wiki/Unix_time https://en.wikipedia.org/wiki/Unix_time
- ams6110 11y agoI read yesterday that the leap second was handled by repeating the last second of the day. So you would see 59 seconds for two seconds but never 60 seconds. I guess different systems and time standards may handle it differently.
- jjoonathan 11y agoI'm sure that's how some systems implement it and it's close enough to the truth that I'm sure it will frequently be reported that way in the news. But I'm also quite sure that the actual standards are as I said they were. See the wiki link for a detailed timeline.
- ised 11y agohttp://cr.yp.to/proto/utctai.html http://cr.yp.to/proto/utctai.html http://cr.yp.to/proto/taiclock.txt http://cr.yp.to/proto/taiclock.txt I am just a dumb user. I use clockspeed (sntpclock, clockadd and clockview) with a short list of compatible servers I consider "reliable". As far as I can tell, it works. http://cr.yp.to/time.html http://cr.yp.to/time.html
- jerf 11y agoTime needs vary widely for people. Some people need nanosecond precision. Probably most end-users wouldn't notice for quite a while if their system clock is off by literally years... I know I've done it before without noticing. However, the existence of the latter doesn't somehow invalidate the former... some people really do care quite deeply. If you are in the latter, it hardly much matters what you do. "Manually setting it off of my cell phone" or "ignoring it entirely" are mostly valid options.
- sshb 11y agoDont they have software with time deltas? Are all time deltas signed? Are negative deltas handled?
- thesnider 11y agoYes, if they're running NTP anyway. Normal clock drift/skew correction would already cause this sort of thing.
- jjoonathan 11y agoSure, but I bet you could find a good number of production systems that have never before had to handle a delta as large as 1s.
- rakoo 11y agoI'm pretty sure OpenBSD core doesn't have any of those, and that's really what the project is caring about. Problems may happen in ports, but there's a reason why they're ports. Also, as stated in the article: > Finally, if you are one of the exceedingly few people for whom the clock being off by a second actually matters, then I'm pretty sure you also know how to deal with it.
- cpach 11y ago”if you are one of the exceedingly few people for whom the clock being off by a second actually matters” I would be interested to hear if anyone has examples to share about those systems :)
- tfigment 11y agoI would think that waveform capture on the electric grid would be impacted when doing timeseries data logging and use in subsequent analysis. Frequently these will be relative time snapshots or using a different time basis so not sure if they are actually impacted. The only time people would care that I'm aware of would be if the grid drooped at that exact time and one was trying to do analysis around that. Otherwise they are just doing things real time as they happen and time tracking is not necessarily involved except for logging. Anyway I frequently run into timeseries trending clients that cannot handle displaying daylight saving time transitions correctly let alone hope that they handle leap seconds correctly.
- ams6110 11y agoIt's not always the right approach, but it's a good reminder to consider "do nothing" as the proper response to a weird edge case that is presented as a [potential] problem.
- xiaq 11y agoAh, the arrogant and absolutely amazing way OpenBSD people write :)
- angersock 11y agoWaaay more fun to read than the with-baited-breath-and-optimism we usually get from the web-dev/devops world.
- stephen_g 11y agoApologies for the off-topic pedantry, but bated breath is probably the idiom you are looking for!
- angersock 11y agoOh, thank you! I've apparently been doing that wrong for years. Thanks!
- bechampion 11y agooh yea ... I'm having so much fun reading yet again another openbsd moody/pedantic journal entry.
- josinalvo 11y agoOut of curiosity... What it the NTP server is running openBSD? =P (not sure if this question makes sense... Anyway, it seems some OS has to worry about leap seconds...)
- mrweasel 11y agoNormally you would run OpenNTPd on an OpenBSD system. It's developer and maintained by OpenBSD developers. It's not as precise the ISC ntpd, but normally "good enough".
- openbsdway 11y agoAvoiding fsck(1) the OpenBSD way.
- openbsdway 11y agoHandling filesystem checks the OpenBSD Way. fsck(1)
- openbsdway 11y agoHandling Unified Buffer Cache the OpenBSD Way. They don't.
- openbsdway 11y agoHandling nfs the OpenBSD way. They don't.
- openbsdway 11y agoLoading Kernel modules the OpenBSD way. They don't.
- PhantomGremlin 11y agoFor anyone curious about this: Finally, if you are one of the exceedingly few people for whom the clock being off by a second actually matters, then I'm pretty sure you also know how to deal with it. One alternative to NTP is PTP.[1] Quoting: IEEE 1588 is designed to fill a niche not well served by either of the two dominant protocols, NTP and GPS. IEEE 1588 is designed for local systems requiring accuracies beyond those attainable using NTP. [1] https://en.wikipedia.org/wiki/Precision_Time_Protocol https://en.wikipedia.org/wiki/Precision_Time_Protocol
- peterwwillis 11y agoIt's not a bug, it's a feature we chose not to implement. Weird that a security-centric OS would be cavalier with time when some cryptosystems are time-sensitive.
- mrweasel 11y agoThere is a point to be made that implementing it correctly, would involve extra code, for what is essentially an edge case. That extra code could prove to be a larger security concern that being 1 second of once in a while. Your clock is almost certain to be a little of every now and again anyway. If it wasn't there would be no point in running ntp.