Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/mod.std.unix.v5/text0016.txt

Text File | 1987-06-30 | 9.2 KB | 232 lines

A wheel that frequently gets reinvented is how to tell the time over networks.
Much work has been done on this subject in the ARPA Internet from back when
there was only the ARPANET up to a few months ago.  This article is a brief
summary of the existing methods.

Herein GMT and UT are used as synonyms for Coordinated Universal Time.

Here is a list of references in (mostly) chronological order, to be followed
by abstracts of or comments on each.  Probably the most widely used protocol
is RFC868.  Possibly the best for what it tries to do is RFC958.  For use
in synchronizing clocks of machines on a local area network, TSP will likely
become increasingly important, because it will come with 4.3BSD.  Several
higher-level schemes employ RFC792.

If there is sufficient interest, I will post the relevant RFCs to mod.sources.

(RFC792) Sep 81    (Postel)      Internet Control Message Protocol
(RFC778) 18 Apr 81 (Mills)       DCNet Internet Clock Service
(RFC867) May 83    (Postel)      Daytime Protocol
(RFC868) May 83    (Postel)      Time Protocol
(RFC956) Sep 85    (Mills)       Algorithms for Synchronizing Network Clocks
(RFC957) Sep 85    (Mills)       Experiments in Network Clock Synchronization
(RFC958) Sep 85    (Mills)       Network Time Protocol
TSP: The Time Synchronization Protocol for UNIX 4.3BSD, R. Gusella and S. Zatti


(RFC792) Sep 81    (Postel)      Internet Control Message Protocol

This is one of the basic protocols of the TCP/IP suite.  It sits on top
of IP and is mostly used for inter-network routing.  However, it also has
a Timestamp message, which is used by several later time applications.
This message allows exchanging time in milliseconds since midnight UT.

(RFC778) 18 Apr 81 (Mills)       DCNet Internet Clock Service

An early use of the ICMP Timestamp messages of RFC792 to synchronize
clocks of machines on a more or less local network.  Superseded by RFC958.

(RFC867) May 83    (Postel)      Daytime Protocol

Allows connecting to a foreign host and receiving the time as an ASCII
character string.  Seldom implemented and little used because there is
no standard for what the character string should be (much less for what
time zone it should be in).


(RFC868) May 83    (Postel)      Time Protocol

The basic Internet time of day protocol for many years.  Quoting:

    This protocol provides a site-independent, machine readable date and
    time.  The Time service sends back to the originating source the time in
    seconds since midnight on January first 1900.

The choice of seconds was deliberate because this protocol was intended to
be used between systems on long-haul networks on which greater precision
would only give an illusion of accuracy.  Sometimes used in conjunction
with ICMP Timestamp messages when communicating with hosts from which
greater accuracy is available.  Best used to poll several hosts and compare
their time before setting the local host's time.

It may be used on top of either TCP or UDP:  UDP is better because of
lessened load on machines running the servers and because of lessened
round trip times.

At least four implementations of this protocol for 4.2BSD exist:

name    author                    anonymous ftp source

rdate    Sun Microsystems Incorporated        none
    Polls one host and believes it if it responds.
    Uses inetd.  Only uses TCP.

ndate    Christopher Kent <[e-mail]> merlin.purdue.edu:dated.flar
    Tries many hosts in succession, believes the first to respond.
    Tries for accuracy by taking round trip delay into account.
    Does not use inetd.  Uses UDP.

nettime    Richard Johnson <[e-mail]>        uci.edu:pub/nettime.c
    Polls many hosts, even broadcasts a request over ethernet.
    Does some averaging and rejection to pick a best time.  Uses UDP.

netdate    John Quarterman <[e-mail]> sally.utexas.edu:pub/netdate.shar
    Polls many hosts, picks the largest group with similar times,
    and believes the first of those.  (The intervals and hosts can
    be specified on the command line for various effects.)
    Uses inetd, with TCP or UDP.


(RFC956) Sep 85    (Mills)       Algorithms for Synchronizing Network Clocks

Covers most of the issues involved.  Here is the first page:

Status of this Memo

   This RFC discussed clock synchronization algorithms for the
   ARPA-Internet community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Table of Contents

   1.      Introduction
   2.      Majority-Subset Algorithms
   3.      Clustering Algorithms
   4.      Application to Time-Synchronization Data
   5.      Summary and Conclusions
   6.      References
   Appendix
   A.      Experimental Determination of Internet Host Clock Accuracies
   A1.     UDP Time Protocol Experiment
   A2.     ICMP Timestamp Message Experiment
   A3.     Comparison of UDP and ICMP Time

