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

David Woolley david at ex.djwhome.demon.co.uk.invalid
Tue Jun 10 20:59:31 UTC 2008

Steve Kostecke wrote:
> On 2008-06-09, Ronny Egner <Ronny.Egner at siv.de> wrote:

>> ntpq> peers
>>   remote           refid    st t when poll reach delay  offset jitter
>> ======================================================================
>> solaris-server     10.x.y.2  5 u   18   64  377  0.259 892.342 30.508
>> windows-dc-serverA 10.x.v.1  4 u   17   64  377  0.214 847.816 50.335
>> windows-dc-serverB 10.x.v.1  4 u   22   64  377  0.272 923.808 45.667
> There is a signifiant diference in offsets between those remote time
> servers. And the jitter is quite high. Are all of these server on the
> same LAN? Are any at remote sites or reached over a VPN?

The delay is too low for a VPN.

>> ntpq> rv 39492
>> assID=39492 status=9014 reach, conf, 1 event, event_reach,
>> srcadr=solaris-server, srcport=123, dstadr=10.x.y.z, dstport=123, leap=00,
>> stratum=5, precision=-18, rootdelay=31.601, rootdispersion=10316.483,
> The root dispersion suggests that this peer has not been synced to a
> real time source is quite a while. This needs to be fixed first.

The root dispersion is an order of magnitude too high for the server to 
be acceptable.  I thought W32Time was the only implementation that 
didn't go to stratum 16 when the root distance exceeded 1 second, so I'm 
not quite sure how a Solaris system could be reporting a valid stratum 
but such a high root dispersion.  However the precision is too good to 
be W32Time.  Could it be using some other alternative NTP implementation?

> Could you please post the solaris-server 'ntpq -p' billboard from (in a
> condensed format as shown above)?

I think you will find that its servers are the two windows domain 
controllers.  However, if it is running an alternative NTP 
implementation it unlikely to respond to ntpq.

>> ntpq> rv 39493
>> assID=39493 status=9014 reach, conf, 1 event, event_reach,
>> srcadr=windows-dc-serverA, srcport=123, dstadr=10.x.y.z,
>> dstport=123, leap=00, stratum=4, precision=-6, rootdelay=31.250,
>> rootdispersion=10285.095, refid=10.x.v.1, reach=377, unreach=0,
> Same problem here, too.

But this could be W32Time, assuming that the recent versions aren't 
still stuck at stratum 2.

The original article appears to have failed to make it to the newsgroup, 
its not on groups.google as well as not in my feed, so I don't know if 
there was an rv 0 and what the reference times were, but I'm not sure if 
root dispersion is only the remote component, or whether it could be 
generated locally with a very old reference time.


More information about the questions mailing list