Re: how long does it take ntpd to sync up
- From: unruh <unruh@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 28 Aug 2011 00:11:19 GMT
On 2011-08-27, Harlan Stenn <stenn@xxxxxxx> wrote:
Bill wrote:
On 2011-08-27, Chris Albertson <albertson.chris@xxxxxxxxx> wrote:
Use some logic. Assume you want to set a mechanical clock's speed by
moving the "slow/fast" lever and you can see the time only to the nearest
Ah yes, but why a) would you want to only adjust it that way, an b)
why not do a fit and figure outexactly what the rate of the clock is
and how far out it is, and correct that, rather then simply "shove the
rate a bit higher if you see the clock time is behind time now, and a
bit slower if you see the clock is ahead." (which is what ntp does).
Using phrases like "shove the rate a bit" seems pretty disingenuous to
me, Bill.
?? Not sure what you mean? ntp works by altering the rate in order to
eliminate the offsets. Is it the infomality of "shove" you object to?
second by eye. If you want the clock to lose/gain one second per
day then it will take you one day (at best) to adjust the time as it
would take that long to detect an error.
It may take a day for the error to be out by a full second, but that in
no way means it takes 24 hours' time to discover that the local clock is
running at a rate that is off by 1 sec/day. If the time is usefully
measurable to, say, 1 msec (just to pick an easy target), then we'll
"notice" an error of this rate in about a minute and a half. If we can
get usefully measurable time to .1 msec, then we can notice that error
in less than 8.7 second's time.
His hypothesis is that you can only measure the time offset to within a
second. No idea why.
If you want to adjust the rate such that it only gains one second per
month it would take a month before you'd know if you got it right.
No... see above.
You have to remember that NTP works be adjusting the rate, faster or
slower and tried hard to never "jump" the time. The only why for
anyone to know if the rate is right is to wait, greater accuracy
requires longer a wait.
But ntpd has no compunction about jumping the time if it is out by 125
ms. It does not try very hard not to jump the time at all.
128 ms.
ntp is designed to work well in a pretty wide variety of circumstances.
The model says that we adjust the time at a rate that does not exceed
500ppm, and that the computer's clock will keep time at a rate that is
not more than 500ppm away from "correct" time.
except when you jump the time, at which point it is a rate that is
infinitely different from the true rate.
It is usually much better than that.
Agreed.
Usually you do not run into either the 500PPM limit or the 128 ms jumps.
However, at a restart you can, especially if, as with the older Linux
kernels, the rate changes by up to 100PPM between separate boots.
Once ntpd has gotten the local clock sync'd, there should be no cases
where the clock diverges by 128ms - if it does there is another problem,
and that problem should be found and fixed. Given the time it takes to
"amortize" a correction of 128ms, do you feel it is better to not "step"
that correction? If you don't like the 128ms value you can change it.
A "jump" is an infinite rate. Thus ntp says that it will only change
rates by up to 500PPM except when it is infinity. Is that better than
say removing that 500PPm limit and allowing the system to correct for up
to say 100000 PPM( the limit of the adjtimex function under Linux).
This is not to say that different algorithms would not do "better" for
some folks, and we're taking steps to make it easier to deploy and test
different algorithms.
NTP works kind of like this. Small errors take a long time to detect
and smaller errors take even longer to detect. So up to a point
NTP's error
no, an error in offset of 1 usec can be detected immediately if you
have a good reference (and almost never if you do not) . And an error
in rate of 1 usec/s can be detected easily within a minute.
Yup.
So the conservative answer is "24 hours" but for most practical
purposes you are "good enough for file system time stamps and the
like" after 1 or 2 hours.
Depends on your accuracy requirements.
and as I mentioned elsewhere, it is "normal" for this stability to be
had within 11 seconds' time of ntpd starting. And if no good drift file
is available, I believe that number increases to around 15 minutes' time
(more or less).
If you have sufficiently-motivating need for even better time stability,
then relying exclusivelyl on internet time servers doesn't seem
... appropriate.
Many now use say gps which can give better time stability than that,
using ntpd.
.
H
- Follow-Ups:
- Re: how long does it take ntpd to sync up
- From: David Woolley
- Re: how long does it take ntpd to sync up
- From: Harlan Stenn
- Re: how long does it take ntpd to sync up
- References:
- Re: how long does it take ntpd to sync up
- From: Chris Albertson
- Re: how long does it take ntpd to sync up
- From: unruh
- Re: how long does it take ntpd to sync up
- From: Harlan Stenn
- Re: how long does it take ntpd to sync up
- Prev by Date: Re: how long does it take ntpd to sync up
- Next by Date: Re: how long does it take ntpd to sync up
- Previous by thread: Re: how long does it take ntpd to sync up
- Next by thread: Re: how long does it take ntpd to sync up
- Index(es):
Relevant Pages
|