List of Tables

   Table 1.  C(n,k) for n from 2 to 20
   Table 2.  Majority Subsets for n = 3,4,5
   Table 3.  Clustering Algorithm using UDP Time Protocol Data
   Table 4.  Clustering Algorithm using ICMP Timestamp Data
   Table 5.  ISI-MCON-GW Majority-Subset Algorithm
   Table 6.  ISI-MCON-GW Clustering Algorithm
   Table 7.  LL-GW (a) Majority-Subset Algorithm
   Table 8.  LL-GW (a) Clustering Algorithm
   Table 9.  LL-GW (b) Majority-Subset Algorithm
   Table 10. LL-GW (b) Clustering Algorithm
   Table A1. UDP Host Clock Offsets for Various Internet Hosts
   Table A2. UDP Offset Distribution < 9 sec
   Table A3. UDP Offset Distribution < 270 sec
   Table A4. ICMP Offset Distribution < 9 hours
   Table A5. ICMP Offset Distribution < 270 sec
   Table A6. ICMP Offset Distribution < 27 sec
   Table A7. ICMP Offset Distribution < .9 sec
   Table A8. Comparison of UDP and ICMP Host Clock Offsets


(RFC957) Sep 85    (Mills)       Experiments in Network Clock Synchronization

Similar to RFC956, but more about how you get the accurate time in the
first place, before you try to distribute it over the network.
Everything you ever wanted to know about WWV and GOES clocks.

Table of Contents

   1.      Introduction
   2.      Design of the Synchronization Algorithm
   2.1.    The Logical Clock
   2.2.    Linear Phase Adjustments
   2.3.    Nonlinear Phase Adjustments
   3.      Synchronizing Network Clocks
   3.1.    Reference Clocks and Reference Hosts
   3.2.    Distribution of Timing Information
   4.      Experimental Validation of the Design
   4.1.    Experiment Design
   4.2.    Experiment Execution
   4.3.    Discussion of Results
   4.3.1.  On Power-Grid Clocks
   4.3.2.  On Clocks Synchronized via Network Links
   4.3.3.  On the Accuracy of Radio Clocks
   4.3.3.1. The Spectracom 8170 WWVB Radio Clock
   4.3.3.2. The True Time 468-DC GOES Radio Clock
   4.3.3.3. The Heath GC-1000 WWV Radio Clock
   4.3.4.  On Handling Disruptions
   4.4.    Additional Experiments
   5.      Summary and Conclusions
   6.      References

List of Figures

   Figure 1. Clock Registers
   Figure 2. Network Configuration


(RFC958) Sep 85    (Mills)       Network Time Protocol

Not yet a standard but it probably will be.  At least one 4.2BSD implementation
is said to exist but I don't have access information for it offhand.
Quoting from the beginning of the RFC:

Status of this Memo

   This RFC suggests a proposed protocol for the ARPA-Internet
   community, and requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

Table of Contents

   1.      Introduction
   2.      Service Model
   3.      Protocol Overview
   4.      State Variables and Formats
   5.      Protocol Operation
   5.1.    Protocol Modes
   5.2.    Message Processing
   5.3.    Network Considerations
   5.4.    Leap Seconds
   6.      References
   Appendix A. UDP Header Format
   Appendix B. NTP Data Format

1.  Introduction

   This document describes the Network Time Protocol (NTP), a protocol
   for synchronizing a set of network clocks using a set of distributed
   clients and servers.  NTP is built on the User Datagram Protocol
   (UDP) [13], which provides a connectionless transport mechanism.  It
   is evolved from the Time Protocol [7] and the ICMP Timestamp message
   [6] and is a suitable replacement for both.

   NTP provides the protocol mechanisms to synchronize time in principle
   to precisions in the order of nanoseconds while preserving a
   non-ambiguous date, at least for this century.  The protocol includes
   provisions to specify the precision and estimated error of the local
   clock and the characteristics of the reference clock to which it may
   be synchronized.  However, the protocol itself specifies only the
   data representation and message formats and does not specify the
   synchronizing algorithms or filtering mechanisms.


TSP: The Time Synchronization Protocol for UNIX 4.3BSD, R. Gusella and S. Zatti

I've not been able to locate a copy of this paper.  But it's a method
of using ICMP Timestamp messages to synchronize the clocks of machines
on a local area network to a high degree of accuracy.  Time is always
monotonic on all the machines:  adjustments are done by slowing or
speeding the clocks; never by running them backwards.  Does not address
the problem of how you get the original time, but that can be dealt
with by using a radio clock or getting the original time over a network
from some machine which has one.

Volume-Number: Volume 5, Number 17