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
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs

Reply via email to