7

Unix/Linux 网络时间协议版本3 Network Time Protocol Version 3 (NTP) distribution for Unix systems

Replied: Fri, 05 Sep 1997 16:17:49 -0400
Replied: ""Ulrich Windl" <[e-mail]> "
Return-Path: [e-mail] 
Return-Path: <[e-mail]>
Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2])
	by whimsy.udel.edu (8.8.5/8.8.5) with ESMTP id HAA27016
	for <[e-mail]>; Fri, 5 Sep 1997 07:18:16 GMT
Received: from ngate.ngate.uni-regensburg.de (ngate.rz.uni-regensburg.de [132.199.3.13])
	by rrzs2.rz.uni-regensburg.de (8.8.5/8.8.5) with SMTP id JAA19789;
	Fri, 5 Sep 1997 09:18:11 +0200 (MET DST)
Received: from rkdvmks1.ngate.uni-regensburg.de by ngate.ngate.uni-regensburg.de; Fri,  5 Sep 97 08:18 MET
Received: from rkdvmks1.ngate.uni-regensburg.de by kgate.ngate.uni-regensburg.de; Fri,  5 Sep 97 07:18 GMT
Received: from RKDVMKS1/SpoolDir by rkdvmks1.ngate.uni-regensburg.de (Mercury 1.32);
    5 Sep 97 09:17:57 +0200
Received: from SpoolDir by RKDVMKS1 (Mercury 1.32); 5 Sep 97 09:17:47 +0200
From: "Ulrich Windl" <[e-mail]>
Organization: Universitaet Regensburg, Klinikum
To: [e-mail]
Date: Fri, 5 Sep 1997 09:17:41 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Subject: Some HTML patches
Cc: [e-mail]
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.53/R1)
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from Quoted-printable to 8bit by whimsy.udel.edu id HAA27016

Harlan,

I have reviewed three of the HTML files in xntp3-5.90.2. I hope I 
could improve the appearance of these files. I'm sending a copy to 
Frank Kardel, because driver8.html first mentions that flags 1 and 2 
enable filtering of timestamps, but later the document says the flags 
are unused. According to the source, the flags are stored, but not 
used. Maybe Frank can say something about it. Personally I think 
filtering would be good for some platforms (like a HP 9000/827 with a 
MUX panel that has *polled* serial ports)...

Ulrich
-------------------
Harlan,

I have worked on three HTML files in the xntp3-5.90.2 release. I
corrected a few spelling errors, added more markup (like
<code>...</code>). Even though it is allowed to leave out the "head"
and "body" elements in HTML 2, some browsers like Netscape 2 choke
badly on it. Thus I added these optional tags.

Ulrich

--- /usr/doc/packages/xntpd/driver8.html	Tue Jun 24 19:28:38 1997
+++ driver8.html	Thu Sep  4 21:34:41 1997
@@ -33,7 +33,7 @@
 
 <p>The reference clock support in xntp contains the necessary
 configuration tables for those receivers. In addition to supporting
-several different clock types and 4 devices, the generation a a
+several different clock types and 4 devices, the generation of a
 PPS signal is also provided as an configuration option. The PPS
 configuration option uses the receiver generated time stamps for
 feeding the PPS loopfilter control for much finer clock
@@ -50,40 +50,44 @@
 
 <p>Fudge factors
 
