Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!cos.UUCP!howard
From: howard@cos.UUCP.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Time RFC 868
Message-ID: <194@cos.COM>
Date: Mon, 6-Apr-87 08:45:55 EST
Article-I.D.: cos.194
Posted: Mon Apr  6 08:45:55 1987
Date-Received: Wed, 8-Apr-87 03:41:35 EST
References: <8704051517.a011510@Huey.UDEL.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: Corporation for Open Systems, McLean, VA
Lines: 33
Approved: tcp-ip@sri-nic.arpa



Time synchronization has been a major issue in 
performance work.  Several lessons learned may help.

First, if at all possible, do not depend on a single
time of day "message," but iterate to get a sense
of path delay.

A technique developed jointly by the Commerce Department
(NBS Time Lab and Institute for Telecommunications Sciences)
and Bell Labs illustrates.  In this technique, assume
a master-slave relationship for time setting, initiated
by the slave.  The slave contacts one (or more) master
clock sites, and requests a download of the time of day.

So far, this is traditional.  However, the enhancement
takes place after the master sends its time of day:
the slave RETRANSMITS what it received.  The master
then calculates the difference (in time units) between
what it sent and what the slave received, and sends
that as a correction factor.  The slave then algebraically
adds this correction factor to its clock and retransmits the
new value.This process repeats until
the desired resolution is achieved.

The first implementation of this method was over the
AT&T dial network (there was one at the time).  It turns
out that the widely held belief that you cannot assume
equal delay on both sides of a dial call is FALSE, at
least for the AT&T routing plan.  They do not, for
example, assign one side to a terrestrial and one to
a satellite facility; both go in the same way.