rfc1589.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,332 行 · 第 1/5 页

      file systems, multimedia teleconferencing and other real-time
      applications. The programming interface also includes the new
      system call ntp_adjtime() mentioned previously, which can be used
      to read and write kernel variables for time and frequency
      adjustment, PLL time constant, leap-second warning and related
      data.

      In addition, the kernel adjusts the maximum error to grow by an
      amount equal to the oscillator frequency tolerance times the
      elapsed time since the last update. The default engineering
      parameters have been optimized for update intervals in the order



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


      of 64 s. For other intervals the PLL time constant can be adjusted
      to optimize the dynamic response over intervals of 16-1024 s.
      Normally, this is automatically done by NTP. In any case, if
      updates are suspended, the PLL coasts at the frequency last
      determined, which usually results in errors increasing only to a
      few tens of milliseconds over a day using room-temperature quartz
      oscillators of typical modern workstations.

      While any synchronization daemon can in principle be modified to
      use the new system calls, the most likely will be users of the NTP
      Version 3 daemon xntpd. The xntpd code determines whether the new
      system calls are implemented and automatically reconfigures as
      required. When implemented, the daemon reads the frequency offset
      from a file and provides it and the initial time constant via
      ntp_adjtime(). In subsequent calls to ntp_adjtime(), only the time
      offset and time constant are affected. The daemon reads the
      frequency from the kernel using ntp_adjtime() at intervals of
      about one hour and writes it to a system file. This information is
      recovered when the daemon is restarted after reboot, for example,
      so the sometimes extensive training period to learn the frequency
      separately for each system can be avoided.

   2.3. Precision Clocks for DECstation 5000/240 and 3000 AXP Alpha

      The stock microtime() routine in the Ultrix kernel returns system
      time to the precision of the timer interrupt interval, which is in
      the 1-4 ms range. However, in the DECstation 5000/240 and possibly
      other machines of that family, there is an undocumented IOASIC
      hardware register that counts system bus cycles at a rate of 25
      MHz. The new microtime() routine for the Ultrix kernel uses this
      register to interpolate system time between timer interrupts. This
      results in a precision of 1 us for all time values obtained via
      the gettimeofday() and ntp_gettime() system calls. For the Digital
      Equipment 3000 AXP Alpha, the architecture provides a hardware
      Process Cycle Counter and a machine instruction rpcc to read it.
      This counter operates at the fundamental frequency of the CPU
      clock or some submultiple of it, 133.333 MHz for the 3000/400 for
      example. The new microtime() routine for the OSF/1 kernel uses
      this counter in the same fashion as the Ultrix routine.

      In both the Ultrix and OSF/1 kernels the gettimeofday() and
      ntp_gettime() system call use the new microtime() routine, which
      returns the actual interpolated value, but does not change the
      kernel time variable. Therefore, other routines that access the
      kernel time variable directly and do not call either
      gettimeofday(), ntp_gettime() or microtime() will continue their
      present behavior. The microtime() feature is independent of other
      features described here and is operative even if the kernel PLL or



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


      new system calls have not been implemented.

      The SunOS kernel already includes a system clock with 1-us
      resolution; so, in principle, no microtime() routine is necessary.
      An existing kernel routine uniqtime() implements this function,
      but it is coded in the C language and is rather slow at 42-85 us
      per call. A replacement microtime() routine coded in assembler
      language is available in the NTP Version 3 distribution and is
      much faster at about 3 us per call.

   2.4. External Time and Frequency Discipline

      The overall accuracy of a time synchronization subnet with respect
      to Coordinated Universal Time (UTC) depends on the accuracy and
      stability of the primary synchronization source, usually a radio
      or satellite receiver, and the system clock oscillator of the
      primary server. As discussed in [5], the traditional interface
      using an RS232 protocol and serial port precludes the full
      accuracy of the radio clock. In addition, the poor stability of
      typical CPU clock oscillators limits the accuracy, whether or not
      precision time sources are available. There are, however, several
      ways in which the system clock accuracy and stability can be
      improved to the degree limited only by the accuracy and stability
      of the synchronization source and the jitter of the operating
      system.

      Many radio clocks produce special signals that can be used by
      external equipment to precisely synchronize time and frequency.
      Most produce a pulse-per-second (PPS) signal that can be read via
      a modem-control lead of a serial port and some produce a special
      IRIG signal that can be read directly by a bus peripheral, such as
      the KSI/Odetics TPRO IRIG SBus interface, or indirectly via the
      audio codec of some workstations, as described in [5]. In the NTP
      Version 3 distribution, the PPS signal can be used to augment the
      less precise ASCII serial timecode to improve accuracy to the
      order of microseconds. Support is also included in the
      distribution for the TPRO interface as well as the audio codec;
      however, the latter requires a modified kernel audio driver
      contained in the bsd_audio.tar.Z distribution in the same host and
      directory as the NTP Version 3 distribution mentioned previously.

      2.4.1. PPS Signal

         The NTP Version 3 distribution includes a special ppsclock
         module for the SunOS 4.1.x kernel that captures the PPS signal
         presented via a modem-control lead of a serial port. Normally,
         the ppsclock module produces a timestamp at each transition of
         the PPS signal and provides it to the synchronization daemon



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


         for integration with the serial ASCII timecode, also produced
         by the radio clock. With the conventional PLL implementation in
         either the daemon or the kernel as described above, the
         accuracy of this scheme is limited by the intrinsic stability
         of the CPU clock oscillator to a millisecond or two, depending
         on environmental temperature variations.

         The ppsclock module has been modified to in addition call a new
         kernel routine hardpps() once each second. The kernel routine
         compares the timestamp with a sample of the CPU clock
         oscillator to develop a frequency offset estimate. This offset
         is used to discipline the oscillator frequency, nominally to
         within a few parts in 10^8, which is about two orders of
         magnitude better than the undisciplined oscillator. The new
         feature is conditionally compiled in the code described below
         only if the PPS_SYNC option is used in the kernel configuration
         file.

         When using the PPS signal to adjust the time, there is a
         problem with the SunOS implementation which is very delicate to
         fix. The Sun serial port interrupt routine operates at
         interrupt priority level 12, while the timer interrupt routine
         operates at priority 10. Thus, it is possible that the PPS
         signal interrupt can occur during the timer interrupt routine,
         with result that a tick increment can be missed and the
         returned time early by one tick. It may happen that, if the CPU
         clock oscillator is within a few ppm of the PPS oscillator,
         this condition can persist for two or more successive PPS
         interrupts. A useful workaround has been to use a median filter
         to process the PPS sample offsets. In this filter the sample
         offsets in a window of 20 samples are sorted by offset and the
         six highest and six lowest outlyers discarded. The average of
         the eight samples remaining becomes the output of the filter.

         The problem is not nearly so serious when using the PPS signal
         to discipline the frequency of the CPU clock oscillator. In
         this case the quantity of interest is the contents of the
         microseconds counter only, which does not depend on the kernel
         time variable.

      2.4.2. External Clocks

         It is possible to replace the system clock function with an
         external bus peripheral. The TPRO device mentioned previously
         can be used to provide IRIG-synchronized time with a precision
         of 1 us. A driver for this device tprotime.c and header file
         tpro.h are included in the kernel.tar.Z distribution mentioned
         previously. Using this device the system clock is read directly



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


         from the interface; however, the device does not record the
         year, so special provisions have to be made to obtain the year
         from the kernel time variable and initialize the driver
         accordingly. This feature is conditionally compiled in the code
         described below only if the EXT_CLOCK option is used in the
         kernel configuration file.

         While the system clock function is provided directly by the
         microtime() routine in the driver, the kernel time variable
         must be disciplined as well, since not all system timing
         functions use the microtime() routine. This is done by
         measuring the difference between the microtime() clock and
         kernel time variable and using the difference to adjust the
         kernel PLL as if the adjustment were provided by an external
         peer and NTP.

         A good deal of error checking is done in the TPRO driver, since
         the system clock is vulnerable to a misbehaving radio clock,
         IRIG signal source, interface cables and TPRO device itself.
         Unfortunately, there is no easy way to utilize the extensive
         diversity and redundancy capabilities available in the NTP
         synchronization daemon. In order to avoid disruptions that
         might occur if the TPRO time is far different from the kernel
         time variable, the latter is used instead of the former if the
         difference between the two exceeds 1000 s; presumably in that
         case operator intervention is required.

      2.4.3. External Oscillators

         Even if a source of PPS or IRIG signals is not available, it is
         still possible to improve the stability of the system clock
         through the use of a specialized bus peripheral. In order to
         explore the benefits of such an approach, a special SBus
         peripheral caled HIGHBALL has been constructed. The device
         includes a pair of 32-bit hardware counters in Unix timeval
         format, together with a precision, oven-controlled quartz
         oscillator with a stability of a few parts in 10^9. A driver
         for this device hightime.c and header file high.h are included
         in the kernel.tar.Z distribution mentioned previously. This
         feature is conditionally compiled in the code described below
         only if the EXT_CLOCK and HIGHBALL options are used in the
         kernel configuration file.

         Unlike the external clock case, where the system clock function
         is provided directly by the microtime() routine in the driver,
         the HIGHBALL counter offsets with respect to UTC must be
         provided first.  This is done using the ordinary kernel PLL,
         but controlling the counter offsets directly, rather than the



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


         kernel time variable. At first, this might seem to defeat the
         purpose of the design, since the jitter and wander of the
         synchronization source will affect the counter offsets and thus
         the accuracy of the time. However, the jitter is much reduced
         by the PLL and the wander is small, especially if using a radio
         clock or another primary server disciplined in the same way.
         In practice, the scheme works to reduce the incidental wander
         to a few parts in 10^8, or about the same as using the PPS
         signal.

         As in the previous case, the kernel time variable must be
         disciplined as well, since not all system timing functions use
         the microtime() routine. However, the kernel PLL cannot be used
         for this, since it is already in use providing offsets for the
         HIGHBALL counters. Therefore, a special correction is
         calculated from the difference between the microtime() clock
         and the kernel time variable and used to adjust the kernel time
         variable at the next timer interrupt. This somewhat roundabout
         approach is necessary in order that the adjustment does not
         cause the kernel time variable to jump backwards and possibly
         lose or duplicate a timer event.

   2.5 Other Features