message is produced once each minute for each frequency in turn after
minute sync has been acquired.
-<p><tt>wwv5 agc wwv wwvh</tt>
+<p><tt>wwv5 port agc wwv wwvh</tt>
-<p>where <tt>agc</tt> is the audio gain for this frequency and
-<tt>wwv</tt> and <tt>wwvh</tt> are two sets of fields, one each for WWV
-and WWVH. Each of the two fields has the format
+<p>where <tt>port</tt> and <tt>agc</tt> are the audio port and gain,
+respectively, for this frequency and <tt>wwv</tt> and <tt>wwvh</tt> are
+two sets of fields, one each for WWV and WWVH. Each of the two fields
+has the format
<p><tt>ident score comp sync/snr/jitr</tt>
of the pulse and <tt>jitr</tt> is the sample difference between the
current epoch and the last epoch. An example is:
-<p><tt>wwv5 111 C20 0100 6 8348/30.0/-3 H20 0203 0 22/-12.4/8846</tt>
+<p><tt>wwv5 2 111 C20 0100 6 8348/30.0/-3 H20 0203 0 22/-12.4/8846</tt>
-<p>Here the radio is tuned to 20 MHz and the AGC is currently 111 at
-that frequency. The message contains a report for WWV (<tt>C20</tt>) and
-WWVH (<tt>H20</tt>). The WWV report scoreboard is 0100 and the compare
-count is 6, which suggests very good reception conditions, and the
-minute sync amplitude and SNR are well above thresholds (2000 and 20 dB,
-respectively). Probably the most sensitive indicator of reception
-quality is the jitter, -3 samples, which is well below threshold (50 ms
-or 400 samples). While the message shows solid reception conditions from
-WWV, this is not the case for WWVH. Both the minute sync amplitude and
-SNR are below thresholds and the jitter is above threshold.
+<p>Here the radio is tuned to 20 MHz and the line-in port AGC is
+currently 111 at that frequency. The message contains a report for WWV
+(<tt>C20</tt>) and WWVH (<tt>H20</tt>). The WWV report scoreboard is
+0100 and the compare count is 6, which suggests very good reception
+conditions, and the minute sync amplitude and SNR are well above
+thresholds (2000 and 20 dB, respectively). Probably the most sensitive
+indicator of reception quality is the jitter, -3 samples, which is well
+below threshold (50 ms or 400 samples). While the message shows solid
+reception conditions from WWV, this is not the case for WWVH. Both the
+minute sync amplitude and SNR are below thresholds and the jitter is
+above threshold.
<p>A sequence of five messages, one for each minute, might appear as
follows:
-<p><pre>agc 95 sync C2 0107 0 164/7.2/8100 H2 0207 0 80/-5.5/7754
-agc 99 sync C5 0104 0 3995/21.8/395 H5 0207 0 27/-9.3/18826
-agc 239 sync C10 0105 0 9994/30.0/2663 H10 0207 0 54/-16.1/-529
-agc 155 sync C15 0103 3 3300/17.8/-1962 H15 0203 0 236/17.0/4873
-agc 111 sync C20 0100 6 8348/30.0/-3 H20 0203 0 22/-12.4/8846</pre>
+<p><pre>wwv5 2 95 C2 0107 0 164/7.2/8100 H2 0207 0 80/-5.5/7754
+wwv5 2 99 C5 0104 0 3995/21.8/395 H5 0207 0 27/-9.3/18826
+wwv5 2 239 C10 0105 0 9994/30.0/2663 H10 0207 0 54/-16.1/-529
+wwv5 2 155 C15 0103 3 3300/17.8/-1962 H15 0203 0 236/17.0/4873
+wwv5 2 111 C20 0100 6 8348/30.0/-3 H20 0203 0 22/-12.4/8846</pre>
<p>Clearly, the only frequencies that are available are 15 MHz and 20
MHz and propagation may be failing for 15 MHz. However, minute sync
pulses are being heard on 5 and 10 MHz, even though the data pulses are
not. This is typical of late afternoon when the maximum usable frequency
(MUF) is falling and the ionospheric loss at the lower frequencies is
-decreasing.
+beginning to decrease.
<h4>Debugging Aids</h4>
<p><dt><tt>0x0001</tt>
<dd>Minute sync. Set when the decoder has identified a station and
acquired the minute sync pulse.</dd>
-
<p><dt><tt>0x0002</tt>
<dd>Second sync. Set when the decoder has acquired the second sync pulse
and within 125 <font face=Symbol>m</font>s of the correct phase.</dd>
show the progress of identifying and tracking the minute pulse of each
station.
-<p><tt>wwv8 call comp ampl snr epoch jitr offs</tt>
-
-<p>where <tt>call</tt> is the station callsign, <tt>comp</tt> the
-compare counter, <tt>ampl</tt> the pulse amplitude, <tt>snr</tt> the
-SNR, <tt>epoch</tt> the sample number of the minute pulse in the minute,
-<tt>jitr</tt> the change since the last <tt>epoch</tt> and <tt>offs</tt>
-the minute pulse offset relative to the second pulse. An example is:
-
-<p><tt>wwv8 WWV 2 9247 30.0 18843 -1 1</tt>
-<br><tt>wwv8 WWVH 0 134 -2.9 19016 193 174</tt>
-
-<p>Here the driver has not yet acquired minute sync, WWV has been heard
-for at least two minutes, and WWVH is in the noise. The WWV minute pulse
-amplitude and SNR are well above the threshold (2000 and 6 dB,
-respectively) and the minute epoch has been determined -1 sample
-relative to the last one and 1 sample relative to the second
-sync pulse. The compare counter has incrmented to two; when it gets to
-three, minute sync has been acquired.
+<p><tt>wwv8 port agc ident comp ampl snr epoch jitr offs</tt>
+
+<p>where <tt>port</tt> and <tt>agc</tt> are the audio port and gain,
+respectively. The <tt>ident</tt>encodes the station (<tt>C</tt> for WWV,
+<tt>H</tt> for WWVH) and frequency (2, 5, 10, 15 and 20). For the
+encoded frequency, <tt>comp</tt> is the compare counter, <tt>ampl</tt>
+the pulse amplitude, <tt>snr</tt> the SNR, <tt>epoch</tt> the sample
+number of the minute pulse in the minute, <tt>jitr</tt> the change since
+the last <tt>epoch</tt> and <tt>offs</tt> the minute pulse offset
+relative to the second pulse. An example is:
+
+<p><tt> wwv8 2 127 C15 2 9247 30.0 18843 -1 1</tt>
+<br><tt>wwv8 2 127 H15 0 134 -2.9 19016 193 174</tt>
+
+<p>Here the radio is tuned to 15 MHz and the line-in port AGC is
+currently 127 at that frequency. The driver has not yet acquired minute
+sync, WWV has been heard for at least two minutes, and WWVH is in the
+noise. The WWV minute pulse amplitude and SNR are well above the
+threshold (2000 and 6 dB, respectively) and the minute epoch has been
+determined -1 sample relative to the last one and 1 sample relative to
+the second sync pulse. The compare counter has incrmented to two; when
+it gets to three, minute sync has been acquired.
<p>Format <tt>wwv3</tt> messages are produced after minute sync has been
acquired and until the seconds unit digit is determined. They show the
(1000), good subcarrier tracking phase and SNR well above the threshold
(10 dB). The bit is almost certainly a zero and the likelihood of a zero
in this second is very high.
-
<p>Format <tt>wwv4</tt> messages are produced for each of the nine BCD
timecode digits until the clock has been set or verified. They show the
results of decoding each digit of the transmitted timecode.
daylight time is in effect, respectively. The state is <tt>I</tt> or
<tt>O</tt> when daylight time is about to go into effect or out of
effect, respectively.</dd>
-
<dt><tt>dut</tt>
<dd>The DUT sign and magnitude shows the current UT1 offset relative to
the displayed UTC time, in deciseconds.</dd>
command specifies the ICOM ID select code. A missing or zero argument
disables the CI-V interface. Following are the ID select codes for the
known radios.
-
<p><table cols=6 width=100%>
<tr>
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
- <META NAME="GENERATOR" CONTENT="Mozilla/4.01 [en] (Win95; I) [Netscape]">
- <TITLE>Monitoring Options
-</TITLE>
-</HEAD>
-<BODY>
-
-<H3>
-Monitoring Options</H3>
-
-<HR>
-<H4>
-Monitoring Support</H4>
-<TT>ntpd</TT> includes a comprehensive monitoring facility suitable for
-continuous, long term recording of server and client timekeeping performance.
-See the <TT>statistics</TT> command below for a listing and example of
-each type of statistics currently supported. Statistic files are managed
-using file generation sets and scripts in the ./scripts directory of this
-distribution. Using these facilities and Unix <TT>cron</TT> jobs, the data
-can be automatically summarized and archived for retrospective analysis.
-<H4>
-Monitoring Commands</H4>
-
-<DL>
-<DT>
-<TT>statistics <I>name</I> [...]</TT></DT>
-
-<DD>
-Enables writing of statistics records. Currently, four kinds of <I><TT>name</TT></I>
-statistics are supported.</DD>
-
-<DD>
- </DD>
-
-<DL>
-<DT>
-<TT>loopstats</TT></DT>
-
-<DD>
-Enables recording of loop filter statistics information. Each update of
-the local clock outputs a line of the following form to the file generation
-set named <TT>loopstats</TT>:</DD>
-
-<PRE>50935 75440.031 0.000006019 13.778190 0.000351733 0.013380 6</PRE>
-
-<DD>
-The first two fields show the date (Modified Julian Day) and time (seconds
-and fraction past UTC midnight). The next five fields show time offset
-(seconds), frequency offset (parts per million - PPM), RMS jitter (seconds),
-Allan deviation (PPM) and clock discipline time constant.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>peerstats</TT></DT>
-
-<DD>
-Enables recording of peer statistics information. This includes statistics
-records of all peers of a NTP server and of special signals, where present
-and configured. Each valid update appends a line of the following form
-to the current element of a file generation set named <TT>peerstats</TT>:</DD>
-
-<PRE>48773 10847.650 127.127.4.1 9714 -0.001605 0.00000 0.00142</PRE>
-
-<DD>
-The first two fields show the date (Modified Julian Day) and time (seconds
-and fraction past UTC midnight). The next two fields show the peer address
-in dotted-quad notation and status, respectively. The status field is encoded
-in hex in the format described in Appendix A of the NTP specification RFC
-1305. The final three fields show the offset, delay and RMS jitter, all
-in seconds.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>clockstats</TT></DT>
-
-<DD>
-Enables recording of clock driver statistics information. Each update received
-from a clock driver appends a line of the following form to the file generation
-set named <TT>clockstats</TT>:</DD>
-
-<PRE>49213 525.624 127.127.4.1 93 226 00:08:29.606 D</PRE>
-
-<DD>
-The first two fields show the date (Modified Julian Day) and time (seconds
-and fraction past UTC midnight). The next field shows the clock address
-in dotted-quad notation, The final field shows the last timecode received
-from the clock in decoded ASCII format, where meaningful. In some clock
-drivers a good deal of additional information can be gathered and displayed
-as well. See information specific to each clock for further details.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>rawstats</TT></DT>
-
-<DD>
-Enables recording of raw-timestamp statistics information. This includes
+<html><head><title>
+Monitoring Options
+</title></head><body><h3>
+Monitoring Options
+</h3><hr>
+
+<h4>Monitoring Support</h4>
+
+<tt>ntpd</tt> includes a comprehensive monitoring facility suitable for
+continuous, long term recording of server and client timekeeping
+performance. See the <tt>statistics</tt> command below for a listing and
+example of each type of statistics currently supported. Statistic files
+are managed using file generation sets and scripts in the ./scripts
+directory of this distribution. Using these facilities and Unix
+<tt>cron</tt> jobs, the datacan be automatically summarized and archived
+for retrospective analysis.
+
+<h4>Monitoring Commands</h4>
+
+<dl>
+
+<dt><tt>statistics <I>name</I> [...]</tt></dt>
+<dd>Enables writing of statistics records. Currently, four kinds of
+<I><tt>name</tt></I>statistics are supported.</dd>
+
+<dl>
+
+<dt><tt>loopstats</tt></dt>
+<dd>Enables recording of loop filter statistics information. Each update
+of the local clock outputs a line of the following form to the file
+generation set named <tt>loopstats</tt>:</dd>
+
+<p><dd><tt>50935 75440.031 0.000006019 13.778190 0.000351733 0.013380
+6</tt></dd>
+
+<p><dd>The first two fields show the date (Modified Julian Day) and time
+(seconds and fraction past UTC midnight). The next five fields show time
+offset (seconds), frequency offset (parts per million - PPM), RMS jitter
+(seconds), Allan deviation (PPM) and clock discipline time
+constant.</dd>
+
+<dt><tt>peerstats</tt></dt>
+<dd>Enables recording of peer statistics information. This includes
statistics records of all peers of a NTP server and of special signals,
-where present and configured. Each NTP message received from a peer or
-clock driver appends a line of the following form to the file generation
-set named <TT>rawstats</TT>:</DD>
-
-<DD>
- </DD>
-
-<DD>
-<TT>50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000 3102453281.58622800031
-02453332.540806000 3102453332.541458000</TT></DD>
-
-<DD>
-<TT> </TT></DD>
-
-<DD>
-The first two fields show the date (Modified Julian Day) and time (seconds
-and fraction past UTC midnight). The next field shows the peer or clock
-address in dotted-quad notation, The final four fields show the originate,
-receive, transmit and final NTP timestamps in order. The timestamp values
-are as received and before processing by the various data smoothing and
-mitigation algorithms.</DD>
-</DL>
-
-<DD>
- </DD>
-
-<DT>
-<TT>statsdir <I>directory_path</I></TT></DT>
-
-<DD>
-Indicates the full path of a directory where statistics files should be
-created (see below). This keyword allows the (otherwise constant) <TT>filegen</TT>
-filename prefix to be modified for file generation sets, which is useful
-for handling statistics logs.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>filegen <I>name</I> [file <I>filename</I>] [type <I>typename</I>] [link
-| nolink] [enable | disable]</TT></DT>
-
-<DT>
-<TT> </TT></DT>
-
-<DD>
-Configures setting of generation file set <I>name</I>. Generation file
-sets provide a means for handling files that are continuously growing during
-the lifetime of a server. Server statistics are a typical example for such
-files. Generation file sets provide access to a set of files used to store
-the actual data. At any time at most one element of the set is being written
-to. The type given specifies when and how data will be directed to a new
-element of the set. This way, information stored in elements of a file
-set that are currently unused are available for administrational operations
-without the risk of disturbing the operation of <TT>ntpd</TT>. (Most important:
-they can be removed to free space for new data produced.)</DD>
-
-<DD>
- </DD>
-
-<DD>
-Note that this command can be sent from the <TT>ntpdc</TT> program running
-at a remote location.</DD>
-
-<DD>
- </DD>
-
-<DL>
-<DT>
-<I><TT>name</TT></I></DT>
-
-<DD>
-This is the type of the statistics records, as shown in the <TT>statististics</TT>
-command.</DD>
-
-<DD>
- </DD>
-</DL>
-
-<DD>
-<TT>file <I>filename</I></TT></DD>
-
-<DL>
-<DD>
-This is the file name for the statistics records. Filenames of set members
-are built from three elements:</DD>
-
-<DD>
- </DD>
-
-<DL>
-<DT>
-prefix</DT>
-
-<DD>
-This is a constant filename path. It is not subject to modifications via
-the <TT>filegen</TT> option. It is defined by the server, usually specified
-as a compile-time constant. It may, however, be configurable for individual
-file generation sets via other commands. For example, the prefix used with
-<TT>loopstats</TT> and <TT>peerstats</TT> generation can be configured
-using the <TT>statsdir</TT> option explained above.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<I><TT>filename</TT></I></DT>
-
-<DD>
-This string is directly concatenated to the prefix mentioned above (no
-intervening <TT>/</TT> (slash)). This can be modified using the <TT>file</TT>
-argument to the <TT>filegen</TT> statement. No <TT>..</TT> elements are
-allowed in this component to prevent filenames referring to parts outside
-the filesystem hierarchy denoted by <TT>prefix</TT>.</DD>
-
-<DD>
- </DD>
-
-<DT>
-suffix</DT>
-
-<DD>
-This part is reflects individual elements of a file set. It is generated
-according to the type of a file set.</DD>
-</DL>
-
-<DD>
- </DD>
-</DL>
-
-<DD>
-<TT>type <I>typename</I></TT></DD>
-
-<DL>
-<DD>
-A file generation set is characterized by its type. The following types
-are supported:</DD>
-
-<DD>
- </DD>
-
-<DL>
-<DT>
-<TT>none</TT></DT>
-
-<DD>
-The file set is actually a single plain file.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>pid</TT></DT>
-
-<DD>
-One element of file set is used per incarnation of a <TT>ntpd</TT> server.
-This type does not perform any changes to file set members during runtime,
-however it provides an easy way of separating files belonging to different
-<TT>ntpd</TT> server incarnations. The set member filename is built by
-appending a <TT>.</TT> (dot) to concatenated <I>prefix</I> and <I>filename</I>
-strings, and appending the decimal representation of the process ID of
-the <TT>ntpd</TT> server process.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>day</TT></DT>
-
-<DD>
-One file generation set element is created per day. A day is defined as
-the period between 00:00 and 24:00 UTC. The file set member suffix consists
-of a <TT>.</TT> (dot) and a day specification in the form <TT>YYYYMMDD.
-YYYY</TT> is a 4-digit year number (e.g., 1992). <TT>MM</TT> is a two digit
-month number. <TT>DD</TT> is a two digit day number. Thus, all information
-written at 10 December 1992 would end up in a file named <TT><I>prefix
-filename</I>.19921210</TT>.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>week</TT></DT>
-
-<DD>
-Any file set member contains data related to a certain week of a year.
-The term week is defined by computing day-of-year modulo 7. Elements of
-such a file generation set are distinguished by appending the following
-suffix to the file set filename base: A dot, a 4-digit year number, the
-letter <TT>W</TT>, and a 2-digit week number. For example, information
-from January, 10th 1992 would end up in a file with suffix <TT>.1992W1</TT>.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>month</TT></DT>
-
-<DD>
-One generation file set element is generated per month. The file name suffix
-consists of a dot, a 4-digit year number, and a 2-digit month.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>year</TT></DT>
-
-<DD>
-One generation file element is generated per year. The filename suffix
-consists of a dot and a 4 digit year number.</DD>
-
-<DD>
- </DD>
-
-<DT>
-<TT>age</TT></DT>
-
-<DD>
-This type of file generation sets changes to a new element of the file
-set every 24 hours of server operation. The filename suffix consists of
-a dot, the letter <TT>a</TT>, and an 8-digit number. This number is taken
-to be the number of seconds the server is running at the start of the corresponding
-24-hour period. Information is only written to a file generation by specifying
-<TT>enabl</TT>; output is prevented by specifying <TT>disable</TT>.</DD>
-
-<DD>
- </DD>
-</DL>
-</DL>
-
-<DD>
-<TT>link | nolink</TT></DD>
-
-<DL>
-<DD>
-It is convenient to be able to access the current element of a file generation
-set by a fixed name. This feature is enabled by specifying <TT>link</TT>
-and disabled using <TT>nolink</TT>. If <TT>link</TT> is specified, a hard
-link from the current file set element to a file without suffix is created.
-When there is already a file with this name and the number of links of
-this file is one, it is renamed appending a dot, the letter <TT>C</TT>,
-and the pid of the <TT>ntpd</TT> server process. When the number of links
-is greater than one, the file is unlinked. This allows the current file
-to be accessed by a constant name.</DD>
-
-<DD>
- </DD>
-</DL>
-
-<DD>
-<TT>enable | disable</TT></DD>
-
-<DL>
-<DD>
-Enables or disables the recording function.</DD>
-</DL>
-</DL>
-
-<HR>
-<ADDRESS>
-David L. Mills (mills@udel.edu)</ADDRESS>
-
-</BODY>
-</HTML>
+where present and configured. Each valid update appends a line of the
+following form to the current element of a file generation set named
+<tt>peerstats</tt>:</dd>
+
+<p><dd><tt>48773 10847.650 127.127.4.1 9714 -0.001605 0.00000
+0.00142</tt></dd>
+
+<p><dd>The first two fields show the date (Modified Julian Day) and time
+(seconds and fraction past UTC midnight). The next two fields show the
+peer address in dotted-quad notation and status, respectively. The
+status field is encoded in hex in the format described in Appendix A of
+the NTP specification RFC 1305. The final three fields show the offset,
+delay and RMS jitter, all in seconds.</dd>
+
+<dt><tt>clockstats</tt></dt>
+<dd>Enables recording of clock driver statistics information. Each
+update received from a clock driver appends a line of the following form
+to the file generation set named <tt>clockstats</tt>:</dd>
+
+<p><dd><tt>49213 525.624 127.127.4.1 93 226 00:08:29.606 D</tt></dd>
+<p><dd>The first two fields show the date (Modified Julian Day) and time
+(seconds and fraction past UTC midnight). The next field shows the clock
+address in dotted-quad notation, The final field shows the last timecode
+received from the clock in decoded ASCII format, where meaningful. In
+some clock drivers a good deal of additional information can be gathered
+and displayed as well. See information specific to each clock for
+further details.</dd>
+
+<dt><tt>rawstats</tt></dt>
+<dd>Enables recording of raw-timestamp statistics information. This
+includes statistics records of all peers of a NTP server and of special
+signals, where present and configured. Each NTP message received from a
+peer or clock driver appends a line of the following form to the file
+generation set named <tt>rawstats</tt>:</dd>
+
+<p><dd><tt>50928 2132.543 128.4.1.1 128.4.1.20 3102453281.584327000
+3102453281.58622800031 02453332.540806000 3102453332.541458000</tt></dd>
+
+<p><dd>The first two fields show the date (Modified Julian Day) and time
+(seconds and fraction past UTC midnight). The next two fields show the
+remote peer or clock address followed by the local address in
+dotted-quad notation, The final four fields show the originate, receive,
+transmit and final NTP timestamps in order. The timestamp values are as
+received and before processing by the various data smoothing and
+mitigation algorithms.</dd>
+
+</dl>
+
+<dt><tt>statsdir <I>directory_path</I></tt></dt>
+<dd>Indicates the full path of a directory where statistics files should
+be created (see below). This keyword allows the (otherwise constant)
+<tt>filegen</tt> filename prefix to be modified for file generation
+sets, which is useful for handling statistics logs.</dd>
+
+<dt><tt>filegen <I>name</I> [file <I>filename</I>] [type
+<I>typename</I>] [link | nolink] [enable | disable]</tt></dt>
+<dd>Configures setting of generation file set <I>name</I>. Generation
+file sets provide a means for handling files that are continuously
+growing during the lifetime of a server. Server statistics are a typical
+example for such files. Generation file sets provide access to a set of
+files used to store the actual data. At any time at most one element of
+the set is being written to. The type given specifies when and how data
+will be directed to a new element of the set. This way, information
+stored in elements of a file set that are currently unused are available
+for administrational operations without the risk of disturbing the
+operation of <tt>ntpd</tt>. (Most important: they can be removed to free
+space for new data produced.)</dd>
+
+<dd>Note that this command can be sent from the <tt>ntpdc</tt> program
+running at a remote location.</dd>
+
+<dl>
+
+<dt><I><tt>name</tt></I></dt>
+<dd>This is the type of the statistics records, as shown in the
+<tt>statististics</tt> command.</dd>
+
+</dl>
+
+<dd><tt>file <I>filename</I></tt></dd>
+
+<dl>
+
+<dd>This is the file name for the statistics records. Filenames of set
+members are built from three concatenated elements
+<I><tt>prefix</tt></I>, <I><tt>filename</tt></I> and
+<I><tt>suffix</tt></I>:</dd>
+
+<dl>
+
+<dt><I><tt>prefix</tt></I></dt>
+<dd>This is a constant filename path. It is not subject to modifications
+via the <tt>filegen</tt> option. It is defined by the server, usually
+specified as a compile-time constant. It may, however, be configurable
+for individual file generation sets via other commands. For example, the
+prefix used with <tt>loopstats</tt> and <tt>peerstats</tt> generation
+can be configured using the <tt>statsdir</tt> option explained
+above.</dd>
+
+<dt><I><tt>filename</tt></I></dt>
+<dd>This string is directly concatenated to the prefix mentioned above
+(no intervening <tt>/</tt> (slash)). This can be modified using the
+<tt>file</tt> argument to the <tt>filegen</tt> statement. No <tt>..</tt>
+elements are allowed in this component to prevent filenames referring to
+parts outside the filesystem hierarchy denoted by <tt>prefix</tt>.</dd>
+
+<dt><I><tt>suffix</tt></I></dt>
+<dd>This part is reflects individual elements of a file set. It is
+generated according to the type of a file set.</dd>
+
+</dl>
+
+</dl>
+
+<dd><tt>type <I>typename</I></tt></dd>
+
+<dl>
+
+<dd>A file generation set is characterized by its type. The following
+types are supported:</dd>
+
+<dl>
+
+<dt><tt>none</tt></dt>
+<dd>The file set is actually a single plain file.</dd>
+
+<dt><tt>pid</tt></dt>
+<dd>One element of file set is used per incarnation of a <tt>ntpd</tt>
+server. This type does not perform any changes to file set members
+during runtime, however it provides an easy way of separating files
+belonging to different <tt>ntpd</tt> server incarnations. The set member
+filename is built by appending a <tt>.</tt> (dot) to concatenated
+<I>prefix</I> and <I>filename</I> strings, and appending the decimal
+representation of the process ID of the <tt>ntpd</tt> server
+process.</dd>
+
+<dt><tt>day</tt></dt>
+<dd>One file generation set element is created per day. A day is defined
+as the period between 00:00 and 24:00 UTC. The file set member suffix
+consists of a <tt>.</tt> (dot) and a day specification in the form
+<tt>YYYYMMdd. YYYY</tt> is a 4-digit year number (e.g., 1992).
+<tt>MM</tt> is a two digit month number. <tt>dd</tt> is a two digit day
+number. Thus, all information written at 10 December 1992 would end up
+in a file named <tt><I>prefix filename</I>.19921210</tt>.</dd>
+
+<dt><tt>week</tt></dt>
+<dd>Any file set member contains data related to a certain week of a
+year. The term week is defined by computing day-of-year modulo 7.
+Elements of such a file generation set are distinguished by appending
+the following suffix to the file set filename base: A dot, a 4-digit
+year number, the letter <tt>W</tt>, and a 2-digit week number. For
+example, information from January, 10th 1992 would end up in a file with
+suffix <tt>.1992W1</tt>.</dd>
+
+<dt><tt>month</tt></dt>
+<dd>One generation file set element is generated per month. The file
+name suffix consists of a dot, a 4-digit year number, and a 2-digit
+month.</dd>
+
+<dt><tt>year</tt></dt>
+<dd>One generation file element is generated per year. The filename
+suffix consists of a dot and a 4 digit year number.</dd>
+
+<dt><tt>age</tt></dt>
+<dd>This type of file generation sets changes to a new element of the
+file set every 24 hours of server operation. The filename suffix
+consists of a dot, the letter <tt>a</tt>, and an 8-digit number. This
+number is taken to be the number of seconds the server is running at the
+start of the corresponding 24-hour period. Information is only written
+to a file generation by specifying <tt>enable</tt>; output is prevented
+by specifying <tt>disable</tt>.</dd>
+
+</dl>
+
+</dl>
+
+<dd><tt>link | nolink</tt></dd>
+
+<dl>
+
+<dd>It is convenient to be able to access the current element of a file
+generation set by a fixed name. This feature is enabled by specifying
+<tt>link</tt> and disabled using <tt>nolink</tt>. If <tt>link</tt> is
+specified, a hard link from the current file set element to a file
+without suffix is created. When there is already a file with this name
+and the number of links of this file is one, it is renamed appending a
+dot, the letter <tt>C</tt>, and the pid of the <tt>ntpd</tt> server
+process. When the number of links is greater than one, the file is
+unlinked. This allows the current file to be accessed by a constant
+name.</dd>
+
+</dl>
+
+<dd><tt>enable | disable</tt></dd>
+
+<dl>
+
+<dd>Enables or disables the recording function.</dd>
+
+</dl>
+
+</dl>
+
+<hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
+href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a>
+</address></a></body></html>
projects / thirdparty / ntp.git / commitdiff
