"Richard B. Gilbert" <rgilber...@comcast.net> writes:
>Uwe Klein wrote:
>> Ulrich Windl wrote:
>>
>>> IMHO, most people don't care if their clock is a few minutes off, but
>>> with using NTP they suddenly expect that their clock will automagically
>>> become as good as an atomic clock.
>>>
>>> Ulrich
>>
>> Afaics it is a question of problem resilience ;-)
>>
>> A:
>> An off by 1000ppm xtal is not an easy reason
>> for exchanging motherboards with your vendor.
>> B:
>> An off by 1000ppm xtal is differently broken
>> from one that wanders up and down the ppm range
>> on changes of barometric pressure, humidity and
>> other whimms.
>>
>> Thus if satisfying timekeeping hangs on 500ppm being
>> a limit the next best step is to push on the software.
>>
>> "Software" as the word says is regularly the less
>> resilient target for problem solving ;-)
>>
>> In exchange for brushing off people that ask again and
>> again ( with rising levels of displeasure ) the
>> more efficient solution would imho be to
>>
>> make the ppm limit a configurable option.
>> or
>> leave the limit and introduce an offset.
>>
>> produce obvious error information
>> when limits are reached. i.e. forex syslog
>>
>> uwe
>>
>>
>>
>>
>>
>>
>Do we have any data on just how large a percentage of computer clocks
>are bad enough to exceed the 500 PPM limit?
And this is relevant how?
>And is there any reason for NTPD to stand on its head to cope with a
>clock that is broken that badly?
Why not, if it is easy. The problem is that it is not terribly easy.
>If you really believe that it's an arbitrary limit perhaps you should
>change it to 5,000 or 50,000 in your copy of NTPD and run it for a
>while. Please let us know how well, or how badly, it works.
The problem is that Mills hardcoded this into the kernel routines for
example on Linux. Thus the adjtimex system call, used in ntpd to adjust
the system time, has two adjustment mechanism. The frequency adjustment
and the tickvalue adjustment. The frequency adjustment has a 500PPM
limit, and it is what ntpd uses to adjust the rate on Linux. The
tickvalue has a limit of 100000PPM but is not used by ntpd (it is by
chrony). Thus what you can do on Linux is, if you find that your system
clock is out by greater than say 100PPM is to use the program adjtimex
to adjust the tickvalue by hand. From the man page for adjtimex
Set the number of microseconds that should be added to the
system time for each kernel tick interrupt. For a kernel with
USER_HZ=100, there are supposed to be 100 ticks per second, so
val should be close to 10000. Increasing val by 1 speeds up the
system clock by about 100 ppm, or 8.64 sec/day. tick must be in
the range 900000/USER_HZ...1100000/USER_HZ. If val is rejected
by the kernel, adjtimex will determine the acceptable range
through trial and error and print it. (After completing the
search, it will restore the original value.)
Ie, you can bring your clock to within about 50PPm by hand. Now, one
could well argue that ntp should do this for you automatically, but it
does not.
This of course does not help if your machine has a variable rate which
changes by 500PPM during the course of the day, due to rate
adjustmentsi, but may help if it is out consistantly by say 500PPM.
It also does not help if you are running windows.
_______________________________________________
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
