rfc1589.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,332 行 · 第 1/5 页

Network Working Group                                           D. Mills
Request for Comments: 1589                        University of Delaware
Category: Informational                                       March 1994


                A Kernel Model for Precision Timekeeping

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Overview

   This memorandum describes an engineering model which implements a
   precision time-of-day function for a generic operating system. The
   model is based on the principles of disciplined oscillators and
   phase-lock loops (PLL) often found in the engineering literature. It
   has been implemented in the Unix kernel for several workstations,
   including those made by Sun Microsystems and Digital Equipment. The
   model changes the way the system clock is adjusted in time and
   frequency, as well as provides mechanisms to discipline its frequency
   to an external precision timing source. The model incorporates a
   generic system-call interface for use with the Network Time Protocol
   (NTP) or similar time synchronization protocol. The NTP Version 3
   daemon xntpd operates with this model to provide synchronization
   limited in principle only by the accuracy and stability of the
   external timing source.

   This memorandum does not obsolete or update any RFC. It does not
   propose a standard protocol, specification or algorithm. It is
   intended to provoke comment, refinement and alternative
   implementations. While a working knowledge of NTP is not required for
   an understanding of the design principles or implementation of the
   model, it may be helpful in understanding how the model behaves in a
   fully functional timekeeping system. The architecture and design of
   NTP is described in [1], while the current NTP Version 3 protocol
   specification is given in RFC-1305 [2] and a subset of the protocol,
   the Simple Network Time Protocol (SNTP), in RFC-1361 [4].

   The model has been implemented in three Unix kernels for Sun
   Microsystems and Digital Equipment workstations. In addition, for the
   Digital machines the model provides improved precision to one
   microsecond (us). Since these specific implementations involve
   modifications to licensed code, they cannot be provided directly.
   Inquiries should be directed to the manufacturer's representatives.
   However, the engineering model for these implementations, including a



Mills                                                           [Page 1]

RFC 1589         Kernel Model for Precision Timekeeping       March 1994


   simulator with code segments almost identical to the implementations,
   but not involving licensed code, is available via anonymous FTP from
   host louie.udel.edu in the directory pub/ntp and compressed tar
   archive kernel.tar.Z. The NTP Version 3 distribution can be obtained
   via anonymous ftp from the same host and directory in the compressed
   tar archive xntp3.3g.tar.Z, where the version number shown as 3.3g
   may be adjusted for new versions as they occur.

1. Introduction

   This memorandum describes a model and programming interface for
   generic operating system software that manages the system clock and
   timer functions. The model provides improved accuracy and stability
   for most workstations and servers using the Network Time Protocol
   (NTP) or similar time synchronization protocol. This memorandum
   describes the principles of design and implementation of the model.
   Related technical reports discuss the design approach, engineering
   analysis and performance evaluation of the model as implemented in
   Unix kernels for Sun Microsystems and Digital Equipment workstations.
   The NTP Version 3 daemon xntpd operates with these implementations to
   provide improved accuracy and stability, together with diminished
   overhead in the operating system and network. In addition, the model
   supports the use of external timing sources, such as precision
   pulse-per-second (PPS) signals and the industry standard IRIG timing
   signals. The NTP daemon automatically detects the presence of the new
   features and utilizes them when available.

   There are three prototype implementations of the model presented in
   this memorandum, one each for the Sun Microsystems SPARCstation with
   the SunOS 4.1.x kernel, Digital Equipment DECstation 5000 with the
   Ultrix 4.x kernel and Digital Equipment 3000 AXP Alpha with the OSF/1
   V1.x kernel. In addition, for the DECstation 5000/240 and 3000 AXP
   Alpha machines, a special feature provides improved precision to 1 us
   (Sun 4.1.x kernels already do provide 1-us precision). Other than
   improving the system clock accuracy, stability and precision, these
   implementations do not change the operation of existing Unix system
   calls which manage the system clock, such as gettimeofday(),
   settimeofday() and adjtime(); however, if the new features are in
   use, the operations of gettimeofday() and adjtime() can be controlled
   instead by new system calls ntp_gettime() and ntp_adjtime() as
   described below.

   A detailed description of the variables and algorithms is given in
   the hope that similar functionality can be incorporated in Unix
   kernels for other machines. The algorithms involve only minor changes
   to the system clock and interval timer routines and include
   interfaces for application programs to learn the system clock status
   and certain statistics of the time synchronization process. Detailed



Mills                                                           [Page 2]

RFC 1589         Kernel Model for Precision Timekeeping       March 1994


   installation instructions are given in a specific README files
   included in the kernel distributions.

   In this memorandum, NTP Version 3 and the Unix implementation xntp3
   are used as an example application of the new system calls for use by
   a synchronization daemon. In principle, the new system calls can be
   used by other protocols and implementations as well. Even in cases
   where the local time is maintained by periodic exchanges of messages
   at relatively long intervals, such as using the NIST Automated
   Computer Time Service, the ability to precisely adjust the system
   clock frequency simplifies the synchronization procedures and allows
   the telephone call frequency to be considerably reduced.

