[ntp:questions] ntpdate.c unsafe buffer write

Unruh unruh-spam at physics.ubc.ca
Tue Feb 12 07:04:28 UTC 2008


Harlan Stenn <stenn at ntp.org> writes:

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

The question is not does it work well, but does it work the best it can.


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

No, I am interested in the behaviour in general. That is why I am trying to
test it on an ADSL link as well.


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

The question is whether or not it can be made better in general.



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

This original thread was  about how ntpdate had an too small a buffer for a
given use-- a very easily fixable problem. It then wandered to whether or
not ntpdate should be axed or not. And then as an aside I mentioned further
experiments I was doing on the comparison of chrony and ntp-- mentioned
because one of the reasons ntpdate is used is the slow convergence of ntp
to the true time. I mentioned that chrony has much faster convergence. 
So as sometimes happens in threads, they wander, and in this case I was at
least partially responsible for part of the wander.




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

Too many potential problems. I am confused about which one. 


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

Mine was a specific response to the comment that Harlan made. 


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

Alright, one problem is the slow response of ntp to change. While I
certainly understand why it is there, it is still a "problem". The other is
not clear yet if it is a problem, and that is the accuracy with which ntp
disciplines the clock to true UTC. Does it do the best it could with the
data available to it? It is not clear yet that it is a problem-- that is
what I am trying to measure. 



>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?

The former at present. 

>-- 
>Harlan Stenn <stenn at ntp.org>
>http://ntpforum.isc.org  - be a member!




More information about the questions mailing list