Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!tcp-ip From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: Plea for ICMP Timestamp support Message-ID: <8880@ucbvax.ARPA> Date: Mon, 8-Jul-85 17:49:00 EDT Article-I.D.: ucbvax.8880 Posted: Mon Jul 8 17:49:00 1985 Date-Received: Tue, 9-Jul-85 06:55:17 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 54 From: mills@dcn6.arpa Folks, This is a plea to the gateway implementors to incorporate ICMP Timestamp messages (cf. RFC-792) in their implementations. The reason for this timely passion is to facilitate experiments I am running to determine the feasability of synchronizing clocks across the Internet. The motivation for this is to synchonize data-base updates and cache timeouts, as well as determine one-way delays and other performance parameters. To my knowledge, the only Internet players now implementing "standard" (millisecond) ICMP Timestamps are the fuzzballs and some Unix systems, including some 4.2bsd and C/70 sites. Unfortunately, the Sun clock seems to wander badly, often over ten seconds over the course of the day. The BBN gateways do respond to ICMP Timestamp messages, but not in millisecond units. A C/70 in Germany appears to run slow by 50/60, which is hardly surprising. The following implementation hints may serve to provoke interest in bringing up an ICMP Timestamp service. Assuming some sort of line-frequency or crystal-controlled hardware clock is available, it is very simple to implement an interrupt routine that updates a double-word (32 bits) by a number of milliseconds equal to the clock interval. For 50-Hz (European) mains or crystal clocks that can be set to interrupt at a multiple of one millisecond, a 32-bit accumulator suffices; however, for 60-Hz (US) mains, an additional 16 bits of precision is neccessary for the fractional part. Just to save you some keystrokes, in the case of 60-Hz systems, the magic number of milliseconds, expressed as a 32-bit quantity in two 16-bit words, is 16 in the high-order 16 bits (integer part) and 43691 in the low-order 16 bits (fraction part). You should also roll over the clock at 24 hours, which in milliseconds expressed as a 32-bit quantity in two 16-bit words, is 1318 in the high-order 16 bits and 23552 in the low-order 16 bits. It is not necessary that the clock be synchronized to some external reference, since corrections can be computed remotely. In this case the high-order bit of the 32-bit timestamp returned in the ICMP Timestamp Reply should be set to one. If you attempt to synchronize the clock to a local reference, such as an operator command, I suggest you not disturb the clock accumulator itself, but use an additional 32-bit quantity that is added (with interrupts disabled!) modulo-24 hours to the clock accumulator before passing to the application level. In this case the high-order bit of the timestamp should be set to zero. I promise to reach out and tickle any implementation that manages this magic and report my finidngs. If there is interest in tickling fuzzballs, I will suggest appropriate targets upon individual request. I would expecially like to compare line frequency stability between the four regional power grids in (1) Quebec, (2) most of Texas, (3) west of the Rockies and (4) east of the Rockies, as well as overseas. The goal is to assess whether the rate of phase change between the grids is sufficiently small to assume reliable clocks can be achieved with relatively infrequent broadcast corrections. Dave -------