[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: TS-7200: time sync issues
Ken Hornstein wrote:
Hmm...maybe I don't understand your problem, but I thought that was how
ntpd worked. When the clock isn't right, ntpd needs to both step the
clock and possibly change the clock frequency. When the clock frequency
isn't quite right, then stepping the clock will work for a while, but it
will still drift off. So, ntpd will repeatedly readjust the clock and
clock frequency until it doesn't drift much. I believe that ntpd has an
algorithm to slowly adjust the clock frequency to minimize effects of
intermittent bad data points.
This has been bugging me for a while now, and I thought I'd finally say
something about it.
On my TS-7200, ntpd has some issues synchronizing the clock.
Specifically, when ntpd starts up, it finds the time servers normally
and does the initial time step to get the clock close enough. But
after that time step occurs, the clock is off by a variable amount;
sometimes it's close to a second, but a lot of the time it's around
a quarter of a second. E.g:
Dec 7 20:28:57 modred ntpd: frequency initialized 0.000 PPM from
Dec 7 20:30:30 modred ntpd: time reset -2.381602 s
Dec 7 20:30:30 modred ntpd: kernel time sync status change 0001
Dec 7 20:46:32 modred ntpd: time reset +0.906469 s
Dec 7 21:02:04 modred ntpd: time reset +0.573713 s
Dec 7 21:18:06 modred ntpd: time reset +0.201409 s
Dec 7 21:33:12 modred ntpd: time reset +0.198393 s
Eventually what will happen is that ntpd will get "lucky" and get the time
within the 128 ms slew threshold, and then ntpd will function normally.
I've been trying to figure out what's going on here, but I've had little
luck. Does anyone have any ideas? Or even an idea of where to start?
<http://www.eecis.udel.edu/%7Entp/ntpfaq/NTP-a-faq.htm>, Section 5.
Instead, *ntpd*'s reaction will depend on the offset between the local
clock and the reference time. For a tiny offset *ntpd* will adjust the
local clock as usual; for small and larger offsets, *ntpd* will reject
the reference time for a while. In the latter case the operation
system's clock will continue with the last corrections effective while
the new reference time is being rejected. After some time, small offsets
(significantly less than a second) will be slewed (adjusted slowly),
while larger offsets will cause the clock to be stepped (set anew). Huge
offsets are rejected, and *ntpd* will terminate itself, believing
something very strange must have happened.
...For a general discussion see Section 3
<http://www.eecis.udel.edu/%7Entp/ntpfaq/NTP-s-sw-clocks.htm>. Also keep
in mind that corrections are applied gradually, so it may take up to
three hours until the frequency error is compensated...
From the ntpd man page:
Slew up to 600
Normally, the time is slewed if the offset is less than
threshold, which is 128 ms by default, and stepped if
threshold. This option sets the threshold to 600 s,
well within the accuracy window to set the clock
Note: Since the slew rate of typical Unix kernels is
0.5 ms/s, each second of adjustment requires an
interval of 2000 s. Thus, an adjustment as much as 600
take almost 14 days to complete. This option can be
the -g and -q options. See the tinker configuration file
tive for other options. Note: The kernel time
disabled with this option.
Hope this is what you were asking.
Main Index |
Thread Index |