Re: losing time fast

On 2012-07-12, Anonymous <noreply@xxxxxxxxxx> wrote:
"Ron Frazier (NTP)" <timekeepingntplist@xxxxxxxxxxxxxxxx> 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.


.

Relevant Pages

  • Re: losing time fast
    ... I am using ntp version 4.2.4p7 which was installed with Slackware ... Stop ntpd using whatever means is normal for your OS. ... the system software clock at the wrong rate and the clock was rapidly ... If he is really loosing minutes par day, then there is no drift file ...
    (comp.protocols.time.ntp)
  • Re: Very large offset and jitter values after reboot
    ... Strangely every time I reboot I get results like this, wich settle down after a while: ... ntpd will discipline the clock in the usual way. ... No drift file is better than one with an incorrect value for drift. ... the driftfile is being written to over a longer period of time and is used to correct a general drift of the clock. ...
    (comp.protocols.time.ntp)
  • Re: once ntpd stops, does the drift file value continue to get used for clock adjustments?
    ... The value in the "drift file" is a snapshot of the frequency correction ... being applied to the system clock. ... The purpose of the drift file is to provide ntpd with an approximate ...
    (comp.protocols.time.ntp)
  • Re: losing time fast
    ... You may be right about the drift file. ... I don't know for sure what caused the runaway clock I experience in the ... others (the national time standards) using up other's scarce resources ... IF you are a server for a bunch of other machines that really ...
    (comp.protocols.time.ntp)
  • Re: losing time fast
    ... You may be right about the drift file. ... I don't know for sure what caused the runaway clock I experience in the ... others (the national time standards) using up other's scarce resources ... ntpd is absolutely incapable of correcting errors like that or ...
    (comp.protocols.time.ntp)