summaryrefslogtreecommitdiff
path: root/README
blob: a67f2b4d00455943e81355cd86ba6975032b774e (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170

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: <martin.burnicki@meinberg.de>

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: <martin.burnicki@meinberg.de>

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
-----------------------------------------------------------------------------------