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