[ntp:questions] Linux/Windows: Different synchronization behaviour

David Woolley david at djwhome.demon.co.uk
Tue Oct 31 22:19:29 UTC 2006

In article <1162279048.696498.218770 at k70g2000cwa.googlegroups.com>,
"Geir G <geir.guldstein at start.no> wrote:

> *nccgps02        .hopf.           1 u   30   64   77    7.812  -370.45
The Linux one hasn't finished starting.
The 7.812's are weirdly identical!

>  7.812

> precision=-7, rootdelay=7.812, rootdispersion=1824.707, peer=46724,
Because it hasn't finished starting the dispersion hasn't converged,
so it will apply very large error tolerances on the times, and, in this
case allow the two times that are 1 second apart to both be accepted.
Hopefully, once dispersion has tightened it will reject one of them
(this system has a third vote, which will tie break).

This precision is extremely poor for a modern machine.  It probably 
indicates that clock ticks are not being interpolated - maybe that
is because the kernel assumes it has a TSC and has dropped the code that
read the balance in the CTC, but maybe you have a chip with no TSC support.
This, I think, explains the 7.812s, at least partly.

> x192.168.1.142   .hopf.           1 u   27   64  377    0.805  -1001.6
Windows has fully loaded the filter pipeline

> precision=-20, rootdelay=0.000, rootdispersion=17.445, peer=0,

It's got a reasonable precision (1 microsecond) as against the +10ms
(1/128 s) that the Linux system is reporting.  More importantly,
dispersion is tight, and, as 1 second > 17ms the error bands for the two
times don't overlap, and as the third (and fourth) servers are doing an
error recovery step, there is no tie breaker.  Both servers are therefore
rejected as there is no overlap that contains the majority of the servers.

I don't know why the HOPF has a local clock fallback configured.  In
my view they are overused.

More information about the questions mailing list