>>> In article <[EMAIL PROTECTED]>, Unruh <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> http://ntpforum.isc.org - be a member! _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
