Network Time Protocol

Use the ntpq -p command to get NTP status:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(1)        LOCAL(1)        12 l   15   64  377    0.000    0.000   0.001
+192.168.206.25  196.1.29.233     2 u  199  256  377    0.638  119.307  17.469
-192.168.206.26  196.1.29.233     2 u  101  256  377    0.763  148.057  21.290
*192.168.206.27  196.1.29.233     2 u  224  256  377    0.695  122.400  15.020
+192.168.206.28  196.1.29.233     2 u  157  256  377    0.711  124.704  15.411

The start of each entry is prefixed by a character:

The following values are described below:

remote:

IP address of peer

refid

IP address of reference for peer

st:

Stratum of peer

t:

Type of peer (Local, unicast, multicast or broadcast)

when:

When the last packet was received (number of seconds ago).

Every time a when count reaches the poll number in the same line, the NTP daemon queries the time from the corresponding time source and resets the when count to 0. The query results of each polling cycle are filtered and used as a measure for the clock's quality and reachability.

poll:

Polling interval (seconds) - How often the time server is queried.

reach:

The column reach (reachability register - octal) shows if a reference time source could be reached at the last polling intervals, i.e. data could be read from the reference time source, and the reference time source was synchronized.

The value must be interpreted as an 8 bit shift register whose contents is displayed as octal values. If the NTP daemon has just started, the value is 0. Each time a query was successful a '1' is shifted in from the right, so after the daemon has been started the sequence of reach numbers 0, 1, 3, 7, 17, 37, 77, 177, 377.

The maximum value 377 means that the eight last queries were completed successfully. The NTP daemon must have reached a reference time source several times (reach not 0) before it selects a preferred time source and puts an asterisk in the first column. Estimated delay (miliseconds)

delay:

The delay value is derived from the roundtrip time of the queries.

offset:

The offset (miliseconds) in value shows the difference between the reference time and the system clock. If the reference clock is ahead of the system clock, you'll have a positive number.

jitter:

The jitter (dispersion - miliseconds) value indicates the magnitude of jitter between several time queries.

The calculated system NTP drift value is stored in ntp.drift. This is the error in the intrinsic frequency of the clock on the computer it is running on.

Its recorded in PPM (parts per million), and is the systematic frequency error of the system clock (i.e. the clock permanently loses time or gains time). If ntp.drift contains 0.000, your clock perfectly keeps time (except for random errors).

100 PPM = 8.64 seconds / day
12 PPM correspond to one second per day roughly.
500 PPM mean the clock is off by about 43 seconds per day.

Therefore, a value of -13.409 in ntp.drift implies the system clock is approximately 1.16 seconds slower than the reference clock a day.

Frequency error ? exceeds tolerance 500 PPM:

The hardware clock frequency error exceeds the rate the kernel can correct. This could be a hardware or a kernel problem.

Log Error clk_fault - clock LOCAL(1) event 'clk_fault' (0x03):

The message simply results from a variable which has not been properly initilized so that the message is printed before the clock's status has been checked. You can simply ignore it.

Under ordinariy conditions, ntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities. Under conditions of extreme network congestion, the roundtrip delay jitter can exceed three seconds and the synchronization distance, which is equal to one-half the roundtrip delay plus error budget terms, can become very large.

The ntpd algorithms discard sample offsets exceeding 128 ms, unless the interval during which no sample offset is less than 128 ms exceeds 900s. The first sample after that, no matter what the offset, steps the clock to the indicated time. In practice this reduces the false alarm rate where the clock is stepped in error to a vanishingly low incidence.

As the result of this behavior, once the clock has been set, it very rarely strays more than 128 ms, even under extreme cases of network path congestion and jitter. Sometimes, in particular when ntpd is first started, the error might exceed 128 ms. This may on occasion cause the clock to be set backwards if the local clock time is more than 128 s in the future relative to the server. In some applications, this behavior may be unacceptable. If the -x option is included on the command line, the clock will never be stepped and only slew corrections will be used.

The issues should be carefully explored before deciding to use the -x option. The maximum slew rate possible is limited to 500 parts-per-million (PPM) as a consequence of the correctness principles on which the NTP protocol and algorithm design are based. As a result, the local clock can take a long time to converge to an acceptable offset, about 2,000 s for each second the clock is outside the acceptable range. During this interval the local clock will not be consistent with any other network clock and the system cannot be used for distributed applications that require correctly synchronized network time. A slewed clock never moves backwards; it is just slowed down.

The maximum slew rate is 500PPM, which corresponds to a maximum adjustment of 0.5ms / second correction.

ntpd -q -M -g -c “c:\Program Files\NTP\etc\ntp.conf”