[ntp:questions] NTP shows all servers in condition "reject"
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
> 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