summaryrefslogtreecommitdiffstats
path: root/contrib/ntp/html
diff options
context:
space:
mode:
authorroberto <roberto@FreeBSD.org>2002-11-04 19:36:11 +0000
committerroberto <roberto@FreeBSD.org>2002-11-04 19:36:11 +0000
commita85d9ae25e8e8696677bc30feb6eaf7fc150e529 (patch)
tree5071c8dbfd7605eec15909cabca2296957573ac7 /contrib/ntp/html
parent8d541346f2b91896a9ef53cafe2b81898978ccf3 (diff)
downloadFreeBSD-src-a85d9ae25e8e8696677bc30feb6eaf7fc150e529.zip
FreeBSD-src-a85d9ae25e8e8696677bc30feb6eaf7fc150e529.tar.gz
Virgin import of ntpd 4.1.1b
Diffstat (limited to 'contrib/ntp/html')
-rw-r--r--contrib/ntp/html/driver42.htm41
-rw-r--r--contrib/ntp/html/driver43.htm109
-rwxr-xr-xcontrib/ntp/html/driver44.htm131
-rw-r--r--contrib/ntp/html/refclock.htm430
4 files changed, 470 insertions, 241 deletions
diff --git a/contrib/ntp/html/driver42.htm b/contrib/ntp/html/driver42.htm
new file mode 100644
index 0000000..655ff14
--- /dev/null
+++ b/contrib/ntp/html/driver42.htm
@@ -0,0 +1,41 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<html>
+<head>
+<meta name="generator" content=
+"HTML Tidy for Solaris (vers 1st May 2002), see www.w3.org">
+<meta http-equiv="Content-Type" content=
+"text/html; charset=iso-8859-1">
+<meta name="GENERATOR" content=
+"Mozilla/4.01 [en] (Win95; I) [Netscape]">
+<title>Zyfer GPStarplus Receiver</title>
+</head>
+<body>
+<h3>Zyfer GPStarplus Receiver</h3>
+
+<hr>
+<h4>Synopsis</h4>
+
+Address: 127.127.42.<i>u</i> <br>
+Reference ID: <tt>GPS</tt> <br>
+Driver ID: <tt>Zyfer GPStarplus</tt> <br>
+Serial Port: <tt>/dev/zyfer<i>u</i></tt>; 9600 baud, 8-bits, no
+parity <br>
+Features: <tt>(none)</tt>
+<h4>Description</h4>
+
+This driver supports the <a href="http://www.zyfer.com/">Zyfer
+GPStarplus</a> receiver.
+<p>The receiver has a DB15 port on the back which has input TxD and
+RxD lines for configuration and control, and a separate TxD line
+for the once-per-second timestamp.</p>
+
+<p>Additionally, there are BNC connectors on the back for things
+like PPS and IRIG output. Additional Information</p>
+
+<p><a href="refclock.htm">Reference Clock Drivers</a>&nbsp;</p>
+
+<hr>
+<address>Harlan Stenn (stenn@whimsy.udel.edu)</address>
+</body>
+</html>
+
diff --git a/contrib/ntp/html/driver43.htm b/contrib/ntp/html/driver43.htm
new file mode 100644
index 0000000..fc994ef
--- /dev/null
+++ b/contrib/ntp/html/driver43.htm
@@ -0,0 +1,109 @@
+<html>
+<head>
+<title>RIPE NCC interface for Trimble Palisade</title>
+</head>
+<body>
+<h3>RIPE NCC interface for Trimble Palisade</h3>
+
+<hr>
+
+<img src="pic/driver43_2.jpg" alt="Trimble Acutime 2000" align="right">
+
+<h4>Synopsis</h4>
+
+Address: 127.127.43.<i>u</i> <br>
+Reference ID: <tt>RIPENCC</tt> <br>
+Driver ID: <tt>RIPENCC</tt>
+
+<h4>Description</h4>
+
+<p> This is a special driver developed to be used in conjuction with the
+RIPE NCC clock card in the RIPE NCC Test Traffic Measurements project.
+</p>
+
+<h4>Why this driver?</h4>
+
+<p>
+The reason why we created a seperated driver for an antenna for which
+already a (vendor supplied) driver exist is a design decision.
+To be more specific, the standard Trimble interface uses a 12 pin
+connector. The cable sold by Trimble to connect to this wire is a very
+thick cable. Certainly not something you wish to run for several 100
+meters through your building. And if you wanted to run it for 100 meters,
+you always would have to really run the cable, and didn't have the option
+to use existing wiring.<br>
+This is where we wanted more flexibility. We wanted to be able to use
+existing wiring in buildings. That leaded us to CAT-5(UTP) which only
+gives us 8 wires. Therefor we decided to redesing the use of the Trimble
+antenna. The Trimble supports two modes: EVENT driver and PPS mode. The
+default is to use the EVENT mode which needs all 12 wires. We only use the
+PPS timestamps for which we have enough with 8 wires. For our purposes
+this is more than fine.
+</p>
+
+More information about the project can be found on the <a href="http://www.ripe.net/test-traffic" TARGET=_new>Test Traffic Measurements</a> website.
+
+<img src="pic/driver43_1.gif" alt="RIPE NCC clock card" align="right">
+<h4> RIPE NCC clock card</h4>
+
+<p>The card is very a simple PCI card. The only feature on the bus it uses
+is the power supply. It uses this power supply to power the Trimble GPS
+antenna.</p>
+
+<p>The card basicly just is a RS422 to RS232 converter. It gets the
+Trimble's RS422 signal on a RJ45 connector and transforms that to RS232 on a
+DIN9 connector. This connector should be loopbacked on the back of the
+machine to the serial port. As said, the card doesn't do any PCI data
+transfers.</p>
+
+<p>The schematics of the interface card is available here: <a
+href="http://www.ripe.net/ripencc/mem-services/ttm/Documents/gps_interface_schematic.pdf">gps_interface_schematic.pdf</a>.
+You are free to create this card yourself as long as you give some credit
+or reference to us. Note that we don't sell these cards on a commercial
+basis, but for interested parties we do have some spares to share.<p>
+
+
+<h4>Monitor Data</h4>
+
+In the <tt>filegen clockstats</tt> file the following (example) data is
+collected:
+<pre>
+52445 41931.275 127.127.40.0 U1 20.6.2002 11:38:51 13 11
+52445 41931.395 127.127.40.0 C1 20062002 113851 6 364785 110.2 450 6.7 13 5222.374737 N 0453.268013 E 48 7 11 0 1 -14 20 0 -25
+52445 41931.465 127.127.40.0 S1 07 1 1 02 59.3 291.5 39.3
+52445 41931.485 127.127.40.0 S1 11 2 1 02 59.9 138.0 60.2
+52445 41931.525 127.127.40.0 S1 01 4 1 02 48.4 185.7 28.3
+52445 41931.555 127.127.40.0 S1 14 5 2 02 32.7 41.0 15.4
+52445 41931.585 127.127.40.0 S1 20 6 1 02 59.9 256.6 78.0
+52445 41931.615 127.127.40.0 S1 25 8 2 00 0.0 86.6 20.1
+</pre>
+This is in the form of:
+<pre>
+All output lines consist of a prefix and a message, the prefix is:
+[days since epoch] [sec.ms since start of day] [peer address]
+
+And all individual messages:
+
+*Primary UTC time packet:
+U1 [date] [time] [trackstat] [utcflags]
+
+*Comprehensive time packet:
+C1 [date] [time] [mode] [bias] [biasunc] [rate] [rateunc] [utcoff] [latitude] [longtitude] [alt] [vis sat](x8)
+
+*Tracking status packet:
+S1 [prn] [channel] [aqflag] [ephstat] [snr] [azinuth] [elevation]
+</pre>
+
+<h4>Additional Information</h4>
+
+<a href="refclock.htm">Reference Clock Drivers</a>
+
+
+<hr>
+<a href="index.htm"><img align="left" src="pic/home.gif" alt=
+"Home"></a>
+
+<address><a href="mailto:marks@ripe.net">Mark Santcroos
+&lt;marks@ripe.net&gt;</a></address>
+</body>
+</html>
diff --git a/contrib/ntp/html/driver44.htm b/contrib/ntp/html/driver44.htm
new file mode 100755
index 0000000..0d29384
--- /dev/null
+++ b/contrib/ntp/html/driver44.htm
@@ -0,0 +1,131 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+ <title>NeoClock4X</title>
+
+ <meta http-equiv="content-type"
+ content="text/html; charset=ISO-8859-15">
+</head>
+ <body>
+
+<h1>NeoClock4X - DCF77 / TDF serial line receiver<br>
+ </h1>
+
+<hr width="100%" size="2">
+<h2>Synopsis</h2>
+
+<table cellpadding="0" cellspacing="0" border="0" width="100%">
+ <tbody>
+ <tr>
+ <td valign="top">
+ <table cellpadding="2" cellspacing="0" border="0" width="100%">
+ <tbody>
+ <tr>
+ <td valign="top">Adress<br>
+ </td>
+ <td valign="top">127.127.44.u<br>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top">Reference ID<br>
+ </td>
+ <td valign="top">neol<br>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top">Driver ID<br>
+ </td>
+ <td valign="top">NEOCLK4X<br>
+ </td>
+ </tr>
+ <tr>
+ <td valign="top">Serial Port<br>
+ </td>
+ <td valign="top">/dev/neoclock4x-u<br>
+ </td>
+ </tr>
+
+ </tbody>
+ </table>
+ <br>
+ </td>
+ <td valign="top" align="right"><a href="http://www.linum.com"><img
+ src="pic/neoclock4x.gif" alt="NeoClock4X - DCF77 receiver" width="150"
+ height="195">
+ </a><br>
+ </td>
+ </tr>
+
+ </tbody>
+</table>
+
+<hr width="100%" size="2">
+<h2>Description</h2>
+ The refclock_neoclock4x driver supports the NeoClock4X receiver available
+ from <a href="http://www.linum.com">Linum Software GmbH</a>. The receiver
+ is available as a <a href="http://www.dcf77.de">DCF77</a> or TDF receiver.
+ Both receivers have the same output string. For more information about the
+ NeoClock4X receiver please visit <a
+ href="http://www.linum.com/redir/jump/id=neoclock4x&amp;action=redir">http://www.linum.com/redir/jump/id=neoclock4x&amp;action=redir</a>.
+  
+<hr width="100%" size="2">
+<h2>Fudge Factors</h2>
+
+<dl>
+ <dt> <b><a href="clockopt.htm">time1 time</a></b></dt>
+ <dd> Specifies the time offset calibration factor with the default value
+ off 0.16958333 seconds. This offset is used  to correct serial line and
+operating system delays incurred in capturing time stamps. If you want to
+fudge the time1 offset <b>ALWAYS</b> add a value off 0.16958333. This is
+neccessary to compensate to delay that is caused by transmit the timestamp
+at 2400 Baud. If you want to compensate the delay that the DCF77 or TDF radio
+signal takes to travel to your site simply add the needed millisecond delay
+to the given value. Note that the time here is given in seconds.</dd>
+ <dd>Default setting is 0.16958333 seconds.<br>
+ </dd>
+</dl>
+
+<dl>
+ <dt> <b><a href="file:///E:/ntp-4.1.1a/html/clockopt.htm">time2 time</a></b></dt>
+ <dd> Not used by this driver.</dd>
+</dl>
+
+<dl>
+ <dt> <a href="clockopt.htm"><b>flag1 0 | 1</b></a></dt>
+ <dd>When set to 1 the driver will feed ntp with timestampe even if the
+radio signal is lost. In this case an internal backup clock generates the
+timestamps. This is ok as long as the receiver is synced once since the receiver
+is able to keep time for a long period.</dd>
+ <dd>Default setting is 0 = don't synchronize to CMOS clock.<br>
+ </dd>
+ <dd><br>
+ </dd>
+ <dt> <a href="clockopt.htm"><b>flag2 0 | 1</b></a></dt>
+ <dd>You can allow the NeoClock4X driver to use the quartz clock even if
+ it is never synchronized to a radio clock. This is usally not a good idea
+ if you want preceise timestamps since the CMOS clock is maybe not adjusted
+ to a dst status change. So <b>PLEASE</b> switch this only on if you now
+what you're doing.</dd>
+ <dd>Default setting is 0 = don't synchronize to unsynchronized CMOS clock.<br>
+ </dd>
+ <dt><br>
+ </dt>
+ <dt><a href="clockopt.htm"><b>flag3 0 | 1</b></a></dt>
+ <dd> Not used by this driver.<tt><tt><tt><tt><tt><tt> </tt></tt></tt></tt></tt></tt></dd>
+ <dd><br>
+ </dd>
+ <dt> <a href="clockopt.htm"><b>flag4 0 | 1</b></a></dt>
+ <dd>It is recommended to allow extensive logging while you setup the NeoClock4X
+ receiver. If you activate flag4 every received data is logged. You should
+ turn off flag4 as soon as the clock works as expected to reduce logfile
+cluttering.</dd>
+ <dd>Default setting is 0 = don't log received data and converted utc time.<br>
+ </dd>
+</dl>
+
+<hr width="100%" size="2">Please send any comments or question to <a
+ href="mailto:neoclock4@linum.com">neoclock4x@linum.com</a>.<br>
+ <br>
+ <br>
+</body>
+</html>
diff --git a/contrib/ntp/html/refclock.htm b/contrib/ntp/html/refclock.htm
index 079baba..df4af3a 100644
--- a/contrib/ntp/html/refclock.htm
+++ b/contrib/ntp/html/refclock.htm
@@ -1,254 +1,202 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
-<meta name="generator" content="HTML Tidy, see www.w3.org">
-<title>Reference Clock Drivers</title>
+
+ <meta name="generator" content="HTML Tidy, see www.w3.org">
+ <title>Reference Clock Drivers</title>
</head>
-<body>
+ <body>
+
<h3>Reference Clock Drivers</h3>
-
-<img align="left" src="pic/stack1a.jpg" alt="gif">Master Time
-Facility at the <a href="http://www.eecis.udel.edu/~mills/lab.htm">
-UDel Internet Research Laboratory</a>: <br clear="left">
-<hr>
-<p>Support for most of the commonly available radio and modem
-reference clocks is included in the default configuration of the
-NTP daemon for Unix <tt>ntpd</tt>. Individual clocks can be
-activated by configuration file commands, specifically the <tt>
-server</tt> and <tt>fudge</tt> commands described in the <a href=
-"ntpd.htm"><tt>ntpd</tt> program manual page</a>. The following
-discussion presents Information on how to select and configure the
-device drivers in a running Unix system.</p>
-
-<p>Many radio reference clocks can be set to display local time as
-adjusted for timezone and daylight saving mode. For use with NTP
-the clock must be set for Coordinated Universal Time (UTC) only.
-Ordinarily, these adjustments are performed by the kernel, so the
-fact that the clock runs on UTC will be transparent to the
-user.</p>
-
-<p>Radio and modem clocks by convention have addresses in the form
-127.127.<i>t.u</i>, where <i>t</i> is the clock type and <i>u</i>
-is a unit number in the range 0-3 used to distinguish multiple
-instances of clocks of the same type. Most of these clocks require
-support in the form of a serial port or special bus peripheral, but
-some can work directly from the audio codec found in some
-workstations. The particular device is normally specified by adding
-a soft link <tt>/dev/device<i>u</i></tt> to the particular hardware
-device involved, where <i><tt>u</tt></i> correspond to the unit
-number above.</p>
-
-<p>Most clock drivers communicate with the reference clock using a
-serial port, usually at 9600 bps. There are several application
-program interfaces (API) used in the various Unix and NT systems,
-most of which can be detected at configuration time. Thus, it is
-important that the NTP daemon and utilities be compiled on the
-target system or clone. In some cases special features are
-available, such as timestamping in the kernel or pulse-per-second
-(PPS) interface. In most cases these features can be detected at
-configuration time as well; however, the kernel may have to be
-recompiled in order for them to work.</p>
-
-<p>The audio drivers are a special case. These include support for
-the NIST time/frequency stations WWV and WWVH, the Canadian
-time/frequency station CHU and generic IRIG signals. Currently,
-support for the Solaris and SunOS audio API is included in the
-distribution. It is left to the volunteer corps to extend this
-support to other systems. Further information on hookup, debugging
-and monitoring is given in the <a href="audio.htm">Audio
-Drivers</a> page.</p>
-
-<p>The local clock driver is also a special case. A server
-configured with this driver can operate as a primary server to
-synchronize other clients when no other external synchronization
-sources are available. If the server is connected directly or
-indirectly to the public Internet, there is some danger that it can
-adversely affect the operation of unrelated clients. Carefully read
-the <a href="driver1.htm">Undisciplined Local Clock</a> page and
-respect the stratum limit.</p>
-
-<p>The local clock driver also supports an external synchronization
-source such as a high resolution counter disciplined by a GPS
-receiver, for example. Further information is on the <a href=
-"extern.htm">External Clock Discipline and the Local Clock
-Driver</a> page.</p>
-
+ <img align="left" src="pic/stack1a.jpg" alt="gif">
+Master Time Facility at the <a
+ href="http://www.eecis.udel.edu/%7Emills/lab.htm"> UDel Internet Research
+Laboratory</a>: <br clear="left">
+
+<hr>
+<p>Support for most of the commonly available radio and modem reference clocks
+is included in the default configuration of the NTP daemon for Unix <tt>ntpd</tt>.
+Individual clocks can be activated by configuration file commands, specifically
+the <tt> server</tt> and <tt>fudge</tt> commands described in the <a
+ href="ntpd.htm"><tt>ntpd</tt> program manual page</a>. The following discussion
+presents Information on how to select and configure the device drivers in
+a running Unix system.</p>
+
+<p>Many radio reference clocks can be set to display local time as adjusted
+for timezone and daylight saving mode. For use with NTP the clock must be
+set for Coordinated Universal Time (UTC) only. Ordinarily, these adjustments
+are performed by the kernel, so the fact that the clock runs on UTC will
+be transparent to the user.</p>
+
+<p>Radio and modem clocks by convention have addresses in the form 127.127.<i>t.u</i>,
+where <i>t</i> is the clock type and <i>u</i> is a unit number in the range
+0-3 used to distinguish multiple instances of clocks of the same type. Most
+of these clocks require support in the form of a serial port or special bus
+peripheral, but some can work directly from the audio codec found in some
+workstations. The particular device is normally specified by adding a soft
+link <tt>/dev/device<i>u</i></tt> to the particular hardware device involved,
+where <i><tt>u</tt></i> correspond to the unit number above.</p>
+
+<p>Most clock drivers communicate with the reference clock using a serial
+port, usually at 9600 bps. There are several application program interfaces
+(API) used in the various Unix and NT systems, most of which can be detected
+at configuration time. Thus, it is important that the NTP daemon and utilities
+be compiled on the target system or clone. In some cases special features
+are available, such as timestamping in the kernel or pulse-per-second (PPS)
+interface. In most cases these features can be detected at configuration
+time as well; however, the kernel may have to be recompiled in order for
+them to work.</p>
+
+<p>The audio drivers are a special case. These include support for the NIST
+time/frequency stations WWV and WWVH, the Canadian time/frequency station
+CHU and generic IRIG signals. Currently, support for the Solaris and SunOS
+audio API is included in the distribution. It is left to the volunteer corps
+to extend this support to other systems. Further information on hookup, debugging
+and monitoring is given in the <a href="audio.htm">Audio Drivers</a> page.</p>
+
+<p>The local clock driver is also a special case. A server configured with
+this driver can operate as a primary server to synchronize other clients
+when no other external synchronization sources are available. If the server
+is connected directly or indirectly to the public Internet, there is some
+danger that it can adversely affect the operation of unrelated clients. Carefully
+read the <a href="driver1.htm">Undisciplined Local Clock</a> page and respect
+the stratum limit.</p>
+
+<p>The local clock driver also supports an external synchronization source
+such as a high resolution counter disciplined by a GPS receiver, for example.
+Further information is on the <a href="extern.htm">External Clock Discipline
+and the Local Clock Driver</a> page.</p>
+
<h4>Driver Calibration</h4>
-
-<p>Some drivers depending on longwave and shortwave radio services
-need to know the radio propagation time from the transmitter to the
-receiver, which can amount to some tens of milliseconds. This must
-be calculated for each specific receiver location and requires the
-geographic coordinates of both the transmitter and receiver. The
-transmitter coordinates for various radio services are given in the
-<a href="qth.htm">Stations, Frequencies and Geographic
-Coordinates</a> page. Receiver coordinates can be obtained or
-estimated from various sources. The actual calculations are beyond
-the scope of this document.</p>
-
-<p>When more than one clock driver is supported, it is often the
-case that each shows small systematic offset differences relative
-to the rest. To reduce the effects of jitter when switching from
-one driver to the another, it is useful to calibrate the drivers to
-a common ensemble offset. The <tt>enable calibrate</tt>
-configuration command in the <a href="miscopt.htm">Miscellaneous
-Options</a> page is useful for this purpose. The calibration
-function can also be enabled and disabled using the <tt>ntpdc</tt>
-program utility.</p>
-
-<p>Most clock drivers use the <tt>time1</tt> value specified in the
-<tt>fudge</tt> configuration command to provide the calibration
-correction when this cannot be provided by the clock or interface.
-When the calibration function is enabled, the <tt>time1</tt> value
-is automatically adjusted to match the offset of the remote server
-or local clock driver selected for synchronization. Ordinarily, the
-NTP selection algorithm chooses the best from among all sources,
-usually the best radio clock determined on the basis of stratum,
-synchronization distance and jitter. The calibration function
-adjusts the <tt>time1</tt> values for all clock drivers except this
-source so that their indicated offsets tend to zero. If the
-selected source is the kernel PPS discipline, the <tt>fudge
+
+<p>Some drivers depending on longwave and shortwave radio services need to
+know the radio propagation time from the transmitter to the receiver, which
+can amount to some tens of milliseconds. This must be calculated for each
+specific receiver location and requires the geographic coordinates of both
+the transmitter and receiver. The transmitter coordinates for various radio
+services are given in the <a href="qth.htm">Stations, Frequencies and Geographic
+Coordinates</a> page. Receiver coordinates can be obtained or estimated from
+various sources. The actual calculations are beyond the scope of this document.</p>
+
+<p>When more than one clock driver is supported, it is often the case that
+each shows small systematic offset differences relative to the rest. To reduce
+the effects of jitter when switching from one driver to the another, it is
+useful to calibrate the drivers to a common ensemble offset. The <tt>enable
+calibrate</tt> configuration command in the <a href="miscopt.htm">Miscellaneous
+Options</a> page is useful for this purpose. The calibration function can
+also be enabled and disabled using the <tt>ntpdc</tt> program utility.</p>
+
+<p>Most clock drivers use the <tt>time1</tt> value specified in the <tt>fudge</tt>
+configuration command to provide the calibration correction when this cannot
+be provided by the clock or interface. When the calibration function is enabled,
+the <tt>time1</tt> value is automatically adjusted to match the offset of
+the remote server or local clock driver selected for synchronization. Ordinarily,
+the NTP selection algorithm chooses the best from among all sources, usually
+the best radio clock determined on the basis of stratum, synchronization
+distance and jitter. The calibration function adjusts the <tt>time1</tt>
+values for all clock drivers except this source so that their indicated offsets
+tend to zero. If the selected source is the kernel PPS discipline, the <tt>fudge
time1</tt> values for all clock drivers are adjusted.</p>
-
-<p>The adjustment function is an exponential average designed to
-improve accuracy, so the function takes some time to converge. The
-recommended procedure is to enable the function, let it run for an
-hour or so, then edit the configuration file using the <tt>
-time1</tt> values displayed by the <tt>ntpq</tt> utility and <tt>
-clockvar</tt> command. Finally, disable the calibration function to
-avoid possible future disruptions due to misbehaving clocks or
-drivers.</p>
-
+
+<p>The adjustment function is an exponential average designed to improve
+accuracy, so the function takes some time to converge. The recommended procedure
+is to enable the function, let it run for an hour or so, then edit the configuration
+file using the <tt> time1</tt> values displayed by the <tt>ntpq</tt> utility
+and <tt> clockvar</tt> command. Finally, disable the calibration function
+to avoid possible future disruptions due to misbehaving clocks or drivers.</p>
+
<h4>Performance Enhancements</h4>
-
-<p>In general, performance can be improved, especially when more
-than one clock driver is supported, to use the prefer peer function
-described in the <a href="prefer.htm">Mitigation Rules and the <tt>
-prefer</tt> Keyword</a> page. The prefer peer is ordinarily
-designated the remote peer or local clock driver which provides the
-best quality time. All other things equal, only the prefer peer
-source is used to discipline the system clock and jitter-producing
-"clockhopping" between sources is avoided. This is valuable when
-more than one clock driver is present and especially valuable when
-the PPS clock driver (type 22) is used. Support for PPS signals is
-summarized in the <a href="pps.htm">Pulse-per-second (PPS) Signal
-Interfacing</a> page.</p>
-
-<p>Where the highest performance is required, generally better than
-one millisecond, additional hardware and/or software functions may
-be required. Kernel modifications for precision time are described
-in the <a href="kern.htm">A Kernel Model for Precision
-Timekeeping</a> page. Special line discipline and streams modules
+
+<p>In general, performance can be improved, especially when more than one
+clock driver is supported, to use the prefer peer function described in the
+<a href="prefer.htm">Mitigation Rules and the <tt> prefer</tt> Keyword</a>
+page. The prefer peer is ordinarily designated the remote peer or local clock
+driver which provides the best quality time. All other things equal, only
+the prefer peer source is used to discipline the system clock and jitter-producing
+"clockhopping" between sources is avoided. This is valuable when more than
+one clock driver is present and especially valuable when the PPS clock driver
+(type 22) is used. Support for PPS signals is summarized in the <a
+ href="pps.htm">Pulse-per-second (PPS) Signal Interfacing</a> page.</p>
+
+<p>Where the highest performance is required, generally better than one millisecond,
+additional hardware and/or software functions may be required. Kernel modifications
+for precision time are described in the <a href="kern.htm">A Kernel Model
+for Precision Timekeeping</a> page. Special line discipline and streams modules
for use in capturing precision timestamps are described in the <a
-href="ldisc.htm">Line Disciplines and Streams Drivers</a> page.</p>
-
+ href="ldisc.htm">Line Disciplines and Streams Drivers</a> page.</p>
+
<h4>Comprehensive List of Clock Drivers</h4>
-
-<p>Following is a list showing the type and title of each driver
-currently implemented. The compile-time identifier for each is
-shown in parentheses. Click on a selected type for specific
-description and configuration documentation, including the clock
-address, reference ID, driver ID, device name and serial line
-speed, and features (line disciplines, etc.). For those drivers
-without specific documentation, please contact the author listed in
-the <a href="copyright.htm">Copyright Notice</a> page.</p>
-
-<p><a href="driver1.htm">Type 1</a> Undisciplined Local Clock
-(<tt>LOCAL</tt>)<br>
-<a href="driver2.htm">Type 2</a> Trak 8820 GPS Receiver
-(<tt>GPS_TRAK</tt>)<br>
-<a href="driver3.htm">Type 3</a> PSTI/Traconex 1020 WWV/WWVH
-Receiver (<tt>WWV_PST</tt>)<br>
-<a href="driver4.htm">Type 4</a> Spectracom WWVB and GPS Receivers
-(<tt>WWVB_SPEC</tt>)<br>
-<a href="driver5.htm">Type 5</a> TrueTime GPS/GOES/OMEGA Receivers
-(<tt>TRUETIME</tt>)<br>
-<a href="driver6.htm">Type 6</a> IRIG Audio Decoder
-(<tt>IRIG_AUDIO</tt>)<br>
-<a href="driver7.htm">Type 7</a> Radio CHU Audio
-Demodulator/Decoder (<tt>CHU</tt>)<br>
-<a href="driver8.htm">Type 8</a> Generic Reference Driver
-(<tt>PARSE</tt>)<br>
-<a href="driver9.htm">Type 9</a> Magnavox MX4200 GPS Receiver
-(<tt>GPS_MX4200</tt>)<br>
-<a href="driver10.htm">Type 10</a> Austron 2200A/2201A GPS
-Receivers (<tt>GPS_AS2201</tt>)<br>
-<a href="driver11.htm">Type 11</a> Arbiter 1088A/B GPS Receiver
-(<tt>GPS_ARBITER</tt>)<br>
-<a href="driver12.htm">Type 12</a> KSI/Odetics TPRO/S IRIG
-Interface (<tt>IRIG_TPRO</tt>)<br>
-Type 13 Leitch CSD 5300 Master Clock Controller
-(<tt>ATOM_LEITCH</tt>)<br>
-Type 14 EES M201 MSF Receiver (<tt>MSF_EES</tt>)<br>
-<a href="driver5.htm">Type 15</a> * TrueTime generic receivers<br>
-<a href="driver16">Type 16</a> Bancomm GPS/IRIG Receiver
-(<tt>GPS_BANCOMM</tt>)<br>
-Type 17 Datum Precision Time System (<tt>GPS_DATUM</tt>)<br>
-<a href="driver18.htm">Type 18</a> NIST Modem Time Service
-(<tt>ACTS_NIST</tt>)<br>
-<a href="driver19.htm">Type 19</a> Heath WWV/WWVH Receiver
-(<tt>WWV_HEATH</tt>)<br>
-<a href="driver20.htm">Type 20</a> Generic NMEA GPS Receiver
-(<tt>NMEA</tt>)<br>
-Type 21 TrueTime GPS-VME Interface (<tt>GPS_VME</tt>)<br>
-<a href="driver22.htm">Type 22</a> PPS Clock Discipline
-(<tt>PPS</tt>)<br>
-<a href="driver23.htm">Type 23</a> PTB Modem Time Service
-(<tt>ACTS_PTB</tt>)<br>
-<a href="driver24.htm">Type 24</a> USNO Modem Time Service
-(<tt>ACTS_USNO</tt>)<br>
-<a href="driver5.htm">Type 25</a> * TrueTime generic receivers<br>
-<a href="driver26.htm">Type 26</a> Hewlett Packard 58503A GPS
-Receiver (<tt>GPS_HP</tt>)<br>
-<a href="driver27.htm">Type 27</a> Arcron MSF Receiver
-(<tt>MSF_ARCRON</tt>)<br>
-<a href="driver28.htm">Type 28</a> Shared Memory Driver
-(<tt>SHM</tt>)<br>
-<a href="driver29.htm">Type 29</a> Trimble Navigation Palisade GPS
-(<tt>GPS_PALISADE</tt>)<br>
-<a href="driver30.htm">Type 30</a> Motorola UT Oncore GPS
-(<tt>GPS_ONCORE</tt>)<br>
-Type 31 Rockwell Jupiter GPS (<tt>GPS_JUPITER</tt>)<br>
-<a href="driver32.htm">Type 32</a> Chrono-log K-series WWVB
-receiver (<tt>CHRONOLOG</tt>)<br>
-<a href="driver33.htm">Type 33</a> Dumb Clock (<tt>DUMBCLOCK</tt>)<br>
-<a href="driver34.htm">Type 34</a> Ultralink WWVB Receivers (<tt>ULINK</tt>)<br>
-<a href="driver35.htm">Type 35</a> Conrad Parallel Port Radio Clock
-(<tt>PCF</tt>)<br>
-<a href="driver36.htm">Type 36</a> Radio WWV/H Audio
-Demodulator/Decoder (<tt>WWV</tt>)<br>
-<a href="driver37.htm">Type 37</a> Forum Graphic GPS Dating station
-(<tt>FG</tt>)<br>
-<a href="driver38.htm">Type 38</a> hopf GPS/DCF77 6021/komp for
-Serial Line (<tt>HOPF_S</tt>)<br>
-<a href="driver39.htm">Type 39</a> hopf GPS/DCF77 6039 for PCI-Bus
-(<tt>HOPF_P</tt>)<br>
-<a href="driver40.htm">Type 40</a> JJY Receivers (<tt>JJY</tt>)<br>
-</p>
-
-
-<p>* All TrueTime receivers are now supported by one driver, type
-5. Types 15 and 25 will be retained only for a limited time and may
-be reassigned in future.</p>
-
+
+<p>Following is a list showing the type and title of each driver currently
+implemented. The compile-time identifier for each is shown in parentheses.
+Click on a selected type for specific description and configuration documentation,
+including the clock address, reference ID, driver ID, device name and serial
+line speed, and features (line disciplines, etc.). For those drivers without
+specific documentation, please contact the author listed in the <a
+ href="copyright.htm">Copyright Notice</a> page.</p>
+
+<p><a href="driver1.htm">Type 1</a> Undisciplined Local Clock (<tt>LOCAL</tt>)<br>
+ <a href="driver2.htm">Type 2</a> Trak 8820 GPS Receiver (<tt>GPS_TRAK</tt>)<br>
+ <a href="driver3.htm">Type 3</a> PSTI/Traconex 1020 WWV/WWVH Receiver (<tt>WWV_PST</tt>)<br>
+ <a href="driver4.htm">Type 4</a> Spectracom WWVB and GPS Receivers (<tt>WWVB_SPEC</tt>)<br>
+ <a href="driver5.htm">Type 5</a> TrueTime GPS/GOES/OMEGA Receivers (<tt>TRUETIME</tt>)<br>
+ <a href="driver6.htm">Type 6</a> IRIG Audio Decoder (<tt>IRIG_AUDIO</tt>)<br>
+ <a href="driver7.htm">Type 7</a> Radio CHU Audio Demodulator/Decoder (<tt>CHU</tt>)<br>
+ <a href="driver8.htm">Type 8</a> Generic Reference Driver (<tt>PARSE</tt>)<br>
+ <a href="driver9.htm">Type 9</a> Magnavox MX4200 GPS Receiver (<tt>GPS_MX4200</tt>)<br>
+ <a href="driver10.htm">Type 10</a> Austron 2200A/2201A GPS Receivers (<tt>GPS_AS2201</tt>)<br>
+ <a href="driver11.htm">Type 11</a> Arbiter 1088A/B GPS Receiver (<tt>GPS_ARBITER</tt>)<br>
+ <a href="driver12.htm">Type 12</a> KSI/Odetics TPRO/S IRIG Interface (<tt>IRIG_TPRO</tt>)<br>
+ Type 13 Leitch CSD 5300 Master Clock Controller (<tt>ATOM_LEITCH</tt>)<br>
+ Type 14 EES M201 MSF Receiver (<tt>MSF_EES</tt>)<br>
+ <a href="driver5.htm">Type 15</a> * TrueTime generic receivers<br>
+ <a href="driver16">Type 16</a> Bancomm GPS/IRIG Receiver (<tt>GPS_BANCOMM</tt>)<br>
+ Type 17 Datum Precision Time System (<tt>GPS_DATUM</tt>)<br>
+ <a href="driver18.htm">Type 18</a> NIST Modem Time Service (<tt>ACTS_NIST</tt>)<br>
+ <a href="driver19.htm">Type 19</a> Heath WWV/WWVH Receiver (<tt>WWV_HEATH</tt>)<br>
+ <a href="driver20.htm">Type 20</a> Generic NMEA GPS Receiver (<tt>NMEA</tt>)<br>
+ Type 21 TrueTime GPS-VME Interface (<tt>GPS_VME</tt>)<br>
+ <a href="driver22.htm">Type 22</a> PPS Clock Discipline (<tt>PPS</tt>)<br>
+ <a href="driver23.htm">Type 23</a> PTB Modem Time Service (<tt>ACTS_PTB</tt>)<br>
+ <a href="driver24.htm">Type 24</a> USNO Modem Time Service (<tt>ACTS_USNO</tt>)<br>
+ <a href="driver5.htm">Type 25</a> * TrueTime generic receivers<br>
+ <a href="driver26.htm">Type 26</a> Hewlett Packard 58503A GPS Receiver (<tt>GPS_HP</tt>)<br>
+ <a href="driver27.htm">Type 27</a> Arcron MSF Receiver (<tt>MSF_ARCRON</tt>)<br>
+ <a href="driver28.htm">Type 28</a> Shared Memory Driver (<tt>SHM</tt>)<br>
+ <a href="driver29.htm">Type 29</a> Trimble Navigation Palisade GPS (<tt>GPS_PALISADE</tt>)<br>
+ <a href="driver30.htm">Type 30</a> Motorola UT Oncore GPS (<tt>GPS_ONCORE</tt>)<br>
+ Type 31 Rockwell Jupiter GPS (<tt>GPS_JUPITER</tt>)<br>
+ <a href="driver32.htm">Type 32</a> Chrono-log K-series WWVB receiver (<tt>CHRONOLOG</tt>)<br>
+ <a href="driver33.htm">Type 33</a> Dumb Clock (<tt>DUMBCLOCK</tt>)<br>
+ <a href="driver34.htm">Type 34</a> Ultralink WWVB Receivers (<tt>ULINK</tt>)<br>
+ <a href="driver35.htm">Type 35</a> Conrad Parallel Port Radio Clock (<tt>PCF</tt>)<br>
+ <a href="driver36.htm">Type 36</a> Radio WWV/H Audio Demodulator/Decoder
+(<tt>WWV</tt>)<br>
+ <a href="driver37.htm">Type 37</a> Forum Graphic GPS Dating station (<tt>FG</tt>)<br>
+ <a href="driver38.htm">Type 38</a> hopf GPS/DCF77 6021/komp for Serial Line
+(<tt>HOPF_S</tt>)<br>
+ <a href="driver39.htm">Type 39</a> hopf GPS/DCF77 6039 for PCI-Bus (<tt>HOPF_P</tt>)<br>
+ <a href="driver40.htm">Type 40</a> JJY Receivers (<tt>JJY</tt>)<br>
+<a href="driver44.htm">Type 44</a> NeoClock4X DCF77 / TDF receiver<br>
+ </p>
+
+<p>* All TrueTime receivers are now supported by one driver, type 5. Types
+15 and 25 will be retained only for a limited time and may be reassigned
+in future.</p>
+
<p>Additional Information</p>
-
-<p><a href="prefer.htm">Mitigation Rules and the <tt>prefer</tt>
-Keyword</a><br>
-<a href="rdebug.htm">Debugging Hints for Reference Clock
-Drivers</a><br>
-<a href="kern.htm">A Kernel Model for Precision Timekeeping</a><br>
-<a href="ldisc.htm">Line Disciplines and Streams Drivers</a><br>
-<a href="audio.htm">Reference Clock Audio Drivers</a><br>
-<a href="pps.htm">Pulse-per-second (PPS) Signal Interfacing</a><br>
-<a href="howto.htm">How To Write a Reference Clock Driver</a></p>
-
-<hr>
-<a href="index.htm"><img align="left" src="pic/home.gif" alt=
-"gif"></a>
-
-<address><a href="mailto:mills@udel.edu">David L. Mills
-&lt;mills@udel.edu&gt;</a></address>
+
+<p><a href="prefer.htm">Mitigation Rules and the <tt>prefer</tt> Keyword</a><br>
+ <a href="rdebug.htm">Debugging Hints for Reference Clock Drivers</a><br>
+ <a href="kern.htm">A Kernel Model for Precision Timekeeping</a><br>
+ <a href="ldisc.htm">Line Disciplines and Streams Drivers</a><br>
+ <a href="audio.htm">Reference Clock Audio Drivers</a><br>
+ <a href="pps.htm">Pulse-per-second (PPS) Signal Interfacing</a><br>
+ <a href="howto.htm">How To Write a Reference Clock Driver</a></p>
+
+<hr> <a href="index.htm"><img align="left" src="pic/home.gif" alt="gif">
+</a>
+<address><a href="mailto:mills@udel.edu">David L. Mills &lt;mills@udel.edu&gt;</a></address>
+ <br>
</body>
</html>
-
OpenPOWER on IntegriCloud