Annotation of embedaddon/ntp/html/drivers/driver22.html, revision 1.1.1.1
1.1 misho 1: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2:
3: <html>
4:
5: <head>
6: <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
7: <meta name="generator" content="HTML Tidy, see www.w3.org">
8: <title>PPS Clock Discipline</title>
9: <link href="scripts/style.css" type="text/css" rel="stylesheet">
10: </head>
11:
12: <body>
13:
14: <h3>PPS Clock Discipline</h3>
15: <hr>
16:
17: <p>Last change:
18:
19: <!-- #BeginDate format:En2m -->22-Apr-2009 15:02<!-- #EndDate -->
20: UTC</p>
21:
22: <h4>Synopsis</h4>
23:
24: <p>Address: 127.127.22.<i>u</i><br>
25: Reference ID: <tt>PPS</tt><br>
26: Driver ID: <tt>PPS</tt><br>
27: Serial or Parallel Port: <tt>/dev/pps<i>u</i></tt><br>
28: Requires: PPSAPI signal interface for PPS signal processing.</p>
29:
30: <p>Note: This driver supersedes an older one of the same name. The older driver operated with several somewhat archaic signal interface devices, required intricate configuration and was poorly documented. This driver requires the Pulse per Second API (PPSAPI)<sup>1</sup>. Note also that the <tt>pps</tt> configuration command has been obsoleted by this driver.</p>
31:
32: <h4>Description</h4>
33:
34: <p>This driver furnishes an interface for the pulse-per-second (PPS) signal produced by a cesium clock, radio clock or related devices. It can be used to augment the serial timecode generated by a GPS receiver, for example. It can be used to remove accumulated jitter and re-time a secondary server when synchronized to a primary server over a congested, wide-area network and before redistributing the time to local clients. The driver includes extensive signal sanity checks and grooming algorithms. A range gate and frequency discriminator reject noise and signals with incorrect frequency. A multiple-stage median filter rejects jitter due to hardware interrupt and operating system latencies. A trimmed-mean algorithm determines the best time samples. With typical workstations and processing loads, the incidental jitter can be reduced to a few microseconds.</p>
35:
36: <p>While this driver can discipline the time and frequency relative to the PPS source, it cannot number the seconds. For this purpose an auxiliary source is required, ordinarily a radio clock operated as a primary reference (stratum 1) source; however, another NTP time server can be used as well. For this purpose, the auxiliary source should be specified as the prefer peer, as described in the <a href="../prefer.html">Mitigation Rules and the <tt>prefer</tt> Keyword</a> page.</p>
37: <p>The driver requires the PPSAPI interface<sup>1</sup>, which is a proposed IETF standard. The interface consists of the <tt>timepps.h</tt> header file and associated kernel support. Support for this interface is included in current versions of Solaris, FreeBSD and Linux and proprietary versions of Tru64 (Alpha) and SunOS. See the <a href="../pps.html">Pulse-per-second (PPS) Signal Interfacing</a> page for further information.</p>
38: <p>The PPS source can be connected via a serial or parallel port, depending on the hardware and operating system. A serial port can be dedicated to the PPS source or shared with another device; however, if dedicated the data leads should not be connected, as noise or unexpected signals can cause <tt>ntpd</tt> to exit.</p>
39: <p>A radio clock is usually connected via a serial port and the PPS source
40: connected via a level converter to the data carrier detect (DCD)
41: pin (DB-9 pin 1, DB-25 pin 8) of the same connector. In some systems
42: where a parallel port and driver are available, the PPS signal can
43: be connected directly to the ACK pin (DB25 pin 10) of the connector.
44: Whether the PPS signal is connected via a dedicated port or shared with another
45: device, the driver opens the device <tt>/dev/pps%d</tt>,
46: where <tt>%d</tt> is the unit number. As with other drivers, links can be
47: used to redirect the logical name to the actual physical device.</p>
48: <p>The driver normally operates like any other driver and uses the same mitigation
49: algorithms and PLL/FLL clock discipline incorporated in the daemon.
50: If kernel PLL/FLL support is available, the kernel PLL/FLL clock
51: discipline can be used instead. The default behavior is not to use
52: the kernel PPS clock discipline, even if present. This driver incorporates
53: a good deal of signal processing to reduce jitter using the median
54: filter algorithm in the driver. As the result, performance
55: with <tt>minpoll</tt> configured at 4 (16s) is generally
56: better than the kernel PPS discipline. However, fudge flag 3 can
57: be used to enable the kernel PPS discipline if necessary.</p>
58: <p>This driver
59: is enabled only under one of two conditions (a) a prefer peer other than
60: this driver is among the survivors of the mitigation algorithms or (b)
61: there are no survivors and the <tt>minsane</tt> option
62: of the <tt>tos</tt> command is 0. The prefer peer designates another source
63: that can reliably number the seconds when available . However, if no
64: sources are available, the system clock continues to be disciplined by
65: the PPS driver on an indefinite basis.</p>
66: <p>A scenario where the latter behavior can be most useful is a planetary orbiter
67: fleet, for instance in the vicinity of Mars, where contact between orbiters
68: and Earth only one or two times per Sol (Mars day). These orbiters have a
69: precise timing reference based on an Ultra Stable Oscillator (USO) with accuracy
70: in the order of a Cesium oscillator. A PPS signal is derived from the USO
71: and can be disciplined from Earth on rare occasion or from another orbiter
72: via NTP. In the above scenario the PPS signal disciplines the spacecraft clock
73: between NTP updates.</p>
74: <p>In a similar scenario a PPS signal can be used to discipline the clock between
75: updates produced by the modem driver. This would provide precise synchronization
76: without needing the Internet at all.</p>
77: <h4>Fudge Factors</h4>
78: <dl>
79: <dt><tt>time1 <i>time</i></tt>
80: <dd>Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
81: <dt><tt>time2 <i>time</i></tt>
82: <dd>Not used by this driver.
83: <dt><tt>stratum <i>number</i></tt>
84: <dd>Specifies the driver stratum, in decimal from 0 to 15, with default 0.
85: <dt><tt>refid <i>string</i></tt>
86: <dd>Specifies the driver reference identifier, an ASCII string from one to four characters, with default <tt>PPS</tt>.
87: <dt><tt>flag1 0 | 1</tt>
88: <dd>Not used by this driver.
89: <dt><tt>flag2 0 | 1</tt>
90: <dd>Specifies PPS capture on the rising (assert) pulse edge if 0; falling
91: (clear) edge if 1. (default),
92: 1 for clear.
93: <dt><tt>flag3 0 | 1</tt>
94: <dd>Controls the kernel PPS discipline: 0 for disable (default), 1 for enable.
95: <dt><tt>flag4 0 | 1</tt>
96: <dd>Record a timestamp once for each second if 1. Useful for constructing
97: Allan deviation plots..
98: </dl>
99: <h4>Additional Information</h4>
100: <p><a href="../refclock.html">Reference Clock Drivers</a></p>
101: <p>Reference</p>
102: <ol>
103: <li>Mogul, J., D. Mills, J. Brittenson, J. Stone and U. Windl. Pulse-per-second API for Unix-like operating systems, version 1. Request for Comments RFC-2783, Internet Engineering Task Force, March 2000, 31 pp.
104: </ol>
105: <hr>
106: <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
107: </body>
108:
109: </html>
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to driver22.html CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / ntp / html / drivers