[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
difference.
>
> 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
possible.
>
> 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