-<p>Only two fudge factors are utilized. The time1 fudge factor defines
-the phase offset of the synchronization character to the actual
-time. On the availability of PPS information the time2 fudge factor
-defines the skew between the PPS time stamp and the receiver
-timestamp of the PPS signal. This parameter is usually zero, as
-usually the PPS signal is believed in time and OS delays should be
-corrected in the machine specific section of the kernel driver.
-time2 needs only be set when the actual PPS signal is delayed for
-some reason. The flag1 enables input filtering. This a median
-filter with continuous sampling. The flag2 selects averaging of the
-samples remaining after the filtering. Leap second-handling is
-controlled with the flag3. When set a leap second will be deleted
-on receipt of a leap second indication from the receiver. Otherwise
-the leap second will be added, (which is the default).
-flag3 should never be set. PPS handling is enabled by adding 128 to
-the mode parameter in the server/peer command.
+<p>Only two fudge factors are utilized. The <code>time1</code> fudge
+factor defines the phase offset of the synchronization character to
+the actual time. On the availability of PPS information the
+<code>time2</code> fudge factor defines the skew between the PPS time
+stamp and the receiver timestamp of the PPS signal. This parameter is
+usually zero, as usually the PPS signal is believed in time and OS
+delays should be corrected in the machine specific section of the
+kernel driver.  <code>time2</code> needs only be set when the actual
+PPS signal is delayed for some reason.
+
+<p>The <code>flag1</code> enables input filtering. This a median
+filter with continuous sampling. The <code>flag2</code> selects
+averaging of the samples remaining after the filtering. Leap
+second handling is controlled with the <code>flag3</code>. When set a
+leap second will be deleted on receipt of a leap second indication
+from the receiver. Otherwise the leap second will be added, (which is
+the default).  <code>flag3</code> should never be set. PPS handling is
+enabled by adding 128 to the mode parameter in the server/peer
+command.
 
 <p>ntpq (8)
 
 <p>timecode variable
 
 <p>The ntpq program can read clock variables command list several
-variables. These hold the following information: refclock_time is
-the local time with the offset to UTC (format HHMM). The currently
-active receiver flags are listed in refclock_status. Additional
-feature flags of the receiver are optionally listed in parentheses.
-The actual time code is listed in timecode. A qualification of the
-decoded time code format is following in refclock_format. The last
-piece of information is the overall running time and the
-accumulated times for the clock event states in refclock_states.
-When PPS information is present additional variable are available.
-refclock_ppstime lists then the PPS timestamp and refclock_ppsskew
-lists the difference between RS232 derived timestamp and the PPS
-timestamp.
+variables.  These hold the following information:
+<code>refclock_time</code> is the local time with the offset to UTC
+(format HHMM).  The currently active receiver flags are listed in
+<code>refclock_status</code>.  Additional feature flags of the receiver
+are optionally listed in parentheses.  The actual time code is listed
+in <code>timecode</code>.  A qualification of the decoded time code
+format is following in <code>refclock_format</code>.  The last piece of
+information is the overall running time and the accumulated times for
+the clock event states in <code>refclock_states</code>.  When PPS
+information is present additional variable are available.
+<code>refclock_ppstime</code> lists then the PPS timestamp and
+<code>refclock_ppsskew</code> lists the difference between RS232
+derived timestamp and the PPS timestamp.
 
 <p>Currently, fourteen clock types (devices /dev/refclock-0 -
 /dev/refclock-3) are supported by the PARSE driver.
@@ -119,7 +123,7 @@
 </ul>
 
 <p>Actual data formats and set-up requirements of the various clocks can
-be found in <a href="http:parsedata.html">XNTP PARSE clock data formats</a>.
+be found in <a href="parsedata.html">XNTP PARSE clock data formats</a>.
 <p>The reference clock support carefully monitors the state
 transitions of the receiver. All state changes and exceptional
 events such as loss of time code transmission are logged via the
@@ -144,14 +148,15 @@
 details). Meinberg receivers can be connected by feeding the PPS
 pulse of the receiver via a 1488 level converter to Pin 8 (CD) of a
 Sun serial zs-port.
-To select PPS support the STREAMS driver for PARSE must be loaded and
-the mode parameter ist the mode value of above plus 128. If 128 is
+
+<p>To select PPS support the STREAMS driver for PARSE must be loaded
+and the mode parameter ist the mode value of above plus 128. If 128 is
 not added to the mode value PPS will be detected to be available but
-it will not be used. For PPS to be used you MUST add 128 to the
-mode parameter.
+it will not be used. For PPS to be used you <strong>must</strong> add
+128 to the mode parameter.
 
 <p>There exists a special firmware release for the PZF535 Meinberg
