[ntp:questions] Re: Why do clients reject win 2003 ntp server?

David Woolley david at djwhome.demon.co.uk
Thu Jun 30 20:06:01 UTC 2005

In article <1120139553.370363.230810 at o13g2000cwo.googlegroups.com>,
weage98 at yahoo.com wrote:

> I've been having problems on and off with ntpd not syncing to a Windows
Oops.  Warning signs.

>        2 u    2   64  377    0.352  3363.48 2.525
                   ^^^^^^^^^        ^

You appear to have a stratum one server on your private network, why
not use it?  (Or could it be that your server software bogusly
claims to be always running at stratum 2 as does W32Time, but you
can't be using W32Time, as that is a (broken) SNTP server and using
an SNTP server upstream of an NTP client is a protocol violation.)

> leap=00, stratum=2, precision=-6, rootdelay=125.000,
That's quite a bad root delay for something on the same private
network as a stratum one server.  Could be valid, though.

> rootdispersion=10230.255, refid=, reach=377, unreach=0,
That's an error.  This server is claiming to be validly synchronised
but its synchronisation distance is more than 10 seconds.  The maximum
synchronisation distance after which a valid NTP server will declare
itself unsynchronised and report stratum 16 and, I think, leap=11, is
only one second.

Dispersion is a pessimistic estimate of the maximum clock drift due
to the difference in time from when the upstream measurement was made
to the time the current measurement was reported downstream (and some
other thngs, like clock reading resolution).  rootdispersion, here,
is the accumulated potential drift since the stratum one server read
its radio clock (except, I suspect that it never did, because its also
not a valid NTP implementation).

> offset=3363.480, delay=0.352, dispersion=16.518, jitter=2.525,

dispersion here is the the additional impact of the time between
the query to the server and the time at which rv was answered.

The synchronisation distance is found from half the sum of delay and
root delay added to the sum of dispersion and root dipersion, and
one or two other small measures of uncertainty that are dwarfed by
the 10 seconds root dispersion.

Unlike your upstream server, your client is running a sufficiently
valid NTP implementation that it does reject the over one second
synchronisation distance.

> Any solutions to this?

There is no reason why your Windows server should be running a broken
NTP server as a free implementation of the reference implementation of
the proposed NTP 4 standard is available for Windows NT family operating
systems.  Replace the broken NTP implementation in the upstream server
(and its upstream servers, as needed) with a valid NTP implementation and
make sure that there is a complete chain of such valid servers leading
to a radio clock or, calibrated, atomic clock.

Although it is reporting an invalid stratum, your upstream
server has at least been kind enough to give an, at least slightly,
honest root dispersion.

More information about the questions mailing list