Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!think!ames!sdcsvax!darrell
From: howard@COS.COM (Howard C. Berkowitz)
Newsgroups: comp.os.research
Subject: Re: Keeping Time Synchronous in a Network
Message-ID: <3277@sdcsvax.UCSD.EDU>
Date: Fri, 5-Jun-87 16:26:43 EDT
Article-I.D.: sdcsvax.3277
Posted: Fri Jun  5 16:26:43 1987
Date-Received: Wed, 10-Jun-87 01:05:54 EDT
Sender: darrell@sdcsvax.UCSD.EDU
Organization: Corporation for Open Systems, McLean, VA
Lines: 25
Approved: mod-os@sdcsvax.uucp


An approach used in performance measurement, developed jointly
by the NBS Time Lab and AT&T Bell Labs, assumes an accurate time
source at a central reference point (e.g., a dual oven crystal
locked to WWV for 1**10-7 accuracy).

In this approach, a slave node desiring synchronization contacts
the master timer using a communications channel of constant delay.
Dial calls through AT&T (unclear about others) have constant delay,
on both sides of the call, during that call.

The master transmits its current time value to the slave.  On receiving
and storing it, the slave retransmits its current time-of-day value
to the master.  The master computes the difference between its current
time value and that sent to it, divides it by two (assuming equal
delay on both sides of the channel), and sends that quotient as a 
correction factor to the slave.

This process is repeated until the clocks synchronize.  Failure
to synchronize (within clock accuracy) suggests variable channel delay.

I am not convinced we have a decent way to synchronize in a ring,
although it can be approximated, in a deterministic network, by
adding the delays through each node.  I would not want to try
on a CSMA LAN unless it were idled other than for timing traffic.