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