Greyware Automation Products, Inc.
Greyware Automation Products, Inc.   
     Home    Products    Store    Downloads    Customer Service    Site Search    
Log in  or   Create an account now -- FREE!        
Domain Time II > v5 > Configuration > Client > ntpd Compatibility

Pricing   Buy Now

Download
30-Day Trial Version
ntpd Compatibility  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).

  • Domain Time is not a port of ntpd. Because Domain Time does not share a code base with ntpd, it is not vulnerable to amplification attacks or the recently discovered ntpd security vulnerabilities. These security problems are not part of the NTP protocol itself; they are peculiar to ntpd's implementation.

  • Although both programs use similar statistical methods to eliminate outliers and calculate the intersection of sample sets, Domain Time does not use the canonical ntpd algorithms or keep individual peer statistics in the same way ntpd does. Domain Time uses more sophisticated methods of clock steering, especially on those versions of Windows that have inherent clock control issues (i.e. Server 2008/Win7/Vista). Domain Time also is able to compare samples obtained using multiple protocols to improve sample accuracy and offset calculations, as well as provide time to a wider range of clients.

  • ntpq-compatible responses can be disabled if desired by setting the following registry value to True (Windows versions only):

      HKEY_LOCAL_MACHINE\SOFTWARE\Greyware\Domain Time Server[Client]\Parameters\NTP Query Disabled

    Turning off ntpq responses does not disable the ability to obtain the time using NTP (the protocol).

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. 64 0.146 0.167 0.000 
    -132.163.4.103  .ACTS. 64 24.091  2.259 0.000 
    +71.252.193.25  192.168.1.3 64 5.094 0.432 0.000 
    +71.252.193.12  192.168.1.3 64 5.374 0.806 0.000 
    129.6.15.29  .ACTS. 64 101.833 36.432 0.000 
    -50.97.210.169  209.51.161.238 64 42.283 -0.587 0.000 
    128.4.1.1  .PPS. 64 49.651 -0.013 0.000 
    216.239.35.4  71.79.79.71 64 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  
    ==================================================================== 
    1552 f634 yes yes ok sys.peer reachable 3
    1553 9314 yes yes none outlyer reachable 1
    1554 9414 yes yes none candidat reachable 1
    1555 9414 yes yes none candidat reachable 1
    1556 901d yes yes none reject  1
    1557 9314 yes yes none outlyer reachable 1
    1558 9014 yes yes none reject reachable 1
    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.

 


My Account  |   Contact Us  |   Privacy Policy  |   Printer-Friendly Version
 
Copyright © 1995-2024 Greyware Automation Products, Inc.  All Rights Reserved
All Trademarks mentioned are the properties of their respective owners.