A lot of interesting geophysics in the unpredictable need for leap seconds. I mention Google's "smearing" approach here: http://arstechnica.com/science/2016/04/the-leap-second-becau...
[deleted]
Making every (leap) second count with our new public NTP servers
21–30 of 73 posts
Re: Making every (leap) second count with our new public NTP servers
#22Earlier quoted context omitted.
That doesn't make it any less unilateral. IMO, it makes it rather worse to have been doing this for five years. The situation would be much better if they had been working to build a broader consensus over all that time. As near as I can tell, they don't even have consensus within Linux, let alone POSIX or the ITU.
Honest question: what's so bad about others' systems running on slightly off time? I get why people care about internal consistency, and why deviations should be quite small, but this?
During the last leap second, I had servers configured against google's semi-public servers and some other good sources of time. ntpd marked the google servers as a false ticker sometime during the distortion, and when it was done, was happy with it again. However, I have more non-google servers than google servers, and high minpoll times which tends to result in time checks between servers happening far apart in time, so even if I had multiple google servers, they wouldn't look very close together.
Re: Making every (leap) second count with our new public NTP servers
#23Why the hell aren't time servers and clients sync to TAI instead? Dealing with leap seconds should be a client side problem.
Re: Making every (leap) second count with our new public NTP servers
#24Earlier quoted context omitted.
Smearing leap seconds does make sense, but it's an odd step to take unilaterally, rather than coordinating with other NTP servers and with Linux timekeeping (which currently handles leap seconds via a 61-second minute instead).
I think taking this step unilaterally is the only way it's going to be taken. Given that Google doesn't want to deal with leap seconds [1], and that the standards organizations have been debating removing leap seconds for years, at least they're publicizing what they're doing. [1] for good reasons
It isn't even so simple as "work with others" - the other people involved here aren't even thinking at this level. Leap seconds are an ugly hack that were inserted without any thought as to the impact on computer systems. We should not use them, they exist as a vanity project imo.
Remember when leap seconds caused ALL JVMs to lock up until restarted? Or kernel bugs? ick!
Re: Making every (leap) second count with our new public NTP servers
#25Why the hell aren't time servers and clients sync to TAI instead? Dealing with leap seconds should be a client side problem.
Yup, it seems awesome, but software needs to be written to handle it properly. I think it'd work no problem with software already written against monotonic clocks, but everything else would probably need some fixing.
Re: Making every (leap) second count with our new public NTP servers
#26Does anyone know if Google has open sourced the time smearing algorithm?
Re: Making every (leap) second count with our new public NTP servers
#27Why the hell aren't time servers and clients sync to TAI instead? Dealing with leap seconds should be a client side problem.
Google introduced this exactly to not have to deal with it client-side, while still having UTC timestamps that match the rest of the world most of the time.
Re: Making every (leap) second count with our new public NTP servers
#28Earlier quoted context omitted.
They've been doing this since at least 2011.
That doesn't make it any less unilateral. IMO, it makes it rather worse to have been doing this for five years. The situation would be much better if they had been working to build a broader consensus over all that time. As near as I can tell, they don't even have consensus within Linux, let alone POSIX or the ITU.
In the absense of a published and agreed standard, every approach is unilateral. My company is taking a similar approach - disconnecting from external NTP servers on 31st December, stepping the change in gradually, and reconnecting when we're "right" again.
Google have never been in the NTP business - there's no reason for them to have worked towards a concensus on this. But when a company their size makes their approach publicly available to all, it starts to pave the way for a consistent standard for everyone.
Re: Making every (leap) second count with our new public NTP servers
#29“Leap Smearing must not be used for public-facing NTP servers” - https://tools.ietf.org/html/draft-ietf-ntp-bcp-02
Re: Making every (leap) second count with our new public NTP servers
#30Earlier quoted context omitted.
Smearing leap seconds does make sense, but it's an odd step to take unilaterally, rather than coordinating with other NTP servers and with Linux timekeeping (which currently handles leap seconds via a 61-second minute instead).
>Linux timekeeping (which currently handles leap seconds via a 61-second minute instead) Google doesn't think so: "No commonly used operating system is able to handle a minute with 61 seconds"
One of the big problems is application support. How many will break by seeing 60 as current second as opposed to 59 twice?