[ntp:questions] Re: Windows timekeeping - sudden degradation - why?

John Allen allen{at}vo{dot}lu at ntp.isc.org
Sat Dec 10 14:38:46 UTC 2005

> I'm not an expert in reading those "rv" outputs, but if you are on stratum 
> 16 it means you aren't synchronised.  Try the command:  ntpq -p deeley. 
> The "reach" column should show 377 for each server  - octal for a bit 
> field of 8 ones meaning 8 good connections.
> My guess is that you may have a TCP/IP problem, like a firewall blocking 
> access from your NTP client to its servers.


Thanks for the feedback.

First of all, I looked again at your website and I realise that my problem is 
probably not the same as yours - you had a deterioration in time-keeping, 
whereas my system seems to have given up altogether. Probably my problem belongs 
in a separate thread, but I'll keep going here as there is a lot of useful 
information on Windows and NTP in this thread.

Mine is not an obvious TCP/IP problem: the client (deeley) and server (barlow) 
are both on the LAN, whereas the only firewall - on barlow - is on the interface 
to the outside world (and barlow's ntpd synchronizes fine with pool.ntp.org 
servers). Also there is no sign of trouble with netstat -s.

When looking at the NTP log on deeley after a period of time I see a pattern: it 
records synchronization to barlow, and then 4-10 minutes later it records "no 
servers reachable", like this:

10 Dec 13:54:19 NTP[3548]: synchronized to, stratum 3
10 Dec 14:00:38 NTP[3548]: no servers reachable

Successive ntpq -p commands show:

C:\NTP>ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
*barlow   3 u   37   64   77    0.278  -816.70 861.409

C:\NTP>ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
  barlow   3 u   37   64  377    0.267  -28115. 1823.41

I'm open to any suggestions for looking at other debugging information.



John Allen
Bofferdange, Luxembourg

More information about the questions mailing list