[ntp:questions] losing time fast
unruh
unruh at invalid.ca
Fri Jul 13 06:43:34 UTC 2012
On 2012-07-13, Fritz Wuehler <fritz at spamexpire-201207.rodent.frell.theremailer.net> wrote:
> 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.
No idea where it says that, but if it does it is bad advice in your
situation. IF you are a server for a bunch of other machines that really
need accurate time (eg stock traders, airlines,etc) then it might be
good advice. For a home user who has spent no time trying to figure out
what his requirements are who sits on an adsl line say, it is terible
dvice, since it clogs up the national server. (No idea what you mean
when you say your's is not very good. What evidence do you have for
that?)
>
>
>> 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.
I guess all three.
>
>> 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.
I saw it and commented.
>
>> 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