[ntp:questions] losing time fast
Fritz Wuehler
fritz at spamexpire-201207.rodent.frell.theremailer.net
Fri Jul 13 05:12:57 UTC 2012
unruh <unruh at invalid.ca> wrote:
> 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.
That's all very nice but it says on the ntp.org page to use a national
server if you have one. Mine happens to not be very good but that doesn't
mean I shouldn't use it if it was good.
> The network variability is factors to 10-1000 times worse than the error you
> are correcting by using the national time standard.
Nobody said it was the cause, since I'm not using it. But I can't tell who
you are arguing with, the guy who suggested it or me for agreeing with it,
or ntp.org for saying it's a good idea.
> 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.
Posted already, have no idea when the post will arrive though.
> 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.
Sounds like the voice of experience. But then again you have proven yourself
obnoxious and unhelpful in other newsgroups so...
>
>
More information about the questions
mailing list