On 2013-11-27 10:26, Martin Burnicki wrote:
Brian Inglis wrote:
> On 2013-11-26 08:22, Martin Burnicki wrote:
>> Brian Inglis wrote:
[...]
> As I said above, on Windows stable, with only network servers, and
> normal maxpoll 10, as the poll interval increases, the FLL kicks in
> to drive the drift within PPB, and the offset stabilizes in the low
> us.
Yes, you said that. But on which Windows version?
7 SP1 patched up to date
Here's a short summary of possible variants, if I remember correctly:
2. With Windows Vista and later (Win 7, Server 2008) the system time
started to tick in 1 ms increments instead of 16 ms increments.
The bug where small time corrections are ignored by the Windows kernel
was not yet known, but experiments showed that on systems with 1 ms
increments the time adjustment was usually smoother if the Windows
system clock was *not* interpolated.
Agrees with my experiences with interpolation on stable and older dev.
So starting with 4.2.6, ntpd tries to figure out if the system clock
increments in 1 ms steps, or more coarsely.
In the former case interpolation was disabled, but in the latter case
interpolation was still used, basically the same way as in ntpd 4.2.4.
These Windows versions also "knew" which CPU types have problems with
their TSCs, and used PMTIMER or HPET instead.
If these Windows version decide to use TSC then TSC usually works reliably.
So, if ntpd figures out that QPC uses TSC then it reads TSC directly,
which is faster than using the QPC API.
Some of the default behavior can be altered by using some environment
variables. This great work was done by Dave Hart.
Running on AMD quad with stepping disabled in BIOS and fixes for TSC.
Tried to force TSC with HTPD_PCC=1 but ntpd switched to using HPET!
No apparent difference before/after.
3. So while ntpd 4.2.6 often works great on Windows XP / Server 2003,
as well as on Windows 7 / Server 2008 we at Meinberg received a number
of reports where the system time adjustment loop didn't settle, and
ntpq -p reported a large offset and jitter.
We could determine 2 cases where other drivers messed up the system time,
but there were still cases were we were unable to find the reason.
Fortunately a guy named Andrew Dixie came up with
https://bugs.ntp.org/show_bug.cgi?id=2328
and brought the Windows bug
http://support.microsoft.com/kb/2537623
to our attention.
He also provided a patch with a workaround which was pulled into the
current development version of ntpd.
This patch has fixed the loop settling problems on all systems I know
of where the system time adjustment didn't converge with an earlier
version of ntpd.
With current stable and a ref clock with prefer or low poll, and
backup servers with low or no minpoll, backup servers are polled
at minpoll or the same rate as the ref clock, so would never see
this issue.
I have not yet used refclocks with the Windows port of ntpd.
At least on my Linux here system this doesn't happen with ntpd 4.2.6p5.
I have a mixture of parse and SHM refclocks all clamped to minpoll 4 /
maxpoll 4, and a backup server without minpoll / maxpoll configured,
which stays at a 64 s polling interval.
Have never tried without minpoll and maxpoll.
I wouldn't expect the poll interval changes to be controlled by OS-specific
code,
but I could imagine that it depends on the results of subsequent pollings, which
may yield different offset and jitter figures under Windows and Linux, or even
with or without refclocks under Windows.
>> What if you don't have a refclock, only upstream servers?
Poll intervals increase up to maxpoll, depending on the server and
link quality.
Right, and that's exactly where I have seen offset increasing, at least under
Windows.
Thus my suggestion to limit the poll interval, which also speeds up synchronization,
which is also appreciated by most users I've talked to.
Have never experienced increasing offset, but have seen drift diverging,
with and without ref clocks!
Will try dev build again and see if anything better.
--
Take care. Thanks, Brian Inglis
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
