6.4 ICMP Timestamp Request and Reply

The ICMP timestamp request allows a system to query another for the current time. The recommended value to be returned is the number of milliseconds since midnight, Coordinated Universal Time (UTC). (Older manuals refer to UTC as Greenwich Mean Time.) The nice feature of this ICMP message is that it provides millisecond resolution, whereas some other methods for obtaining the time from another host (such as the rdate command provided by some Unix systems) provide a resolution of seconds. The drawback is that only the time since midnight is returned ”the caller must know the date from some other means.

Figure 6.6 shows the format of the ICMP timestamp request and reply messages.

Figure 6.6. ICMP timestamp request and reply messages.

The requestor fills in the originate timestamp and sends the request. The replying system fills in the receive timestamp when it receives the request, and the transmit timestamp when it sends the reply. In actuality, however, most implementations set the latter two fields to the same value. (The reason for providing the three fields is to let the sender compute the time for the request to be sent, and separately compute the time for the reply to be sent.)

Examples

We can write a simple program (named icmptime ) that sends an ICMP timestamp request to a host and prints the returned reply. We try it first on our small internet:

 sun %  icmptime bsdi  orig = 83573336, recv = 83573330, xmit = 83573330, rtt = 2 ms     difference = -6 ms     sun %  icmptime bsdi  orig = 83577987, recv = 83577980, xmit = 83577980, rtt = 2 ms     difference = -7 ms

The program prints the three timestamps in the ICMP message: the originate ( orig ), receive ( recv ), and transmit ( xmit ) timestamps. As we can see in this and the following examples, all the hosts set the receive and transmit timestamps to the same value.

We also calculate the round-trip time ( rtt ), which is the time the reply is received minus the time the request was sent. The difference is the received timestamp minus the originate timestamp. Figure 6.7 shows the relationship between these values.

Figure 6.7. Relationship between values printed by our `icmptime` program.

If we believe the RTT and assume that one-half of the RTT is for the request, and the other half for the reply, then the sender's clock needs to be adjusted by difference minus one-half the RTT, to have the same time as the host being queried. In the preceding example, the clock on bsdi was 7 and 8 ms behind the clock on sun.

Since the timestamp values are the number of milliseconds past midnight, UTC, they should always be less than 86,400,000 (24 —60 —60 —1000). These examples were run just before 4:00 P.M. in a time zone that is 7 hours behind UTC, so the values being greater than 82,800,000 (2300 hours) makes sense.

If we run this program several times to the host bsdi we see that the final digit in the receive and transmit timestamp is always 0. This is because the software release (Version 0.9.4) only provides a 10-ms clock. (We describe this in Appendix B.)

If we run the program twice to the host svr4 we see that the low-order three digits of the SVR4 timestamp are always 0:

 sun %  icmptime svr4  orig = 83588210, recv = 83588000, xmit = 83588000, rtt = 4 ms     difference = -210 ms     sun %  icmptime svr4  orig = 83591547, recv = 83591000, xmit = 83591000, rtt = 4 ms     difference = -547 ms

For some reason SVR4 doesn't provide any millisecond resolution using the ICMP timestamp. This imprecision makes the calculated differences useless for subsecond adjustments.

If we try two other hosts on the 140.252.1 subnet, the results show that one clock differs from sun 's by 3.7 seconds, and the other by nearly 75 seconds:

 sun %  icmptime gemini  orig = 83601883, recv = 83598140, xmit = 83598140, rtt = 247 ms     difference = -3743 ms     sun %  icmptime aix  orig = 83606768, recv = 83532183, xmit = 83532183, rtt = 253 ms     difference = -74585 ms

Another interesting example is to the router gateway (a Cisco router). It shows that when a system returns a nonstandard timestamp value (something other than milliseconds past midnight, UTC), it is supposed to turn on the high-order bit of the 32-bit timestamp. Our program detects this, and prints the receive and transmit timestamps in angle brackets (after turning off the high-order bit). Also, we can't calculate the difference between the originate and receive timestamps, since they're not the same units.

 sun %  icmptime gateway  orig = 83620811, recv = <4871036>, xmit = <4871036>, rtt = 220 ms     sun %  icmptime gateway  orig = 83641007, recv = <4891232>, xmit = <4891232>, rtt = 213 ms

If we run our program to this host a few times it becomes obvious that the values do contain millisecond resolution and do count the number of milliseconds past some starting point, but the starting point is not midnight, UTC. (It could be a counter that's incremented every millisecond since the router was bootstrapped, for example.)

As a final example we'll compare sun 's clock with a system whose clock is known to be accurate ”an NTP stratum 1 server. (We say more about NTP, the Network Time Protocol, below.)

 sun %  icmptime clock.llnl.gov  orig = 83662791, recv = 83662919, xmit = 83662919, rtt = 359 ms     difference = 128 ms     sun %  icmptime clock.llnl.gov  orig = 83670425, recv = 83670559, xmit = 83670559, rtt = 345 ms     difference = 134 ms

If we calculate the difference minus one-half the RTT, this output indicates that the clock on sun is between 38.5 and 51.5 ms fast.

Alternatives

There are other ways to obtain the time and date.

We described the daytime service and time service in Section 1.12. The former returns the current time and date in a human readable form, a line of ASCII characters . We can test this service using the telnet command:
```
 sun %  telnet bsdi daytime  Trying 140.252.13.35 ...             Connected to bsdi.             Escape character is '^]'.  first three lines output are from the Telnet client  Wed Feb  3 16:38:33 1993  here's the daytime service output  Connection closed by foreign host.  this is also from the Telnet client  
```
The time server, on the other hand, returns a 32-bit binary value with the number of seconds since midnight January 1, 1900, UTC. While this provides the date, the time value is in units of a second. (The rdate command that we mentioned earlier uses the TCP time service.)
Serious timekeepers use the Network Time Protocol (NTP) described in RFC 1305 [Mills 1992]. This protocol uses sophisticated techniques to maintain the clocks for a group of systems on a LAN or WAN to within millisecond accuracy. Anyone interested in precise timekeeping on computers should read this RFC.
The Open Software Foundation's (OSF) Distributed Computing Environment (DCE) defines a Distributed Time Service (DTS) that also provides clock synchronization between computers. [Rosenberg, Kenney, and Fisher 1992] provide additional details on this service.
Berkeley Unix systems provide the daemon timed (8) to synchronize the clocks of systems on a local area network. Unlike NTP and DTS, timed does not work across wide area networks.

6.4 ICMP Timestamp Request and Reply