tcp-ip@ucbvax.ARPA (07/09/85)
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 -------
tcp-ip@ucbvax.ARPA (07/09/85)
From: tmallory@bbnccv Dave, Have you considered the alternative approach of including the time unit with the icmp time-stamp rather than forcing conversion to milliseconds which seems a little arbitrary? You would then have some idea of the granularity of the clock ticks you are comparing. (Perhaps a self-defining message using x.409?) A 24-hour rollover seems to be a reasonable request. Tracy
tcp-ip@ucbvax.ARPA (07/09/85)
From: Dennis Rockwell <drockwel@CSNET-SH.ARPA> One thing to note about the 4.2 timestamp reply (as distributed): it is computed assuming no leap-time other than whole days. It takes the UNIX time, which is measured from midnight UT (15 years ago), divides by one day, and uses the remainder. So, for instance, the recent leap-second is basically ignored. Of course, if you look at it the other way, we've moved the zero point by the leap-time since zero. Of course, this makes no practical difference to most of us, since clocks among our machines (all in the same room) are normally different by as much as five minutes. I suppose that this is what Dave is proposing to remedy? Dave, feel free to poke CSNET-RELAY, CSNET-SH, and CSNET-DEV. For real thrills, poke 192.5.58.5, which is CSNET-DEV's PDN address. Expect to lose the first packet per five minutes, at least for a while yet. Dennis Rockwell CSNET Technical Staff
tcp-ip@ucbvax.ARPA (07/09/85)
From: Stephen Casner <Casner@USC-ISIB.ARPA> Dave, In our EPOS operating system, we use a different technique for the 60 Hz clock. Rather than adding the approximate fraction 2/3 to a fractional extension of the accumulator, we use a modulo-3 counter to add an extra 1 to the accumulator on 2 out of every 3 cycles. For the example of a millisecond clock, 17 is added on the first 2 out of 3 cycles and 16 is added on the third cycle. (In EPOS we actually keep a 48-bit clock of 40 microsecond ticks, but the principle is the same.) The advantage of this method is that it is exact rather than having an error of .000005 ms per 60 Hz tick or about 1 ms per hour. The number of instructions is about the same with either technique. Here is a code segment for the PDP11: DEC TRICYC ; Is this the third of three cycles? BPL 1$ ; No - just update time MOV #2,TRICYC ; Yes - reset the modulo-three counter ADD #INCTIM,UPTML ; Update time less 2/3 fraction to adjust BR 2$ ; for the two extra 1/3 fraction 1$: ADD #INCTIM+1,UPTML ; Update time including 1/3 fraction extra 2$: ADC UPTMM ; Carry the update out through 32 bits The BR 2$ can be eliminated by replicating code if that is practical. -- Steve -------
tcp-ip@ucbvax.ARPA (07/09/85)
From: mills@dcn6.arpa Tracy, Several years ago we chatted up the timestamp issues and ended up with a number of proposals (see old RFCs). One of the conclusions was that simple, grumpy gateways could participate with only the barest bones of code and with only minimal protocolmanship. We could recook those conclusions handily (an x.409 IP option?!), but not without shaking the dust off the ICMP spec. Notwithstanding the above, the experience with our local-net algorithms suggests a much more important issue is the sender's estimate of the intrinsic accuracy of his clock, whether derived from power mains, local radio clock or second-hand from a UPS with a free-running 59.8-Hz oscillator. Dave -------