RFC 2783 (rfc2783) - Page 3 of 31


Pulse-Per-Second API for UNIX-like Operating Systems, Version 1



Alternative Format: Original Text Document



RFC 2783                  Pulse-Per-Second API                March 2000


   One convenient means to provide a PPS signal to a computer system is
   to connect that signal to a modem-control pin on a serial-line
   interface to the computer.  The Data Carrier Detect (DCD) pin is
   frequently used for this purpose.  Typically, the time-code output of
   the time source is transmitted to the computer over the same serial
   line.  The computer detects a signal transition on the DCD pin,
   usually by receiving an interrupt, and records a timestamp as soon as
   possible.

   Although existing practice has focussed on the use of serial lines
   and DCD transitions, PPS signals might also be delivered by other
   kinds of devices.  The API specified in this document does not
   require the use of a serial line, although it may be somewhat biased
   in that direction.

   The typical use of this facility is for the operating system to
   record ("capture") a high-resolution timestamp as soon as possible
   after it detects a PPS signal transition (usually indicated by an
   interrupt).  This timestamp can then be made available, with less
   stringent delay constraints, to time-related software.  The software
   can compare the captured timestamp to the received time-code to
   accurately discover the offset between the system clock and the
   precise time source.

   The operating system may also deliver the PPS event to a kernel
   procedure, called the "in-kernel PPS consumer."  One example would be
   the "hardpps()" procedure, described in RFC 1589, which is used to
   discipline the kernel's internal timebase.

   The API specified in this document allows for one or more signal
   sources attached to a computer system to provide PPS inputs, at the
   option of user-level software.  User-level software may obtain
   signal-transition timestamps for any of these PPS sources.  User-
   level software may optionally specify at most one of these PPS
   sources to be used to discipline the system's internal timebase.

   Although the primary purpose of this API is for capturing true
   pulse-per-second events, the API may also be used for accurately
   timestamping events of other periods, or even aperiodic events, when
   these can be expressed as signal transitions.

   This document does not define internal details of how the API must be
   implemented, and does not specify constraints on the accuracy,
   resolution, or latency of the PPS feature.  However, the utility of
   this feature is inversely proportional to the delay (and variance of
   delay), and implementors are encouraged to take this seriously.





Mogul, et al.                Informational