[ntp:questions] Google and leap seconds

Harlan Stenn stenn at ntp.org
Wed Sep 21 23:01:44 UTC 2011

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.

What are the effects of a different (presumably larger) value going to
have on the behavior of the loop?

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.

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.

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."


More information about the questions mailing list