Re: ntpd -x option
- From: Unruh <unruh-spam@xxxxxxxxxxxxxx>
- Date: Thu, 12 Mar 2009 21:12:49 GMT
Steve Kostecke <kostecke@xxxxxxx> writes:
On 2009-03-12, Unruh <unruh-spam@xxxxxxxxxxxxxx> wrote:
Ie, IF you do not want to have jumps even on bootup, want fast convergence
to the good time,
In your haste to proselytize for chrony you've overlooked the fact the
the OP did not specify that he needs fast convergence.
In fact, in a discussion on IRC he told me that the speed of convergence
is at the bottom of his list of requirements. The most important thing
is that his clock _never_ steps.
even if it starts out way off, and want hardware clocks, you have zero
choices at present. You have to give up one of those. Which is the
cheapest to give up?
The problem that the OP needs to solve is the fact that ntpd sees that a
frequency correction of ~700PPM is required and that it exits.
Yes, that will happen with a large correction needed. The correction is
applied by taking the size of the offset, multiplying it by a small factor
and altering the rate by the result. If the offset is large, the rate
change will be large. Now, I had thought that ntp 4.2.4 clamped it at 500PPM but
my memory of reading the source is not good enough.
Note than an offset of minutes or hours would take many days to correct.
(At 500PPM, 1 min takes 2000 min to correct, and 1 hour, 2000 hours.
Why you would want to have your clock out of commission for that length of
time I do not know. It would almost certainly crash long before it got on
time, and everything would have to start over. Ie, everyone wants speed. )
- Prev by Date: Re: Significance of "space" in the ntpq -p display
- Next by Date: Re: demonstrate traceability to UTC
- Previous by thread: Re: ntpd -x option
- Next by thread: Re: ntpd -x option