This is the README file for the "ntptest" tool that is similar to ntpdate which comes with the NTP software package. It sends an NTP request packet to an NTP server, receives the response packet, and evaluates the returned information. Beside these basic functions ntptest supports a monitoring mode which can be enabled with -Z. In monitoring mode 4 req/s are sent to a server and the status as well as offset *changes* from the initial offset are printed in 1 line. This is useful e.g. for leap second monitoring of remote devices. To build the executable under Linux just unpack the tar.gz source code archive, cd into the unix/ directory below the extracted directory, and run "make". Then type "./ntptest -?" to get some usage information. For Windows there is a project file for Visual Studio 2008 in the windows\vs2008 directory. Build the solution, then run the compiled binary "ntptest -?" to get some usage information. At least the hostname or IP address of a remote NTP server has to be specified on the command line, e.g.: ------------------------------------------------------------------------------ #ntptest> ./ntptest ntp1.py.meinberg.de ntptest v1.11, (c) Meinberg 2014-2019, contact: Host ntp3.py.meinberg.de Request packet: mode 3 (client) version 4, leap 3, stratum 0, poll 6, prec -18 (3.81 us) root delay: 00000000 (0.000000 s) root dispersion: 00000000 (0.000000 s/s) reference id: 00000000 ("....") Ref time: 00000000.00000000 1900-01-01 00:00:00.000000000 Org time (T1): 00000000.00000000 1900-01-01 00:00:00.000000000 Rcv time (T2): 00000000.00000000 1900-01-01 00:00:00.000000000 Xmt time (T3): E119EA92.821A694D 2019-09-04 07:47:30.508215504 Curr time (T4): E119EA92.821A694D 2019-09-04 07:47:30.508215504 Response packet: mode 4 (server) version 4, leap 0, stratum 1, poll 6, prec -20 (954 ns) root delay: 00000000 (0.000000 s) root dispersion: 0000000C (0.000183 s/s) reference id: 0053524D ("MRS.") Ref time: E119EA8D.096F0C83 2019-09-04 07:47:25.036850721 Org time (T1): E119EA92.821A694D 2019-09-04 07:47:30.508215504 Rcv time (T2): E119EA92.821FAF7B 2019-09-04 07:47:30.508295981 Xmt time (T3): E119EA92.82258D03 2019-09-04 07:47:30.508385480 Curr time (T4): E119EA92.822EE59F 2019-09-04 07:47:30.508528090 turnaround: 312.586 us (T4 - T1) server latency: 89.498 us (T3 - T2) computed delay: 223.088 us ((T4 - T1) - (T3 - T2)) computed offset: -31.067 us (((T2 - T1) + (T3 - T4)) / 2) ------------------------------------------------------------------------------ The output shows the contents of the request packet sent to the NTP server, and the response packet received from the server. The values T1..T4 from the response packet are evaluated as suggested by the NTP algorithms. The "turnaround" time (T4 - T1) tells how long it takes on the client until a response is received after the request has been sent. The "server latency" value (T3 - T2) indicates the time interval on the server until it sends the reply after it has received the request. The computed "delay" and "offset" numbers are the estimated packet delay and time offset between the client and the server. If called with parameter -c the program runs continuously and sends one request per second. The minimum and maximum numbers for the computed values from several pollings are recorded and displayed. Please note: - The only relevant number in the request packet is the transmit time (T3). - Upon receipt of the request packet the NTP server copies T3 into the "originate time" field, which becomes T1 in the response packet seen by the client. So T3 of the request packet should always match T1 of the response packet. - The server latency may vary with the load on the NTP server. However, this doesn't really matter since it is elimiated in the calculation of the delay and offset on the client. - The computed delay and time offset can only be accurate if the packet propagation delay is constant all the time, and the same for packets in both directions. - In reality the packet propagation delay to or from the NTP server *does* vary mor or less for each packet exchange (polling), and there can be "spikes" where single packet in either direction are delayed significantly longer than usual, in which case the computec delay and offset are significantly off their mean values. - The NTP daemon has been designed to cope with such spikes, and the "delay" and "offset" values displayed by "ntpq -p" are filtered values based on weighted avarages from subsequent poll, so the results displayed by this program will vary more than those displayed by "ntpq -p". - Under Windows the "precise" time API is used, if available. This is the case in Windows 8 / Windows Server 2012 and newer. Under older Windows versions the precision of the system time is limited to 1 ms or even worse, so the calculated time offsets are not very precise. - Don't run this program only with parameter -c against public NTP server. Polling at 1 request per second can be considered as abusive. Use the -s parameter to increase the sleep interval betweent to pollings to at least 64 seconds (-s 64), which is the minimum polling interval used by the NTP reference implementation. Monitoring offset and status ---------------------------- The -Z option can be used to monitor how the offset and leap status of a remote NTP node changes over time. In the example below the ntptest program runs on a system which doesn't observe a leap second and monitors a remote Linux system which inserts a leap second by stepping the time back by -1 s at the beginning of the leap second, so the displayed offset step from ~0 ms to ~-1000 ms. ----------------------------------------------------------------------------------- #ntptest> ./ntptest -Z 172.16.100.44 ntptest v1.3, (c) Meinberg 2014-2016, contact: Host 172.16.100.44, running continuously ... ... D93DABFD.3C940F7A 2015-06-30 23:59:57.236634223, st 1, leap 1, offs[ms]: -0.066 D93DABFD.7CBF93CB 2015-06-30 23:59:57.487298237, st 1, leap 1, offs[ms]: -0.054 D93DABFD.BCEABA70 2015-06-30 23:59:57.737956669, st 1, leap 1, offs[ms]: -0.030 D93DABFD.FD785D4F 2015-06-30 23:59:57.990117866, st 1, leap 1, offs[ms]: -0.079 D93DABFE.3DAAF300 2015-06-30 23:59:58.240889728, st 1, leap 1, offs[ms]: -0.049 D93DABFE.7DD24649 2015-06-30 23:59:58.491489785, st 1, leap 1, offs[ms]: -0.062 D93DABFE.BDF982C1 2015-06-30 23:59:58.742088482, st 1, leap 1, offs[ms]: -0.047 D93DABFE.FE291448 2015-06-30 23:59:58.992814319, st 1, leap 1, offs[ms]: -0.058 D93DABFF.3E533E34 2015-06-30 23:59:59.243457687, st 1, leap 1, offs[ms]: -0.065 D93DABFF.7E7DFE72 2015-06-30 23:59:59.494110014, st 1, leap 1, offs[ms]: -0.117 D93DABFF.BEAD838E 2015-06-30 23:59:59.744835111, st 1, leap 1, offs[ms]: -0.053 D93DABFF.FED45A02 2015-06-30 23:59:59.995427728, st 1, leap 1, offs[ms]: -0.070 D93DABFF.3F00B222 2015-06-30 23:59:59.246104367, st 1, leap 1, offs[ms]: -1000.079 <-- leap second D93DABFF.7F31D91A 2015-06-30 23:59:59.496854370, st 1, leap 1, offs[ms]: -1000.068 <-- leap second D93DABFF.BF59FF26 2015-06-30 23:59:59.747466990, st 1, leap 1, offs[ms]: -1000.073 <-- leap second D93DABFF.FF80E16F 2015-06-30 23:59:59.998060311, st 1, leap 1, offs[ms]: -1000.070 <-- leap second D93DAC00.3FC6AA4F 2015-07-01 00:00:00.249125141, st 1, leap 1, offs[ms]: -1000.093 D93DAC00.800046AE 2015-07-01 00:00:00.500004212, st 1, leap 1, offs[ms]: -1000.074 D93DAC00.C02F7195 2015-07-01 00:00:00.750723933, st 1, leap 0, offs[ms]: -1000.086 D93DAC01.008052E2 2015-07-01 00:00:01.001958065, st 1, leap 0, offs[ms]: -1000.088 D93DAC01.40B4429D 2015-07-01 00:00:01.252750552, st 1, leap 0, offs[ms]: -1000.085 D93DAC01.80F0F7A7 2015-07-01 00:00:01.503676870, st 1, leap 0, offs[ms]: -1000.097 D93DAC01.C124AAC3 2015-07-01 00:00:01.754465744, st 1, leap 0, offs[ms]: -1000.111 D93DAC02.0155AB27 2015-07-01 00:00:02.005213448, st 1, leap 0, offs[ms]: -1000.095 D93DAC02.4189C881 2015-07-01 00:00:02.256008655, st 1, leap 0, offs[ms]: -1000.101 D93DAC02.81C3CDCF 2015-07-01 00:00:02.506893981, st 1, leap 0, offs[ms]: -1000.077 -----------------------------------------------------------------------------------