std-unix@ut-sally.UUCP (Moderator, John Quarterman) (01/12/86)
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 <chris@merlin.purdue.edu> 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 <raj@UCI.EDU> 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 <jsq@sally.utexas.edu> 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