On 2013-12-06 11:05, unruh wrote:
On 2013-12-06, Brian Inglis <brian.ing...@systematicsw.ab.ca> wrote:
It would be better if ntpd used the drift file frequency for the first
two hours, instead of 15 minutes, before coming up with its (currently
wild assed) guesstimate, and then spending 4 hours getting back to the
drift frequency.
I do not think you understand. ntpd has a drift value-- a rate at which
it corrects the system clock (on linux this is using the adjtimex call).
If it find an offset, it changes that drift to eliminate that offset. If
one has a system where the drift file is off, but the offset is OK, then
ntp will take a while to even notice that the offset is increasing (part
of that wait is the poll interval, part is the clock filter which throws
out 80% of the poll results, and part of it is that the wrong drift will
not show up in the offset for a while.) Once it notices there is an
offset, it will alter the drift a little bit to try to eliminate that
offset. For the first while that offset will be small, and the drift
adjustment will be small. The offset continues to grow, and ntp makes
the drift correction larger and larger, but the offset continues to be
large. The drift finally badly overshoots and now the offset starts to
get smaller, but the drift keeps being increased because the offset is
still large. That drives the clock offsets finally off in the opposite
direction.
It is this behaviour, that it only looks at the current offset to adjust
the drift that is the problem. With even a little bit of history, it is
obvious that the drift rate is way off. But ntpd does not keep any
history. This is one of the reasons why chrony performs so much better
than ntpd does. It does keep a history (it does a linear regression on
the past 3-64 offsets to determine the current offset and drift) and
uses it. The number of history points kept is varied depending on how
well the linear model (offset plus drift) fits the data.
There are other differences as well.
ntpd works fine in keeping the time in a situation where there is only
noise-- variable network time delays, gaussian random white noise
affecting the local clock frequency or clock reading, etc. But for large
errors (bad drift file, sudden temperature change, ...) ntpd does poorly
in the sense that it takes a long time to notice and fix. Since one of
the key sources of noise in a computer is temperature variations, this
means that in normal use ntpd does significantly worse than chrony in
keeping the offsets small (the offsets are at least a factor of 2 and I
have heard reports of a factor of 20 higher standard deviation in ntpd
than in chrony). I do not have good figures on how its drift rate
fluctuations compare to those of ntpd-- but probably worse.
This is on Windows 7, current stable ntpd, NMEA user mode pps ref clock
(serialpps does not work with a 64 bit PCIe serial port driver stack).
I try to avoid any issues by copying the drift file daily, if it is
within limits, and copying back before startup, if it outside limits,
to reduce issues with wild ntpd drift estimates.
Could whatever was patched in Linux be required in the Windows port?
What was patched in Linux was the kernel by the kernel developers. Ie
way outside ntpd's pervue, and impossible on Windows.
AFAICT the Windows port does what the Linux kernel and adjtimex do, by
disabling the default system time adjustment, and estimating the frequency
to correct the phase offset, within the system adjustment limits.
But the drift estimate takes 15 minutes, not 11 seconds, and then is off
by many PPM, takes 2 hours to get within 1 PPM, and another 2 hours to start
oscillating around the true system drift value.
I have seen no sign of drifts diverging, it is slowly and consistently
driven towards the true hardware rate, by the ref clock.
On my system, ignoring hours after NTP restart, drift < 1ppm, drift range
< .04ppm, wander range < .0003ppm, phase offset range < 10us, mean < .25us.
TSCs are constant/invariant, synced, and all run at the 2.6GHz CPU clock,
with skews < 3us after 3 weeks uptime, so within read error timing.
NTPD runs on the last CPU at Realtime priority, so is unlikely to be
affected by system use.
I am now seeing obvious heating system artifacts, especially when the
temperature plunged to the coldest on earth the other day.
So I take notice when offset or drift are above those expected ranges!
Also why I would like to see the Windows ntpd support pinning, tsc/pcc use,
and other tweaks, independent of each other and the interpolation option.
That option currently has to be enabled to use those tweaks, but appears
in my tests to degrade results compared to my current setup.
--
Take care. Thanks, Brian Inglis
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