2. Design Approach

   While not strictly necessary for an understanding or implementation
   of the model, it may be helpful to briefly describe how NTP operates
   to control the system clock in a client workstation. As described in
   [1], the NTP protocol exchanges timestamps with one or more peers
   sharing a synchronization subnet to calculate the time offsets
   between peer clocks and the local clock. These offsets are processed
   by several algorithms which refine and combine the offsets to produce
   an ensemble average, which is then used to adjust the local clock
   time and frequency. The manner in which the local clock is adjusted
   represents the main topic of this memorandum. The goal in the
   enterprise is the most accurate and stable system clock possible with
   the available kernel software and workstation hardware.

   In order to understand how the new software works, it is useful to
   review how most Unix kernels maintain the system time. In the Unix
   design a hardware counter interrupts the kernel at a fixed rate: 100
   Hz in the SunOS kernel, 256 Hz in the Ultrix kernel and 1024 Hz in
   the OSF/1 kernel. Since the Ultrix timer interval (reciprocal of the
   rate) does not evenly divide one second in microseconds, the Ultrix
   kernel adds 64 microseconds once each second, so the timescale
   consists of 255 advances of 3906 us plus one of 3970 us. Similarly,
   the OSF/1 kernel adds 576 us once each second, so its timescale
   consists of 1023 advances of 976 us plus one of 1552 us.

   2.1. Mechanisms to Adjust Time and Frequency

      In most Unix kernels it is possible to slew the system clock to a
      new offset relative to the current time by using the adjtime()
      system call. To do this the clock frequency is changed by adding
      or subtracting a fixed amount (tickadj) at each timer interrupt
      (tick) for a calculated number of ticks. Since this calculation
      involves dividing the requested offset by tickadj, it is possible
      to slew to a new offset with a precision only of tickadj, which is



Mills                                                           [Page 3]

RFC 1589         Kernel Model for Precision Timekeeping       March 1994


      usually in the neighborhood of 5 us, but sometimes much more. This
      results in a roundoff error which can accumulate to an
      unacceptable degree, so that special provisions must be made in
      the clock adjustment procedures of the synchronization daemon.

      In order to implement a frequency-discipline function, it is
      necessary to provide time offset adjustments to the kernel at
      regular adjustment intervals using the adjtime() system call. In
      order to reduce the system clock jitter to the regime considered
      in this memorandum, it is necessary that the adjustment interval
      be relatively small, in the neighborhood of 1 s. However, the Unix
      adjtime() implementation requires each offset adjustment to
      complete before another one can be begun, which means that large
      adjustments must be amortized in possibly many adjustment
      intervals. The requirement to implement the adjustment interval
      and compensate for roundoff error considerably complicates the
      synchronizing daemon implementation.

      In the new model this scheme is replaced by another that
      represents the system clock as a multiple-word, precision-time
      variable in order to provide very precise clock adjustments. At
      each timer interrupt a precisely calibrated quantity is added to
      the kernel time variable and overflows propagated as required. The
      quantity is computed as in the NTP local clock model described in
      [3], which operates as an adaptive-parameter, first-order, type-II
      phase-lock loop (PLL). In principle, this PLL design can provide
      precision control of the system clock oscillator within 1 us and
      frequency to within parts in 10^11. While precisions of this order
      are surely well beyond the capabilities of the CPU clock
      oscillator used in typical workstations, they are appropriate
      using precision external oscillators as described below.

      The PLL design is identical to the one originally implemented in
      NTP and described in [3]. In this design the software daemon
      simulates the PLL using the adjtime() system call; however, the
      daemon implementation is considerably complicated by the
      considerations described above. The modified kernel routines
      implement the PLL in the kernel using precision time and frequency
      representions, so that these complications are avoided. A new
      system call ntp_adjtime() is called only as each new time update
      is determined, which in NTP occurs at intervals of from 16 s to
      1024 s. In addition, doing frequency compensation in the kernel
      means that the system time runs true even if the daemon were to
      cease operation or the network paths to the primary
      synchronization source fail.

      In the new model the new ntp_adjtime() operates in a way similar
      to the original adjtime() system call, but does so independently



Mills                                                           [Page 4]

RFC 1589         Kernel Model for Precision Timekeeping       March 1994


      of adjtime(), which continues to operate in its traditional
      fashion. When used with NTP, it is the design intent that
      settimeofday() or adjtime() be used only for system time
      adjustments greater than +-128 ms, although the dynamic range of
      the new model is much larger at +-512 ms. It has been the Internet
      experience that the need to change the system time in increments
      greater than +-128 ms is extremely rare and is usually associated
      with a hardware or software malfunction or system reboot.

      The easiest way to set the time is with the settimeofday() system
      call; however, this can under some conditions cause the clock to
      jump backward. If this cannot be tolerated, adjtime() can be used
      to slew the clock to the new value without running backward or
      affecting the frequency discipline process. Once the system clock
      has been set within +-128 ms, the ntp_adjtime() system call is
      used to provide periodic updates including the time offset,
      maximum error, estimated error and PLL time constant. With NTP the
      update interval depends on the measured dispersion and time
      constant; however, the scheme is quite forgiving and neither
      moderate loss of updates nor variations in the update interval are
      serious.

   2.2 Daemon and Application Interface

      Unix application programs can read the system clock using the
      gettimeofday() system call, which returns only the system time and
      timezone data. For some applications it is useful to know the
      maximum error of the reported time due to all causes, including
      clock reading errors, oscillator frequency errors and accumulated
      latencies on the path to a primary synchronization source.
      However, in the new model the PLL adjusts the system clock to
      compensate for its intrinsic frequency error, so that the time
      errors expected in normal operation will usually be much less than
      the maximum error. The programming interface includes a new system
      call ntp_gettime(), which returns the system time, as well as the
      maximum error and estimated error. This interface is intended to
      support applications that need such things, including distributed