Hi, The official explanation of the output of ntpq -p is here:
http://www.eecis.udel.edu/~mills/ntp/html/decode.html#peer although http://tech.kulish.com/2007/10/30/ntp-ntpq-output-explained/ is probably a bit more understandable if you're not familiar with ntpd. > remote refid st t when poll reach delay offset jitter > ======================================================== > *tick.nrc.com .GPS. 1 u 52h 36h 2 56.036 8.131 0.445 > tock.nrc.com .INIT. 16 u - 36h 0 0.000 0.000 0.000 > 192.168.2.255 .BCST. 16 u - 1024 0 0.000 0.000 0.000 Your time server is using 'tick.nrc.com', a stratum 1 server, as a reference, and has an estimated 8 ms error. You have a second peer configured, 'tock.nrc.com', but it's not being used as it's never been reached. You also have a broadcast association which is not needed if all your clients are configured in unicast mode (as the one below is). Those numbers do look a bit off, though: a 36h poll interval with those reach masks probably means that you manually set minpoll=17 for the peers, which is not a good idea. Ntpd is not designed to do 'point synchronization' like ntpdate; it runs an algorithm which periodically takes measurements from peers and continually updates an error estimate which is then used to adjust your system time (generally by slewing the kernel timekeeping loop frequency). The poll interval is how often a measurement is taken from (i.e. a packet is exchanged with) a specific peer, not how often your time is adjusted. Since frequent measurements are crucial to maintaining a good error estimate, forcing such a long poll interval basically means that your system time will be finely adjusted to a very coarse reference. > remote refid st t when poll reach delay offset jitter > ======================================================== > time.server 128.233.154.245 2 u 32 64 377 0.168 25539.9 40.427 Your client is not using the time server as a reference, and their times are 25.5s off. I don't know what the problem is but if this is the steady-state situation (as a reach mask of 377 would suggest) you probably have a configuration error on one or both ends. It would definitely help if you could post /etc/ntp.conf and /etc/conf.d/ntpd from the server and one of the clients. > Finally, is "refid 128.233.154.245" on client's pointing to the > outside stratum server normal > behaviour? Shoild "refid" not be pointing to our NTP server? It's perfectly normal: the peer your client is using is in the 'remote' column, while the 'refid' column contains the peer's upstream reference. HTH andrea
