Verify that ntpd is still up and running as desired is ntpq -p. That command will show all peers used and configured together.

 

Enable Statistics

vi /etc/ntp.conf

(line starting with statistics)

statistics loopstats
statsdir /var/log/ntp/
filegen peerstats file peers type day link enable
filegen loopstats file loops type day link enable

Review

/var/log/ntp/peers

/var/log/ntp/loops

 

 

Normally ntpd maintains an estimate of the time offset. To inspect these offsets, you can use the following commands:

ntpq -p will display the offsets for each reachable server in milliseconds (ntpdc -p uses seconds instead).

Can be used to check what ntpd thinks the offset and jitter is currently, relative to the preferred/current server

ntpdc -c loopinfo will display the combined offset in seconds, as seen at the last poll. If supported, ntpdc -c kerninfo will display the current remaining correction, just as ntptime does.

Can tell you something about the estimated offset/error all the way to the stratum 1

 

Compare time offsets directly use ntpdate -d server to compare the local system time with the time taken from server.

 

 

 

ntpq- p hostname

 

The very first colum contains the "tally code" character. Short overview:

• * the source you are synchronized to (syspeer)
  
  
• # source selected, distance exceeds maximum value
  
  
• o the PPS(Pulse Per Second) source if your ntpd (ppspeer, only if you have a PPS capable system and refclock)
  
  
• + candidate, i.e. it is considered a good source
  
  
• - outlyer, i.e. quality is not good enough
  
  
• x falseticker, i.e. this one is considered to distribute bad time
  
  
• blank: source discarded, failed sanity
  
  

remote

the hostname or IP of the remote machine.

refid

the identification of the time source to which the remote machines is synced. May be (for example) a radio clock or another ntp server)

st

the stratum of the remote machine. 16 is "unsynchronized". 0 is the best value, that could be (for example) a radio clock or the ntp servers private caesium clock (see http://www.eecis.udel.edu/~mills/ntp/html/index.html#intro for more information about ntp in general).

t

types available:

• l = local (such as a GPS, WWVB)
  
  
• u = unicast (most common)
  
  
• m = multicast
  
  
• b = broadcast
  
  
• - = netaddr
  
  

when

how many seconds since the last poll of the remote machine.

poll

the polling interval in seconds.

reach

an 8-bit left-rotating register. Any 1 bit means that a "time packet" was received. The right most bit indicate the status of the last connection with the NTP server. It is Octal number. Use calculator in progammer interface to translate from OCT to BIN: For example 377 translates to 11111111. Each 1 means a successful connection to the NTP server. If you just start a NTP service, and it connects successfully with its server, this number will change as follows (assuming connectivity is good):

• 00000001 = 001
  
  
• 00000011 = 003
  
  
• 00000111 = 007
  
  
• 00001111 = 017
  
  
• 00011111 = 037
  
  
• 00111111 = 077
  
  
• 01111111 = 177
  
  
• 11111111 = 377
  
  

delay

the time delay (in milliseconds) to communicate with the remote.

offset

the offset (in milliseconds) between our time and that of the remote.

jitter

the observed jitter (in milliseconds) of time with the remote.

TCP Dump NTP

You can easily check if packets are going out from your system and coming back to your box using tcpdump. NTP uses port 123, so you might issue a command like this as root:

tcpdump udp port 123

Allow it to monitor traffic for up to an hour. You should see packets going out to your time servers port 123 (ntp) and replies coming back from each of them. Your local UDP port will probably also be number 123. Kernel firewalling (ipchains or iptables) can prevent synchronization from working even if the servers are replying to your system's requests.

 

If you see packets coming in from the remote time servers, but ntpq indicates your server is not seeing them, then be sure to look at your ipchains/iptables configuration and to consider the ntpd 4.1.1 issue noted in the configuration section for Red Hat 7.3 and to check the system log for configuration messages from ntpd.

Using Syslog (/var/log/messages)

Your ntpd will log various events through your system's syslog facility. This typically means the messages will show up in /var/log/messages, in lines containing the string "ntpd". Configuration problems are reported here.