[LEAPSECS] internet drafts about zoneinfo (POSIX Time)

[Warner Losh]

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