[ntp:questions] Google and leap seconds

unruh unruh at wormhole.physics.ubc.ca
Thu Sep 22 00:26:19 UTC 2011

On 2011-09-21, Harlan Stenn <stenn at ntp.org> wrote:
> Bill wrote:
>> On 2011-09-21, Harlan Stenn <stenn at ntp.org> wrote:
>> > Bill wrote:
>> >> Some operating systems (eg Linux) have the ability to do a much faster
>> >> than 500PPM rate change (100000PPM in the case of Linux) but ntp does
>> >> not make use of that. 
>> >
>> > ... because it would violate the assumptions and rules about the loop
>> > behavior (I'm painting with a wide brush here).  If you want a system
>> ? But that 500PPM was an arbitrary and random value chosed X years ago. 
> "Arbitrary and random" sounds like Spin to me.
> It was several sigmas bigger than the expected worst-case "acceptable"
> clock drift.

And it could have been 1000 PPM  or 2000 AFAIK, and it would not have made any
> What are the effects of a different (presumably larger) value going to
> have on the behavior of the loop?

Why should it have any effect? steps do not appear to have any effect. 

> What will the effect be on other systems that "associate" with these
> boxes that have the faster rate?
>> > that is designed to work with a faster slew rate that's fine, but then
>> > you also have to consider legacy and interoperability issues.
>> sure. But what legacy issues do you have in mind? 
> machines that operate at the 500ppm limit that are now talking to
> machines that operate at this new higher rate.

Clearly if the machine is at the end of the chain, it should not matter. 
If it operates as a server, the 500PPM system will fall behind until the
rate drops and then will catch up. Or it will have an offset greater
than .128ms and step. 

> Applications that "knew" that if a time correction was going to happen,
> it would be at the 500ppm rate - this goes to data correlation and
> timestamp sequencing.

But ntpd is allowed to step, so it has to assume that an infinte rate is

> That's just 2 legacy issues off the top of my head.
>> > It also goes to timestamp correlation issues.
>> It would seem to me that a step (infinite PPM) would be far far worse.
>> ntpd does NOT limit the slew rate to 500PPM. It limits it to infinite
>> PPM. 
> And when it does it logs the event, so it is still traceable and
> auditable.  It's also an indication of "something is wrong, as this
> should not have happened."

But your questions where what happens to other systems. a drift of
500PPM for an hour is surely just as bad. 

> H

More information about the questions mailing list