[ntp:questions] NTP offset doesn't change.

Harlan Stenn stenn at ntp.org
Fri Feb 13 02:38:10 UTC 2015


William Unruh writes:
> On 2015-02-12, Harlan Stenn <stenn at ntp.org> wrote:
> > Bill,
> >
> > So you believe:
> >
> > - the broken linux kernel behavior is an acceptable (or at least
> >   excusable) fact of life,
> 
> Of course not. However, it IS a fact of life, and I have to live in the
> real world. nptd spends many lines of code correcting for rare
> conditions in the real world. But not this one. 

Those coding problems with core linux timekeeping were outside our realm
of "we can reasonably deal with these problems."

It would have been far better for folks with those broken kernels to
have simply removed any drift file before starting ntpd.  The code to
remove the drift file could have been removed once the problem got
fixed.

Or folks could have proceeded with an idea I had years ago - write the
tick value (or the frequency) to the drift file, and when starting up
make sure those values were still appropriate.

But again, how far should we go to accomodate braindamage?

Ntimed is beautiful and small.  And every time somebody decides to
address some new issue, the code will get bigger.

> > - that should have been predicted and accommodated by stable-running
> >   software and algorithms that have been around for decades,
> 
> That the kernel people screwed up was perhaps unpredictable. That clocks
> could have drift rates substantiallydifferent from 1 sec/sec could have
> been predicted. 
> 
> >
> > - where no other kernel has ever misbehaved in this way,
> >
> > - and other projects should deal with that mess;
> >
> > - and chrony, a program with one design goal of closely tracking a
> >   master avoids this kernel brokenness.
> 
> All of the above are predicated on you wrong assumption that I thought
> that the kernel screwup could be predicted. 

I don't see it that way.

The linux folks went ahead and did something Unusual expecting other
folks to deal with their mess.

Kinda like when they took the PPASPI and decided that they were not
going to implement both MOD_ and STA_ bits because they were "similar"
and then got huffy because they changed something they were not using
and the folks who were using it didn't feel like cleaning up that
externally-created mess, either.

> > And the net effect of the above indicates a shortcoming in the way NTP
> > was designed, right?
> 
> The inability to deal with the real world, when that is one of its
> design goals IS a shortcoming in NTP, yes. 

Bullshit.

How about "the unwillingness to deal with excessive stupidity"?

> > That's OK, and it's why I don't take your messages very seriously.
> 
> Of course I cannot make you take anything seriously. I would have
> thought that designing ntpd to handle the real world would be something
> you take seriously. And that when you discover a feature of the real
> world that ntpd does not handle but could, that you would seriously
> consider changing ntpd so that it does. 

Some behaviors are so broken it doesn't make sense to try and accomodate
them.

H


More information about the questions mailing list