ntpd Compatibility
Domain Time II Client Version 5.2 |
This page discusses compatibility features Domain Time for Windows provides for administrators accustomed to using command-line utilities included with ntpd,
one of the more popular NTP time synchronization programs often used on Linux and other platforms. DTLinux can provide peerstats and loopstats only.
IMPORTANT: Note that NTP (the protocol) is not the same as ntpd (the program).
Like Domain Time, the ntpd daemon synchronizes time using the NTP protocol, however ntpd and Domain Time are different programs, with
different approaches to peering, clock steering and other operations. The ntpd package comes with a number of utilities such as ntpq that provide
statistical or other control or output. These utilties are not part of NTP (the protocol), but specific to ntpd (the program).
ntpdate
Domain Time Server answers ntpdate queries to allow for immediate localclock synchronization.
Domain Time Client does not.
ntpq
Domain Time has historically supported a subset of queries from ntpq. Until recently, however, the output could be confusing for
administrators who believed Domain Time was ntpd under the hood. In particular, Domain Time has never supported the concept
of a single sys.peer; all providers currently configured and available are used to create the set of samples, and the
"true time" is derived from statistical analysis of all the samples. This means that no one server necessarily is marked as
sys.peer; it also means that more than one could be marked this way.
As of version 5.2.b.20170101, Domain Time reorders its output for ntpq to conform more closely to what and an ntpd
administrator would expect to see. If more than one source is used to steer the clock, only the first is marked sys.peer;
the remainder are marked as candidates. If a source is consulted but not used, it will be marked sel_reject,
sel_outlier, or sel_falsetick, depending on which statistical anomaly eliminated the sample
(see the section Peer Status Word below).
ntpq> peers |
remote | refid | st | t | when | poll | reach | delay | offset | jitter |
================================================================================== |
*192.168.1.3 | .GPS. | 1 | u | 9 | 64 | 3 | 0.146 | 0.167 | 0.000 |
-132.163.4.103 | .ACTS. | 1 | u | 9 | 64 | 1 | 24.091 | 2.259 | 0.000 |
+71.252.193.25 | 192.168.1.3 | 2 | u | 9 | 64 | 1 | 5.094 | 0.432 | 0.000 |
+71.252.193.12 | 192.168.1.3 | 2 | u | 9 | 64 | 1 | 5.374 | 0.806 | 0.000 |
129.6.15.29 | .ACTS. | 1 | u | 9 | 64 | 1 | 101.833 | 36.432 | 0.000 |
-50.97.210.169 | 209.51.161.238 | 2 | u | 9 | 64 | 1 | 42.283 | -0.587 | 0.000 |
128.4.1.1 | .PPS. | 1 | u | 9 | 64 | 1 | 49.651 | -0.013 | 0.000 |
216.239.35.4 | 71.79.79.71 | 2 | u | 9 | 64 | 1 | 32.222 | -4.622 | 0.000 |
In this report, three servers were used to steer the clock (marked with an asterisk or a plus sign in the first column).
Two servers were rejected as outliers (a minus sign in the first column), and the remainder failed the statistical tests
for other reasons. A more complete accounting of the standard deviation, standard error, and rejection reasons is
available from Domain Time's text log. Domain Time does not track jitter in the same fashion as ntpd does, so the jitter
column will always be 0.000.
ntpq> assoc |
ind | assID | status | conf | reach | auth | condition | last_event | cnt |
==================================================================== |
1 | 1552 | f634 | yes | yes | ok | sys.peer | reachable | 3 |
2 | 1553 | 9314 | yes | yes | none | outlyer | reachable | 1 |
3 | 1554 | 9414 | yes | yes | none | candidat | reachable | 1 |
4 | 1555 | 9414 | yes | yes | none | candidat | reachable | 1 |
5 | 1556 | 901d | yes | yes | none | reject | | 1 |
6 | 1557 | 9314 | yes | yes | none | outlyer | reachable | 1 |
7 | 1558 | 9014 | yes | yes | none | reject | reachable | 1 |
8 | 1559 | 901d | yes | yes | none | reject | | 1 |
This report shows more detail, including that the first server used symmetric authentication. The output of both commands
differs from ntpd's in one significant area: The "reach" column shown for peers, and the "cnt" column shown for associations,
refer to how many samples were taken from that particular server during the most recent time check event. Domain Time does not use
ntpd's concept of an 8-bit shift register to record reachability. A server that does not respond is not included in the output
at all, so it is not possible to shift a 0 into the rightmost bit of the count register. The "cnt" column displayed by a Domain Time
machine will be between 1 and 15 (0x01-0x0F, or O001-O017), because the Peer Status Word allots only 4 bits for the count.
The "reach" column will be between 1 and 255 (0x01-0xFF, O377) because the reach is calculated based on the number of
samples as if it were a proper shift-register. Since unreachables are never present, the only possible decimal values for
the "reach" column are 1, 3, 7, 15, 31, 63, 127, and 255. For machines using PTP as the time source, the reach will almost
always be 255 (0xFF, O377).
NTP Loopstats and Peerstats
As of version 5.2.b.20170101, Domain Time has added the ability to keep loopstats and peerstats files in ntpd's version 4 file format,
including symlinks to the current file (Symlinks are available on Windows versions only).
The default folder on Windows is C:\Program Files\Domain Time II\NTP Stats\, but
you may change this by editing this registry value:
HKEY_LOCAL_MACHINE\SOFTWARE\Greyware\Domain Time Server[Client]\Parameters\NTP Stats Folder
Changes to the log location take effect the next time a stat is generated. Symlinks will not be maintained if you use a UNC folder path,
or if the operating system is XP/2003.
The default log location on Linux is the /var/log/domtime directory.
On Windows versions of Domain Time, you may enable or disable peerstats and loopstats from the Domain Time Control Panel applet's Logs and Status
page. On DTLinux, they are enabled in the dtlinux.conf file. The loopstats file and the peerstats file follow the log roll settings for Text Log Archiving. The filename format
is just "loopstats" and "peerstats" if log roll is set to never; "loopstats.yyyymmdd" and "peerstats.yyyymmdd" if set to daily;
"loopstats.yyyyWn" and "peerstats.yyyyWn" if set to weekly; and "loopstats.yyyymm" and "peerstats.yyyymm" if set to monthly.
Symlinks are only provided on Windows versions. When the log roll is set to never, no symlink is generated, because the bald filename is already the name the symlink would have.
For other log rolling, symlinks for "loopstats" and "peerstats" are generated to point to the current daily, weekly, or monthly file.
The file format conforms to the documentation at ntp.org: http://doc.ntp.org/4.2.4/monopt.html
They are text files, each line terminated by a single LF, each field separated by a single space. Values that are inapplicable or inexpressible in ntpd's format are set to 0.0 and will never vary.
Domain Time keeps offsets and delay measurements in hectonanoseconds (tenths of a microsecond). There will always be exactly seven significant digits after the decimal point.
Note: The protocol used to obtain the time samples is irrelevant to loopstats and peerstats generation. If enabled, even Domain Time machines not using NTP at all will have compatible loopstats and peerstats files.
loopstats
The fields for loopstats, from left to right, are Modified Julian Day, Seconds.fractions past midnight UTC, time offset in seconds, frequency offset in PPM, RMS jitter in seconds, Allan deviation in PPM, and the exponent to which 2 should be raised to calculate the number of seconds between time checks.
Sample loopstats output:
57743 62933.576 0.0003477 0.0 0.0 0.0 6
57743 62994.486 -0.0000167 0.0 0.0 0.0 6
57743 63058.415 -0.0000837 0.0 0.0 0.0 6
Domain Time does not track frequency offset, RMS jitter, or Allan deviation in a way that can be expressed in the loopstats file,
so these three fields will always be 0.0. Domain Time tracks syntonicity, but this is not directly translatable into jitter
and deviation, especially if multiple protocols are used, or if one of them is PTP.
Additionally, Domain Time can be set to obtain the time at any interval, so the 6 in the final field (representing 26, or 64 seconds)
is not necessarily accurate. In the case above, Domain Time was set to check every 60 seconds, which is not directly representable
as a power of two. Domain Time rounds the output to the nearest power of two.
A loop, for Domain Time's purposes, corresponds to a time check event. One line will be written each time Domain Time checks with
its sources, or, in the case of PTP, summarizes the activity over the past n seconds. The schedule may be set to variable or fixed, and an unscheduled check may occur when a sync is signaled, either
internally or externally.
peerstats
The fields for peerstats are, from left to right, Modified Julian Day, Seconds.fractions past midnight UTC, the textual IP
address (dotted quad for IPv4; standard notation for IPv6) of the server, a four-digit hex number (without the leading 0x)
representing the Peer Status Word, followed by offset, delay, dispersion and RMS jitter, all in seconds.
Sample peerstats output:
57743 63118.483 192.168.1.3 F634 0.0000007 0.0001538 0.0 0.0
57743 63118.815 132.163.4.102 901D 0.0043135 0.0256912 0.0 0.0
57743 63118.820 71.252.193.25 9314 0.0002747 0.0043838 0.0 0.0
57743 63118.830 71.252.193.12 9314 0.0004952 0.0046928 0.0 0.0
57743 63121.370 50.97.210.169 9014 0.0000848 0.0392423 0.0 0.0
57743 63121.420 128.4.1.1 9014 0.0000686 0.0496711 0.0 0.0
57743 63121.452 216.239.35.4 901D -0.0046738 0.0322856 0.0 0.0
Domain Time does not calculate dispersion and RMS jitter in a format that can be represented in the peerstats file, so these two
fields will always be 0.0.
A peer, for Domain Time's purposes, is a configured or discovered server, regardless of protocol used, that provides time samples.
A peer that fails to provide a sample at a given loop will not have a line.
The Peer Status Word
The Peer Status Word shown either by ntpq or in the peerstats file, is documented at udel.edu:
https://www.eecis.udel.edu/~mills/ntp/html/decode.html#peer
Since Domain Time only includes peers that have provided time samples, the reach bit will usually be set. The only exception is if
Domain Time is using broadcast/multicast time sources (not including PTP), in which case the bcst bit will be set instead of reach.
Again, since Domain Time only includes peers that have provided time samples, either both auth and authenb bits
will be set, or both will be cleared. A server configured to use authentication that fails because of an authentication failure does
not provide a time sample, and will not appear in the list.
The config bit represents whether the time source was configured (i.e., in a list of servers Domain Time was told to use), or was
discovered by Domain Time in auto-configure mode. For PTP time sources, it is considered configured if the list of PTP masters is
restricted by IP or CIDR mask. If Domain Time follows the BMC without restriction, the source is considered discovered rather than
configured.
The only applicable codes, appearing in the last four bits, are reachable (the default), sys_peer, and popcorn.
|