Re: losing time fast
- From: unruh <unruh@xxxxxxxxxx>
- Date: Thu, 12 Jul 2012 09:10:12 GMT
On 2012-07-12, Anonymous <noreply@xxxxxxxxxx> wrote:
"Ron Frazier (NTP)" <timekeepingntplist@xxxxxxxxxxxxxxxx> wrote:
I'm glad you like the suggestions. You may be right about the drift file.
I don't know for sure what caused the runaway clock I experience in the
past. However, it's my understanding that NTP sets the computer clock
frequency to what it finds in the drift file at startup. If the drift
file is way off, for whatever reason, then the initial clock frequency
will be way off. As far as I know, it won't write another drift file for
an hour. So, during that hour, particularly if the polling interval is
long, the clock can be running so fast or slow that it will drift so far
out that NTP might just give up on it.
That may have been what happened because the drift file looked "normal" to
me when I checked it but the clock was just getting worse and worse, as if
ntp wasn't running. ntpdate sometimes fixed it but it would start drifting
very quickly in huge amounts, minutes until it was 45 or more minutes off.
Why a national time server? No need for that kind of accuracy.
As long as we are all interested in precise and accurate time, every
possible improvement that's easy to make should be worthwhile. Unfortunately
I live in a country with erratic local time servers so I use the asian pool
that has been mostly ok as far as I can tell.
Nuts. If you are interested in accurate time, you examine your error
budget and find the places to make fixes. You do not impose yourself on
others (the national time standards) using up other's scarce resources
to make correction which change your error budget not a whit. The
network variability is factors to 10-1000 times worse than the error you
are correcting by using the national time standard.
Anyway, post your /etc/ntpd.conf file so we can see what you are trying
to do, instead of having to guess. For example are you using the "local"
But a clock that goes to fast by thousands of PPM has nothing to do with
ntpd. ntpd is absolutely incapable of correcting errors like that or
causing errors like that. It is either a hardware problem, a calibration
problem, or you are running as a VM. Do not look at ntpd for the
problem. It is like trying to clean out your ear cannals, when what you have is an
- Re: losing time fast
- From: Fritz Wuehler
- Re: losing time fast
- Prev by Date: Re: losing time fast
- Next by Date: Meinberg is raffling off PCI Express clocks for participation in the NTP Pool
- Previous by thread: Re: losing time fast
- Next by thread: Re: losing time fast