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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
