[ntp:questions] ntpd -x option
unruh-spam at physics.ubc.ca
Thu Mar 12 17:08:18 UTC 2009
Matthias Fuchs <matthias.fuchs at esd-electronics.com> writes:
>> Matthias Fuchs <matthias.fuchs at esd-electronics.com> writes:
>>>I am trying to understand ntpd's -x option. From the ntpd documentation
>>>I expect ntpd to adjust the (system-)time in all situations when -x
>>>is used. The only exception I see is when the system time is totally wrong
>>>(more than 1000s) ntpd will see this as an error and exit. This can be
>>>avoided through the "tinker panic 0" configuration.
>>>But now, when I start ntpd with the -x option and an offset of
>>>about 30s before ntpd is started, I get error messages like this
>>> frequency error 557 PPM exceeds tolerance 500 PPM
>>>Also there seems to be not regulation at all and ntptime reports
>>>ntp_gettime() returns code 5 (ERROR)
>>> time cd624627.39886000 Wed, Mar 11 2009 15:16:07.224, (.224737),
>>> maximum error 993296 us, estimated error 16 us
>>>ntp_adjtime() returns code 5 (ERROR)
>>> modes 0x0 (),
>>> offset 0.000 us, frequency 0.000 ppm, interval 1 s,
>>> maximum error 993296 us, estimated error 16 us,
>>> status 0x40 (UNSYNC),
>>> time constant 4, precision 1.000 us, tolerance 512 ppm,
>>>I am using two remote stratum 1 NTP servers for these tests.
>>>So is there any way to make ntpd _adjust_ the time in all situations?
>>>I am aware of the maximum adjustment of 500ppm (0.5ms/s). I would be lucky
>>>if ntpd could adjust the above offset (30s) in a day or so.
>>>I not want ntpd to step my system time! Not even once during initial
>> Do not use ntp. Use chrony instead. It has a far far faster adjustment.
>> However, it only runs on Linux.
>I thought about usig chrony, but I need hardware reference clocks as well
>(DCF77 or GPS). This works with ntpd but chrony does not seem to support
chrony does not support hardware reference clocks (Yet) (I keep meaning to add it, but do not have the time). So if you need them,
then chrony is not the way to go. However, that does not appear to be your
problem yet. You can always use ntp -g which will at least get rid of any
large initial offsets, but at the price of a clock jump on startup. You did
not want that. Secondly, try to make sure that your hardware clock(RTC) is
as well set as possible. Ie, use hwclock ( not the one which comes with
your OS as part of util-linux, but the standalone version) which tries to do
both offset and rate estimation for the RTC. That way your initial time
will be as good as possible, and any offset will be minimized.
This version which is much newer and better maintained than the util-linux
version, also includes compensation for the rtc clock drift, just as chrony
Ie, IF you do not want to have jumps even on bootup, want fast convergence
to the good time, even if it starts out way off, and want hardware clocks,
you have zero choices at present. You have to give up one of those. Which
is the cheapest to give up?
More information about the questions