[ntp:questions] ntpd and database servers

Brian Utterback brian.utterback at sun.com
Thu Jan 21 19:43:59 UTC 2010


unruh wrote:
> But the timestamps are not lies. they are far closer to the real time
> than is that serverd by ntpd, and it is time that ntp serves, not slew
> rate. ntpd wanders off into the wilderness ( I have seen it go off by
> 20ms, when its steady state error is 2 usec) with its slewing that those
> times are far more lies that the 20usec off but with a slew rate of
> 700PPM that you might occasionally with chrony. Remember at the fastest
> ntp queries once every 16sec. By that time the slew is long finished on
> chrony ( but barely started on ntpd). Ie, I simply do not believe what
> you are saying here. 

Well, clearly a step is no different from the client's POV than a fast
slew that completes entirely between polls. But a sufficiently long
slew is going to result in downstream clients observing that their
clocks are much too fast or much too slow and make adjustments to
their own drift rates. The longer the slew goes on, the longer the
clients will be adjusting their own drifts until eventually they
client's drift corrections are going to match the servers fast slew.
Then when the server gets to where it is going, the slew will stop and
the clients will continue right past that point. Then the clients will
have to spend the same amount of time getting their drift corrections
back to normal, at which point they will have overshot and have to get
back.

Perhaps if everybody used chrony it would adjust so quickly that it
wouldn't matter. And I do agree ntpd in slewalways mode would be even
worse or at least more susceptible, since the likelihood of a slew
lasting longer than a poll interval will be greater. But I do know
that the drift cap is needed to make the proofs in Das Buch work out.

Now, it may be that the edge cases that ntpd handles better than
chrony never happen in real life; I don't know. But I do know that
within the parameters of proofs ntpd is well behaved. I don't think we
have the same assurances about chrony.

This is OT, but I do think that ntpd could be greatly improved and
could learn a lot from the approach crony uses. But I don't think
chrony is appropriate in all cases either nor is it perfect yet. I
have pointed out some clear flaws in ntpd that would be relatively
easy to fix, but was rebuffed. I do intend to address the myself
someday (assuming Dr. Mills will allow the changes in ntp_proto.c) but
haven't had the time yet.

Brian Utterback




More information about the questions mailing list