[ntp:questions] ntpdate.c unsafe buffer write

Harlan Stenn stenn at ntp.org
Tue Feb 12 04:36:51 UTC 2008


>>> In article <oRYrj.18916$w57.10093 at edtnps90>, Unruh <unruh-spam at physics.ubc.ca> writes:

Harlan> In terms of the behavior model of ntp, "state 4" is as good as it
Harlan> gets.  You are in the right ballpark.

Unruh> And as has been commented on numerous times, ntp is state 4 is very
Unruh> slow to converge to the best possible time control. This was a
Unruh> deliberate design decision, as I understand it, so that in steady
Unruh> state the time is averaged over a large number of samples ( not
Unruh> helped by the fact that 85% of samples are thrown away), to reduce
Unruh> the statistical error in the clock control.  Note that at poll 7 the
Unruh> number of actual samples averaged over in the time scale of the ntp
Unruh> feedback loop is only about 3, so the statistical averaging even with
Unruh> such a long time constant, is not very good.

OK, and please don't take this the wrong way, but So What?

For the general use case (LAN and/or WAN and/or jerky path) ntpd behaves
well.

As Dave recently replied, if you are only interested in LAN performance
there are tweaks that can be made that will improve the performance.

The current setup will Just Work regardless of the network environment.

This, to me, is the sign of a "good piece of software".

If somebody with extra knowledge can make a local optimization based on
tighter specs, great.

I suspect that if Dave can be shown that whatever chrony is doing will
behave in the wider space that NTP covers, he will be OK making changes to
use those algorithms.

There may even be a way to choose different algorithms based on the behavior
in evidence.

But you seem to be talking about how improvements can be made and I thought
this original thread was about how there was a *problem*.

>> If you want something else, something you consider "better" than state 4,
>> please make a case for this and lobby for it.

Unruh> I think many people have lobbied for faster response. In the
Unruh> discussion of the chrony/ntp comparison, chrony is much faster to
Unruh> correct errors, and at least on a local network, better at
Unruh> disciplining the clock as well ( in part I think because on such a
Unruh> minimal round trip network, the frequency fluctuations dominate over
Unruh> the offset measurement errors-- Ie, the Allen intercept is much lower
Unruh> than the assumed 1500 sec. in that kind of situation-- also the drift
Unruh> model on real systems is not well modeled by 1/f noise.) So, what I
Unruh> think the point is that using ntpdate, one can rapidly bring the
Unruh> clock into a few msec of the correct time, rather than waiting for
Unruh> the feedback loop to finally eliminate that last 128msec of offset.

OK, and again, I'm seeing you lobby for an enhancement/improvement here (and
I'm all for that).

David (I think) was talking about a *problem*.

I agree with you that we can do better.

I am trying to see if there is also a problem.

Harlan> If folks have suggestions for improvements I welcome them.

Harlan> If folks want something different I invite them to make a case for
Harlan> it.  Please remember the scope and complexity of the problem case.
Harlan> It's much easier to have a simpler solution if one is prepared to
Harlan> ignore certain problems.  Another case in this point is Maildir.

Harlan> If somebody is in the situation where they know they have specific
Harlan> requirements for time, they are in the situation where they have
Harlan> enough altitude on their requirements to know the costs/benefits of
Harlan> what is involved in getting there.

Unruh> Well, I disagree. The sign of a good piece of software is that it
Unruh> does what it needs to do despite the user having a bad idea of how to
Unruh> accomplish the task.

Sounds like NTP.  Folks often have pretty bad ideas about what they "need"
to do or what problems they think they are solving by doing strange things
and the code works anyway.

But more to the point, what is the *problem* you are trying to solve?  You
are still communicating to me that we can do *better* and I agree with you.
You have not yet communicated to me that there is a *problem*.

Unruh> The use of software should not be an esoteric
Unruh> exercise.

While this may be a surprise to some (or painfully obvious to others), I am
not a chime-head.

I have had no trouble bringing up ntpd on *lots* of systems in *lots* of
places using some real simple ntp.conf files for the client boxes and only
slightly more complicated config files for the internal servers.

I'm not a fan of esoterica.  I like things clean and simple.

Unruh> Let me again bring up chrony. It manages to get the system
Unruh> into msec of the right time on a timescale of minutes, not hours. It
Unruh> had a very different model for the clock control mechanism from
Unruh> ntp. From what I have seen now, both in a local net system ( with
Unruh> .2ms roundtrip times) and an adsl connection (20ms round trip times)
Unruh> chrony also does as good a job or better than ntp at disciplining the
Unruh> clock. I have just ordered another Garmin 18LVC so I can make
Unruh> measurments as to how well chrony and ntp actually discipline the
Unruh> adsl system's time to true time despite all of the noise that adsl
Unruh> adds to the measurement process. (both ntp and chrony seem to have
Unruh> about the same standard deviation in the measured offset, so that
Unruh> gives no information as to how well the clock is actually
Unruh> disciplined-- one could discipline it to 5usec and the other to
Unruh> 100usec and you could not tell the difference from the measured times
Unruh> which have a variance of 500usec due to round trip problems).

OK, and since you brought it up again I'll respond again: So What?

Again, are you saying "Hey, I see that chrony seems to do much better than
ntpd in these areas - can we make ntpd do that well too in those same areas
without making things worse in areas that chrony does not address?" or are
you saying "ntpd is broken in the situation of X and here is why"?  Or is it
something else?
-- 
Harlan Stenn <stenn at ntp.org>
http://ntpforum.isc.org  - be a member!




More information about the questions mailing list