-receivers. This release (PZFUERL 4.6 (or higher - The UERL is
+receivers. This release (<code>PZFUERL 4.6</code> (or higher - The UERL is
 important)) is absolutely recommended for XNTP use, as it provides
 LEAP warning, time code time zone information and alternate antenna
 indication. Please check with Meinberg for this firmware release.
@@ -170,12 +175,11 @@
 transmitter shutdowns you are out of luck unless you have other NTP
 servers with alternate time sources available.
 
-
 <p><h4>Monitor Data</h4>
 
-<p>clock states statistics are written hourly the the syslog
+<p>Clock state statistics are written hourly to the syslog
 service. Online information can be found by examining the 
-clock variable via the ntpq cv command.
+clock variable via the <code>ntpq cv</code> command.
 
 <p><h4>Fudge Factors</h4>
 
@@ -219,8 +223,12 @@
 <p>The pare clock mechanismis deviated from the way other xntp reference
 clocks work. For a short description how to build parse reference clocks
 see <a href="parsenew.html">making PARSE clocks</a>
+
 <p>Additional Information
 
-<p><a href="refclock.html"> Reference Clock Drivers</a>
+<p><a href="refclock.html">Reference Clock Drivers</a>
 
-<hr><address><a href="http://www4.informatik.uni-erlangen.de/~kardel">Frank Kardel</a> (<a 
href="mailto: 
[e-mail]">[e-mail]</a>)</address></body><
tml>
+<hr><address>
+<a href="http://www4.informatik.uni-erlangen.de/~kardel">Frank Kardel</a>
+(<a href="mailto:[e-mail]">[e-mail]</a>)
+</address></body></html>
--- /usr/doc/packages/xntpd/parsedata.html	Tue Jun 24 19:28:38 1997
+++ parsedata.html	Thu Sep  4 22:15:46 1997
@@ -1,12 +1,15 @@
 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML Strict//EN">
+<html><head>
 <TITLE>XNTP PARSE clock data formats</TITLE>
+</head><body>
 <h1>XNTP PARSE clock data formats</h1>
 
 <p>The parse driver currently supports several clocks with different
-query mechanisms. In order for you to find a sample that might be
-similar to a clock you might want to integrate into parse i'll sum
-up the major features of the clocks (this information is distributed
-in the parse/clk_*.c and xntpd/refclock_parse.c files).
+query mechanisms.  In order for you to find a sample that might be
+similar to a clock you might want to integrate into parse i'll sum up
+the major features of the clocks (this information is distributed in
+the <code>parse/clk_*.c</code> and <code>xntpd/refclock_parse.c</code>
+files).
 
 <hr>
 <h2>Meinberg clocks</h2>
@@ -17,7 +20,7 @@
       pattern="\2  .  .  ;  ;   :  :  ;    :  ;        ;   .         .       "
 </pre>
         <p>
-	Meinberg is a german manufacturer of time code receivers. Those clocks
+	Meinberg is a German manufacturer of time code receivers. Those clocks
 	have a pretty common output format in the stock version. In order to
 	support NTP Meinberg was so kind to produce some special versions of
 	the firmware for the use with NTP. So, if you are going to use a
@@ -32,7 +35,7 @@
 	the reception of a question mark or every second. NTP uses the latter
 	mechanism. The DCF77 variants have a pretty good relationship between
 	RS232 time code and the PPS signal while the GPS receiver has no fixed
-	timeing between the datagram and the pulse (you need to use PPS with
+	timing between the datagram and the pulse (you need to use PPS with
 	GPS!) on DCF77 you might get away without the PPS signal.
 	<pre>
 	The preferred tty setting for Meinberg is:
@@ -71,9 +74,10 @@
     <p>Version for UNI-ERLANGEN Software is: PZFUERL V4.6 (Meinberg)
 
 
-    <p>The use of this software release (or higher) is *ABSOLUTELY*
-    recommended (ask for PZFUERL version as some minor HW fixes have
-    been introduced) due to the LEAP second support and UTC indication.
+    <p>The use of this software release (or higher) is
+    <strong>absolutely</strong> recommended (ask for PZFUERL version as
+    some minor HW fixes have been introduced) due to the LEAP second
+    support and UTC indication.
     The standard timecode does not indicate when the timecode is in
     UTC (by front panel configuration) thus we have no chance to find
     the correct utc offset. For the standard format do not ever use
@@ -128,21 +132,24 @@
     &lt;L&gt;		   = 'L' on 23:59:60
 </pre>
 
-<p>For the Meinberg parse look into clock_meinberg.c
+<p>For the Meinberg parse look into <code>clk_meinberg.c</code>
 
 <br>
 <h2>Raw DCF77 Data via serial line</h2>
-<p>RAWDCF: end=TIMEOUT&gt;1.5s, sync each char (any char),generate psuedo time
-            codes, fixed format