[ntp:questions] losing time fast

unruh unruh at invalid.ca
Thu Jul 12 09:10:12 UTC 2012


On 2012-07-12, Anonymous <noreply at breaka.net> wrote:
> "Ron Frazier (NTP)" <timekeepingntplist at techstarship.com> wrote:
>
>> Hi Unruh,
>> 
>> 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"
server. 
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
ingrown toenail.




More information about the questions mailing list