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