[LEAPSECS] internet drafts about zoneinfo (POSIX Time)

Warner Losh imp at bsdimp.com
Wed Mar 9 15:18:56 EST 2011


On 03/09/2011 12:33, Ask Bjørn Hansen wrote:

> On Mar 9, 2011, at 9:00, Warner Losh wrote:

>

>> If you are stratum 1, or slaved to a chain of NTP servers that is

>> properly slaved to a stratum 1 that gets leap seconds right, this is

>> what will happen if your kernel is based on the kernel ntp code from

>> dave mills.

> ... or if it's a stratum 1 server that's not getting the leap second right, it could be a second off until someone intervenes.


Yes. If it is stratum 1, and there's either a problem in its source of
leap information, or there's a bug in its use of leap data.


>> If you are slaved to an NTP server that doesn't get time right, ntpd

>> will steer out the error in phase by introducing a small error in

>> frequency until the phases are aligned.

> ... which can take many hours. It's worth clarifying too that during this time both a second isn't a second long *and* the clock is wrong. It's like you don't have a cake and you can't eat it.


Correct, but a second is never a second long. There's always variation
in the length of the second, as realized by computers. Their internal
oscillators just aren't that good, so you routinely see seconds varying
by up to 50ppm over the course of a day as the heating/cooling cycles
kick in. Decently controlled systems might be an order of magnitude
better than this. In measuring PPS against system time on systems in
open loop can be quite revealing.

The steer that's put into remove the second is, however, much larger
than that (if steering out), or you have a time jump (if slewing out).
Errors on the order of 100ms are steered out over 3k or so seconds,
which is on the order of a 30ppm steer. Errors of 1s would take more
like 10k seconds to steer out, as the error introduced is clamped to
about 100ppm. These errors are relatively large, but are in the same
ball park as normal operational variances.


>> If ntp isn't running, then all bets are off.

> I'd clarify that as even on systems that are taking care of time much better than average, "all bets are off when a leap second happens".


That's one reason many users of precision time suspend or scale back
operations around leap seconds. Your tracking of leap seconds are only
as good as your worst supplier.


> As you explained, even the optimal best case scenarios are not really good - and in many cases it doesn't work out optimally.


Using POSIX interfaces, sure. Using the NTP interfaces, you can do
significantly better. The former is used 1000x as often as the latter,
give or take...


> In the field of "making stuff work" it's important that the protocol for any exception or failure scenario is as simple as possible. Leap seconds sound simple; but they aren't.


Totally agreed.

Warner


More information about the LEAPSECS mailing list