Commit dc335688 authored by Eric S. Raymond's avatar Eric S. Raymond

Change logs to use new-style clock identifiers (e.g. not magic addresses).

The --enable-classic-mode build switch restores the old behavior.

All log channels work live (with new clock IDs) at this revision.
parent 79cff209
......@@ -143,6 +143,20 @@ By default, `waf install' will install the package's files in
installation prefix other than `/usr/local' by giving waf the
option `--prefix=PATH'.
== Strict compatibility mode ==
There have been a handful of forward-incompatible changes from NTP Classic.
These are unlikely to affect normal operation. However, there is a configure
operation, --enable-classic-mode, that restores certain legacy behaviors. This
is not recommended, as it makes the code a little bulkier and slower.
Here's what it presently does:
* Reverts logging to the old format that designates clocks with magic
addresses rather than the driver shortname and unit number.
Other behaviors may be added in future releases.
== Uninstalled binaries and scripts ==
Due to variations in Perl library paths, our stock source distribution
......
......@@ -114,7 +114,7 @@ is used to distinguish multiple instances of clocks of the same type.
These addresses used to be exposed as part of the refclock
configuration syntax, but are no longer. Nothing in ntpd now actually
requires this form of address for clocks, but it is still generated
so as not to hand surprises to legacy ntpq instances that still make
so as not to hand surprises to legacy +{ntpq}+ instances that still make
the assumption.
Most clocks require a serial or parallel port or special bus peripheral.
......
......@@ -158,7 +158,7 @@ counters will be appended to the NMEA sentence that gets logged. For
example:
----------------------------------------------------------------------------
56299 76876.691 127.127.20.20 $GPGGA,212116.000,3726.0785,N,12212.2605,W,1,05,2.0,17.0,M,-25.7,M,,0000*5C 228 64 0 0 64 0
56299 76876.691 nmea(0) $GPGGA,212116.000,3726.0785,N,12212.2605,W,1,05,2.0,17.0,M,-25.7,M,,0000*5C 228 64 0 0 64 0
----------------------------------------------------------------------------
.Clockstats
......@@ -167,7 +167,7 @@ example:
|Column|Sample |Meaning
|1 |56299 |MJD
|2 |76876.691 |Time of day in seconds
|3 |127.127.20.20 |IP Address from server config line
|3 |NMEA(0) |Driver type and unit.
|4 |$GPGGA,...0*5C |NMEA Sentence
|5 |228 |Number of sentences received
|6 |64 |Number of sentences accepted and used for timekeeping
......@@ -179,6 +179,11 @@ example:
|10 |0 |Number of PPS pulses used, overrides NMEA sentences
|=============================================================================
The clock identification in field 3 is normally the driver type and
unit, but if your {ntpd} was built in strict Classic compatibility
mode it will be a magic clock address expressing the same information
in a more opaque way.
Sentences like $GPGSV that don't contain the time will get counted in
the total but otherwise ignored.
......
......@@ -136,10 +136,10 @@ it. That will be one of the following: generic, nmea, or spectracom.
If clockstats is enabled, the driver will log a few counters. Examples:
----------------------------------------------------------------------------
57378 3313.351 127.127.22.0 423681 64 0 0 0
57378 3377.352 127.127.22.0 423745 64 0 0 0
57378 3441.352 127.127.22.0 423809 64 0 0 0
57378 3505.351 127.127.22.0 423873 64 0 0 0
57378 3313.351 PPS(0) 423681 64 0 0 0
57378 3377.352 PPS(0) 423745 64 0 0 0
57378 3441.352 PPS(0) 423809 64 0 0 0
57378 3505.351 PPS(0) 423873 64 0 0 0
----------------------------------------------------------------------------
.Clockstats
......@@ -148,7 +148,7 @@ If clockstats is enabled, the driver will log a few counters. Examples:
|Column|Sample |Meaning
|1 |57378 |MJD
|2 |3505.351 |Time of day in seconds
|3 |127.127.22.0 |IP Address from server config line
|3 |PPS(0) |Clock identification
|4 |423873 |Total number of PPS pulses the kernel has seen
|5 |64 |Number of PPS pulses the driver processed
This should be the difference between col 4 and
......@@ -158,7 +158,10 @@ If clockstats is enabled, the driver will log a few counters. Examples:
|8 |0 |Number of times there was no pulse ready
|=============================================================================
The clock identification is normally the driver type and unit, but if
your {ntpd} was built in strict Classic compatibility mode it will
be a magic clock address expressing the same information in a more
opaque way.
== Additional Information ==
......
......@@ -115,21 +115,26 @@ trying to grab a sample.
Here is a sample showing the GPS reception fading out:
------------------------------------------------
54364 84927.157 127.127.28.0 66 65 1 0 0
54364 84990.161 127.127.28.0 63 63 0 0 0
54364 85053.160 127.127.28.0 63 63 0 0 0
54364 85116.159 127.127.28.0 63 62 1 0 0
54364 85180.158 127.127.28.0 64 63 1 0 0
54364 85246.161 127.127.28.0 66 66 0 0 0
54364 85312.157 127.127.28.0 66 50 16 0 0
54364 85375.160 127.127.28.0 63 41 22 0 0
54364 85439.155 127.127.28.0 64 64 0 0 0
54364 85505.158 127.127.28.0 66 36 30 0 0
54364 85569.157 127.127.28.0 64 0 64 0 0
54364 85635.157 127.127.28.0 66 0 66 0 0
54364 85700.160 127.127.28.0 65 0 65 0 0
54364 84927.157 SHM(0) 66 65 1 0 0
54364 84990.161 SHM(0) 63 63 0 0 0
54364 85053.160 SHM(0) 63 63 0 0 0
54364 85116.159 SHM(0) 63 62 1 0 0
54364 85180.158 SHM(0) 64 63 1 0 0
54364 85246.161 SHM(0) 66 66 0 0 0
54364 85312.157 SHM(0) 66 50 16 0 0
54364 85375.160 SHM(0) 63 41 22 0 0
54364 85439.155 SHM(0) 64 64 0 0 0
54364 85505.158 SHM(0) 66 36 30 0 0
54364 85569.157 SHM(0) 64 0 64 0 0
54364 85635.157 SHM(0) 66 0 66 0 0
54364 85700.160 SHM(0) 65 0 65 0 0
------------------------------------------------
The clock identification is normally the driver type and unit, but if
your {ntpd} was built in strict Classic compatibility mode it will
be a magic clock address expressing the same information in a more
opaque way.
== The \'mode' word ==
Some aspects of the driver behavior can be adjusted by setting bits of
......
......@@ -10,16 +10,17 @@
form to the file generation set named _clockstats_:
+
-----------------------------------------------
49213 525.624 127.127.4.1 93 226 00:08:29.606 D
49213 525.624 SPECTRACOM(4) 93 226 00:08:29.606 D
-----------------------------------------------
+
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.
normally shows clock type and unit (but if you are running in strict
Classic compatibility it will show the magic clock address in
dotted-quad notation). The final field 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.
+cryptostats+;;
This option requires the OpenSSL cryptographic software library. It
......@@ -28,23 +29,26 @@ specific to each clock for further details.
following form to the file generation set named _cryptostats_:
+
---------------------------------
49213 525.624 127.127.4.1 message
49213 525.624 SPECTRACOM(4) message
---------------------------------
+
[width="100%",cols="<34%,<33%,<33%"]
|============================================
|Item | Units |Description
|+49213+ |MJD |date
|+525.624+ |s |time past midnight
|+127.127.4.1+|IP |reference clock address
|_+message+_ |text |log message
|============================================
|================================================
|Item | Units |Description
|+49213+ |MJD |date
|+525.624+ |s |time past midnight
|+SPECTRACOM(4)+|IP |reference clock type and unit
|_+message+_ |text |log message
|===============================================
+
The first two fields show the date (Modified Julian Day) and time
(seconds and fraction past UTC midnight). The next field shows the
peer address in dotted-quad notation, The final message field
includes the message type and certain ancillary information. See the
'Authentication Options' section for further information.
(seconds and fraction past UTC midnight). The next field normally
shows the clock driver type and unit (but if you have built in Classic
compatibility mode it will show a magic clock address in dotted-quad
notation). The final message field includes the message type and
certain ancillary information. See the 'Authentication Options'
section for further information.
+loopstats+;;
Enables recording of loop filter statistics information. Each update
......@@ -101,26 +105,27 @@ The event message code and _+message+_ field are described on the
generation set named _peerstats_:
+
---------------------------------------------------------------------------------
48773 10847.650 127.127.4.1 9714 -0.001605376 0.000000000 0.001424877 0.000958674
48773 10847.650 SPECTRACOM(4) 9714 -0.001605376 0.000000000 0.001424877 0.000958674
---------------------------------------------------------------------------------
+
[width="100%",cols="<34%,<33%,<33%"]
|===================================================
|Item |Units |Description
|+48773+ |MJD |date
|+10847.650+ |s |time past midnight
|+127.127.4.1+ |IP |source address
|+9714+ |hex |status word
|+-0.001605376+|s |clock offset
|+0.000000000+ |s |roundtrip delay
|+0.001424877+ |s |dispersion
|+0.000958674+ |s |RMS jitter
|Item |Units |Description
|+48773+ |MJD |date
|+10847.650+ |s |time past midnight
|+SPECTRACOM(4)+ |IP |clock name(unit) or source address
|+9714+ |hex |status word
|+-0.001605376+ |s |clock offset
|+0.000000000+ |s |roundtrip delay
|+0.001424877+ |s |dispersion
|+0.000958674+ |s |RMS jitter
|===================================================
+
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
(seconds and fraction past UTC midnight). The third field shows
the reference clock type and unit number (but if you are running in
the peer address in dotted-quad notation instead) The fourth field
is a status word, encoded in hex in the format described in
Appendix A of the NTP specification RFC 1305. The final four fields
show the offset, delay, dispersion and RMS jitter, all in seconds.
......@@ -161,7 +166,7 @@ show the offset, delay, dispersion and RMS jitter, all in seconds.
+
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
the remote peer or clock identification 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
......
......@@ -154,6 +154,11 @@ few will be user-visible.
* Log timestamps look a little different; they are now in ISO8601 format.
* Clock identifiers in log files are normally the driver shortname
followed by the unit number in parentheses, rather than the magic IP
addresses formerly used. The code can be built in a strict NTP
Classic compatibility mode that restores the old behavior.
* The -!m, ->, and -< options of some Classic commands are not
supported. (The argument-parsing framework code that implemented
them in Classic was overcomplicated and buggy and had to be removed.)
......
......@@ -54,14 +54,13 @@ variables that control various related operations.
=== Association Commands ===
The various modes are determined by the command keyword and the type of
the required IP address. Addresses are classed by type as (s) a remote
server or peer (IPv4 class A, B and C), (b) the broadcast address of a
local interface, (m) a multicast address (IPv4 class D), or (r) a
reference clock address (127.127.x.x). For type m addresses the
IANA has assigned the multicast group address IPv4 224.0.1.1 and IPv6
ff05::101 (site local) exclusively to NTP, but other nonconflicting
addresses can be used.
The various modes are determined by the command keyword and the type
of the required IP address. Addresses are classed by type as (s) a
remote server or peer (IPv4 class A, B and C), (b) the broadcast
address of a local interface, or (m) a multicast address (IPv4 class
D). For type m addresses the IANA has assigned the multicast group
address IPv4 224.0.1.1 and IPv6 ff05::101 (site local) exclusively to
NTP, but other nonconflicting addresses can be used.
Note that only those options applicable to each command are listed
below. Use of options not listed may not be caught as an error, but
......
......@@ -386,7 +386,7 @@ stats_config(
* file format:
* day (MJD)
* time (s past UTC midnight)
* IP address
* IP address (old format) or drivername(unit) (new format)
* status word (hex)
* offset
* delay
......@@ -418,6 +418,16 @@ record_peer_stats(
}
}
static const char *
peerlabel(const struct peer *peer)
{
#ifndef ENABLE_CLASSIC_MODE
if (peer->procptr != NULL)
return refclock_name((struct peer *)peer);
else
#endif /* ENABLE_CLASSIC_MODE */
return stoa(&peer->srcadr);
}
/*
* record_loop_stats - write loop filter statistics to file
......@@ -465,7 +475,7 @@ record_loop_stats(
* file format:
* day (MJD)
* time (s past midnight)
* IP address
* IP address (old format) or drivername(unit) new format
* text message
*/
void
......@@ -486,7 +496,7 @@ record_clock_stats(
now.l_ui %= 86400;
if (clockstats.fp != NULL) {
fprintf(clockstats.fp, "%lu %s %s %s\n", day,
ulfptoa(&now, 3), stoa(&peer->srcadr), text);
ulfptoa(&now, 3), peerlabel(peer), text);
fflush(clockstats.fp);
}
}
......@@ -523,7 +533,7 @@ mprintf_clock_stats(
* day (MJD)
* time (s past midnight)
* peer ip address
* IP address
* IP address old format) or drivername(unit) (new format)
* t1 t2 t3 t4 timestamps
*/
void
......@@ -551,7 +561,7 @@ record_raw_stats(
l_fp now;
u_long day;
UNUSED_ARG(peer);
UNUSED_ARG(srcadr);
if (!stats_control)
return;
......@@ -563,7 +573,7 @@ record_raw_stats(
if (rawstats.fp != NULL) {
fprintf(rawstats.fp, "%lu %s %s %s %s %s %s %s %d %d %d %d %d %d %.6f %.6f %s %d\n",
day, ulfptoa(&now, 3),
stoa(srcadr), dstadr ? stoa(dstadr) : "-",
peerlabel(peer), dstadr ? stoa(dstadr) : "-",
ulfptoa(t1, 9), ulfptoa(t2, 9),
ulfptoa(t3, 9), ulfptoa(t4, 9),
leap, version, mode, stratum, ppoll, precision,
......
......@@ -457,7 +457,7 @@ def cmd_configure(ctx, config):
# Shouldn't be an issue as 8.x shipped in January 1991!
# ctx.define("NEED_RCVBUF_SLOP", 1)
# It should be possible to use asynchrpnous I/O with notification
# It should be possible to use asynchronous I/O with notification
# by SIGIO on any Unix conformant to POSIX.1-2001. But the code to
# do this is untested and there are historical reasons to suspect
# it might not work reliably on all platforms. Enable cautiously
......@@ -546,6 +546,10 @@ def cmd_configure(ctx, config):
from pylib.check_mdns import check_mdns_run
check_mdns_run(ctx)
if ctx.options.enable_classic_mode:
ctx.define("ENABLE_CLASSIC_MODE", 1)
else:
ctx.undefine("ENABLE_CLASSIC_MODE")
if ctx.env.PTHREAD_ENABLE:
ctx.define("ISC_PLATFORM_USETHREADS", 1)
......
......@@ -15,6 +15,7 @@ def options_cmd(ctx, config):
grp.add_option('--disable-dns-lookup', action='store_true', default=False, help="Disable DNS lookups.")
grp.add_option('--disable-dns-retry', action='store_true', default=False, help="Disable retrying DNS lookups.")
grp.add_option('--disable-mdns-registration', action='store_true', default=False, help="Disable MDNS registration.")
grp.add_option('--enable-classic-mode', action='store_true', default=False, help="Strict configuration and log-format compatibility with NTP Classic")
grp = ctx.add_option_group("NTP cross compile options")
grp.add_option('--cross-compiler', type='string', help="Path to cross compiler CC. (enables cross-compiling)")
......
......@@ -9,6 +9,11 @@ shell script once per day, week or month, as appropriate. There are
three file collections presently defined: peerstats, loopstats and
clockstats, each of which is described in this note.
Note: The NTPsec versions of these formats differ in that clock IDs
consist of a string drivername followed by unit number in parentheses
rather than the magic IP addresses used in NTP Classic. The code can
be built in a Classic compatibility node that restores the old behavior.
peerstats
The following data are collected in the peerstats files. The files are
......@@ -52,11 +57,11 @@ received from a configured radio clock. Data are at present recorded for
several radios. The first part of each data line is similar for all
radios, e.g.:
49234 60517.826 127.127.4.1 93 247 16:48:21.814
49234 60517.826 SPECTRACOM(1) 93 247 16:48:21.814
49234 modified Julian day number
60517.826 time of day (s) past midnight UTC
127.127.4.1 receiver identifier (Spectracom)
49234 modified Julian day number
60517.826 time of day (s) past midnight UTC
SPECTRACOM(1) receiver identifier (Spectracom unit 1)
93 247 16:48:21.814 timecode (format varies)
In the case of the Austron GPS receiver, a good deal of additional
......@@ -68,20 +73,20 @@ by these radios.
Spectracom receiver
49234 60517.826 127.127.4.1 ?A93 247 16:48:21.814
49234 60517.826 SPECTRACOM(1) ?A93 247 16:48:21.814
The '?' and 'A' characters are present only when the receiver is
unsynchronized; otherwise, they are replaced by space ' ' characters.
IRIG audio decoder
49234 60517.826 127.127.6.0 247 16:48:21?
49234 60517.826 IRIG(0) 247 16:48:21?
The '?' character is present only when the receiver is unsynchronized.
Austron 2200A/2201A GPS receiver
49234 60580.843 127.127.10.1 93:247:16:49:24.814?
49234 60580.843 AUSTRON(1) 93:247:16:49:24.814?
The '?' character is present only when the receiver is unsynchronized.
......@@ -102,7 +107,7 @@ These data determine the deviations of external time/frequency inputs
relative to receiver oscillator time. The following data are typical
using an external cesium oscillator PPS and 5-MHz outputs.
49234 60580.843 127.127.10.1 93:247:16:49:24.814 ETF
49234 60580.843 AUSTRON(1) 93:247:16:49:24.814 ETF
-85.9 time interval (ns)
-89.0 average time interval (ns)
......@@ -117,7 +122,7 @@ Model and option identifiers
These data show the receiver model number and option configuration.
49234 60708.848 127.127.10.1 93:247:16:51:32.817 ID;OPT;VER
49234 60708.848 AUSTRON(1) 93:247:16:51:32.817 ID;OPT;VER
GPS 2201A model ident (must be "GPS 2200A" or "GPS 2201A")
TTY1 rs232 option present (required)
......@@ -134,7 +139,7 @@ Internal time/frequency data
These data determine the deviations of the receiver oscillator with
respect to satellite time.
49234 60564.846 127.127.10.1 93:247:16:49:08.816 ITF
49234 60564.846 AUSTRON(1) 93:247:16:49:08.816 ITF
COCO current mode (must be "COCO")
0 code coast mode (must be zero)
......@@ -150,7 +155,7 @@ GPS/LORAN ensemble data (requires LORAN assist option LORAN)
These data determine the deviations and weights to calculate ensemble
time from GPS and LORAN data.
49234 60596.852 127.127.10.1 93:247:16:49:40.812 LORAN ENSEMBLE
49234 60596.852 AUSTRON(1) 93:247:16:49:40.812 LORAN ENSEMBLE
+9.06E-08 GPS t (s)
+3.53E-08 GPS sigma (s)
......@@ -167,7 +172,7 @@ These data determine which stations of the LORAN chain are being
tracked, together with individual signal/noise ratios, deviations and
weights.
49234 60532.850 127.127.10.1 93:247:16:48:36.820 LORAN TDATA
49234 60532.850 AUSTRON(1) 93:247:16:48:36.820 LORAN TDATA
M station identifier; data follows
OK status (must be "OK" for tracking)
......@@ -187,7 +192,7 @@ Oscillator status and environment
These data determine the receiver oscillator type, mode, status and
environment. Nominal operating conditions are shown below.
49234 60628.847 127.127.10.1 93:247:16:50:12.817 OSC;ET;TEMP
49234 60628.847 AUSTRON(1) 93:247:16:50:12.817 OSC;ET;TEMP
1121 Software Control oscillator model and mode (must be
"Software Control")
......@@ -200,7 +205,7 @@ Receiver position, status and offsets
These data determine the receiver position and elevation, together with
programmable delay corrections for the antenna cable and receiver.
49234 60788.847 127.127.10.1 93:247:16:52:52.817 POS;PPS;PPSOFF
49234 60788.847 AUSTRON(1) 93:247:16:52:52.817 POS;PPS;PPSOFF
+39:40:48.425 receiver latitude (N)
-075:45:02.392 receiver longitude (E)
......@@ -219,7 +224,7 @@ present state of constellation development, there should be at least
three visible satellites in view. Much of the time the maximum of
seven are being tracked; rarely this number drops to two.
49234 60612.850 127.127.10.1 93:247:16:49:56.820 TRSTAT
49234 60612.850 AUSTRON(1) 93:247:16:49:56.820 TRSTAT
24 T satellite prn and status (T = track, A = acquire)
16 A 13 T 20 T 18 T 07 T 12 T list continued
......@@ -229,7 +234,7 @@ UTC leap-second information
These data determine when the next leap second is to occur. The exact
method to use is obscure.
49234 60548.847 127.127.10.1 93:247:16:48:52.818 UTC
49234 60548.847 AUSTRON(1) 93:247:16:48:52.818 UTC
-1.2107E-08 A0 term (s)
-1.2790E-13 A1 term (s)
......@@ -240,7 +245,3 @@ method to use is obscure.
+4.0000E+00 day number for future leap (days)
+9.0000E+00 future leap seconds (s)
David L. Mills
University of Delaware
mills@udel.edu
23 October 1993
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment