rfc1589.txt

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

         as determined by measurements of Allan variance [5].

         Should the PPS signal fail, the current frequency estimate
         pps_ybar continues to be used, so the nominal frequency remains
         correct subject only to the instability of the undisciplined
         oscillator. The procedure to save and restore the frequency
         estimate works as follows. When setting the frequency from a
         file, the time_freq value is set as the file value minus the
         pps_ybar value; when retrieving the frequency, the two values
         are added before saving in the file. This scheme provides a
         seamless interface should the PPS signal fail or the kernel
         configuration change. Note that the frequency discipline is
         active whether or not the synchronization daemon is active.
         Since all Unix systems take some time after reboot to build a
         running system, usually by that time the discipline process has
         already settled down and the initial transients due to
         frequency discipline have damped out.

      3.1.4. External Clock Interface

         The external clock driver interface is implemented with two
         routines, microtime(), which returns the current clock time,
         and clock_set(), which furnishes the apparent system time
         derived from the kernel time variable. The latter routine is
         called only when the clock is set using the settimeofday()
         system call, but can be called from within the driver, such as
         when the year rolls over, for example.

         In the stock SunOS kernel and modified Ultrix and OSF/1
         kernels, the microtime() routine returns the kernel time
         variable plus an interpolation between timer interrupts based
         on the contents of a hardware counter. In the case of an
         external clock, such as described above, the system clock is
         read directly from the hardware clock registers. Examples of
         external clock drivers are in the tprotime.c and hightime.c
         routines included in the kernel.tar.Z distribution.




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


         The external clock routines return a status code which
         indicates whether the clock is operating correctly and the
         nature of the problem, if not. The return code is interpreted
         by the ntp_gettime() system call, which transitions the status
         state machine to the TIME_ERR state if an error code is
         returned. This is the only error checking implemented for the
         external clock in the present version of the code.

      The simulator has been used to check the PLL operation over the
      design envelope of +-512 ms in time error and +-100 ppm in
      frequency error. This confirms that no overflows occur and that
      the loop initially converges in about 15 minutes for timer
      interrupt rates from 50 Hz to 1024 Hz. The loop has a normal
      overshoot of a few percent and a final convergence time of several
      hours, depending on the initial time and frequency error.

   3.2. Leap Seconds

      It does not seem generally useful in the user application
      interface to provide additional details private to the kernel and
      synchronization protocol, such as stratum, reference identifier,
      reference timestamp and so forth. It would in principle be
      possible for the application to independently evaluate the quality
      of time and project into the future how long this time might be
      "valid." However, to do that properly would duplicate the
      functionality of the synchronization protocol and require
      knowledge of many mundane details of the platform architecture,
      such as the subnet configuration, reachability status and related
      variables. For the curious, the ntp_adjtime() system call can be
      used to reveal some of these mysteries.

      However, the user application may need to know whether a leap
      second is scheduled, since this might affect interval calculations
      spanning the event. A leap-warning condition is determined by the
      synchronization protocol (if remotely synchronized), by the
      timecode receiver (if available), or by the operator (if awake).
      This condition is set by the synchronization daemon on the day the
      leap second is to occur (30 June or 31 December, as announced) by
      specifying in a ntp_adjtime() system call a clock status of either
      TIME_DEL, if a second is to be deleted, or TIME_INS, if a second
      is to be inserted. Note that, on all occasions since the inception
      of the leap-second scheme, there has never been a deletion
      occasion, nor is there likely to be one in future. If the value is
      TIME_DEL, the kernel adds one second to the system time
      immediately following second 23:59:58 and resets the clock status
      to TIME_OK. If the value is TIME_INS, the kernel subtracts one
      second from the system time immediately following second 23:59:59
      and resets the clock status to TIME_OOP, in effect causing system



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


      time to repeat second 59. Immediately following the repeated
      second, the kernel resets the clock status to TIME_OK.

      Depending upon the system call implementation, the reported time
      during a leap second may repeat (with the TIME_OOP return code set
      to advertise that fact) or be monotonically adjusted until system
      time "catches up" to reported time. With the latter scheme the
      reported time will be correct before and shortly after the leap
      second (depending on the number of microtime() calls during the
      leap second), but freeze or slowly advance during the leap second
      itself. However, Most programs will probably use the ctime()
      library routine to convert from timeval (seconds, microseconds)
      format to tm format (seconds, minutes,...). If this routine is
      modified to use the ntp_gettime() system call and inspect the
      return code, it could simply report the leap second as second 60.

   3.3. Clock Status State Machine

      The various options possible with the system clock model described
      in this memorandum require a careful examination of the state
      transitions, status indications and recovery procedures should a
      crucial signal or interface fail. In this section is presented a
      prototype state machine designed to support leap second insertion
      and deletion, as well as reveal various kinds of errors in the
      synchronization process. The states of this machine are decoded as
      follows:

      TIME_OK   If an external clock is present, it is working properly
                and the system clock is derived from it. If no external
                clock is present, the synchronization daemon is working
                properly and the system clock is synchronized to a radio
                clock or one or more peers.

      TIME_INS  An insertion of one second in the system clock has been
                declared following the last second of the current day,
                but has not yet been executed.

      TIME_DEL  A deletion of the last second of the current day has
                been declared, but not yet executed.

      TIME_OOP  An insertion of one second in the system clock has been
                declared following the last second of the current day.
                The second is in progress, but not yet completed.
                Library conversion routines should interpret this second
                as 23:59:60.






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


      TIME_BAD  Either (a) the synchronization daemon has declared the
                protocol is not working properly, (b) all sources of
                outside synchronization have been lost or (c) an
                external clock is present and it has just become
                operational following a non-operational condition.

      TIME_ERR  An external clock is present, but is in a non-
                operational condition.

      In all except the TIME_ERR state the system clock is derived from
      either an external clock, if present, or the kernel time variable,
      if not. In the TIME_ERR state the external clock is present, but
      not working properly, so the system clock may be derived from the
      kernel time variable. The following diagram indicates the normal
      transitions of the state machine. Not all valid transitions are
      shown.

          +--------+     +--------+     +--------+     +--------+
          |        |     |        |     |        |     |        |
          |TIME_BAD|---->|TIME_OK |<----|TIME_OOP|<----|TIME_INS|
          |        |     |        |     |        |     |        |
          +--------+     +--------+     +--------+     +--------+
               A              A
               |              |
               |              |
          +--------+     +--------+
          |        |     |        |
          |TIME_ERR|     |TIME_DEL|
          |        |     |        |
          +--------+     +--------+

      The state machine makes a transition once each second at an
      instant where the microseconds field of the kernel time variable
      overflows and one second is added to the seconds field. However,
      this condition is checked at each timer interrupt, which may not
      exactly coincide with the actual instant of overflow. This may
      lead to some interesting anomalies, such as a status indication of
      a leap second in progress (TIME_OOP) when actually the leap second
      had already expired.

      The following state transitions are executed automatically by the
      kernel:

      any state -> TIME_ERR   This transition occurs when an external
                              clock is present and an attempt is made to
                              read it when in a non-operational
                              condition.




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


      TIME_INS -> TIME_OOP    This transition occurs immediately
                              following second 86,400 of the current day
                              when an insert-second event has been
                              declared.

      TIME_OOP -> TIME_OK     This transition occurs immediately
                              following second 86,401 of the current
                              day; that is, one second after entry to
                              the TIME_OOP state.

      TIME_DEL -> TIME_OK     This transition occurs immediately
                              following second 86,399 of the current day
                              when a delete-second event has been
                              declared.

      The following state transitions are executed by specific
      ntp_adjtime() system calls:

      TIME_OK -> TIME_INS     This transition occurs as the result of a
                              ntp_adjtime() system call to declare an
                              insert-second event.

      TIME_OK -> TIME_DEL     This transition occurs as the result of a
                              ntp_adjtime() system call to declare a
                              delete-second event.

      any state -> TIME_BAD   This transition occurs as the result of a
                              ntp_adjtime() system call to declare loss
                              of all sources of synchronization or in
                              other cases of error.

      The following table summarizes the actions just before, during and
      just after a leap-second event. Each line in the table shows the
      UTC and NTP times at the beginning of the second. The left column
      shows the behavior when no leap event is to occur. In the middle
      column the state machine is in TIME_INS at the end of UTC second
      23:59:59 and the NTP time has just reached 400. The NTP time is
      set back one second to 399 and the machine enters TIME_OOP. At the
      end of the repeated second the machine enters TIME_OK and the UTC
      and NTP times are again in correspondence. In the right column the
      state machine is in TIME_DEL at the end of UTC second 23:59:58 and
      the NTP time has just reached 399. The NTP time is incremented,
      the machine enters TIME_OK and both UTC and NTP times are again in
      correspondence.







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