[ntp:questions] NTP shows all servers in condition "reject"

David Woolley david at ex.djwhome.demon.co.uk.invalid
Fri Jun 13 07:40:48 UTC 2008

Martin Burnicki wrote:

> Concerning the Windows servers - are they running NTP, or w32time? If they
> run w32time they may not be good time sources for "real" NTP nodes running

It is possible to use W32Time as a source for NTP, although, before 
Windows 2003, it violates the NTP specification to do so.  It is almost 
never a good thing to do.  The W32Time instance must be synchronised to 
some proper source of time for this to work - a W32Time root with no 
upstream sources won't work.

> on your Linux machines. Anyway, the fact that the jitter is also high for
> these servers lets me assume your network connection is not very good.

The jitter is a secondary statistic.  The root dispersion is the key. 
That indicates that the Windows systems haven't been synchronised to a 
real source of time for several days (7.7 days, if it uses the same 
worst case drift assumption as does ntpd).  Normal NTP servers would 
alarm under those circumstances (which is why I find the Solaris system 
confusing - it is alarming on one upstream, but is accepting and 
propagating the huge root dispersion on the other.  I wonder if someone 
has changed MAXDISTANCE on that system, e.g. to 10 seconds.

If one had the reference time for the Windows servers, I think one would 
find it was quite ancient.

>> I dont know much about the windows servers. The customer told me i can
>> use them for time synchronization - so i did it because the network i
>> highly protected from the outside lan.

That almost certainly means that they are not being synchronised by 
anything, and are operating like ntpd using a local clock, but with the 
difference that ntpd attributes a root dispersion based on the fiction 
that it successfully synchronised on every read of the local clock.  I 
think W32Time is more honest in this respect.  With the reference 
implementation the server is responsible for pretending all is well, but 
for a pure W32Time network, it is the client that is responsible for 
ignoring the high root dispersion, and believing all is well.

The ntpd strategy makes sense if you are operating an isolated time 
island with a single source of local clock time,ar (although this isn't 
common) you are synchronising the local clock by means other than NTP, 
but is not so good when the local clock is used as a fall back for lost 
external connectivity.

> So, in Windows terms, all 3 upstream servers could be called "synchronized"
> whereas for NTP the times from those 3 servers differ so much that ntpd is
> unable to select the server with the "right" time.

In this case it has no trouble deciding between them.  Root dispersion 
is over 10 seconds, but the offset discerpancies are a couple of orders 
of magnitude less than this; any offset difference upto 10 seconds would 
pass the truechimer test.  ntpd is actually rejecting before that test 
because the excessive root dispersion means that it can't trust the 
offsets to better than 10 seconds.

More information about the questions mailing list