[Git][NTPsec/ntpsec][master] 3 commits: Remove misleading comment; ENABLE_ASYMMETRIC is now gone.
Eric S. Raymond
gitlab at mg.gitlab.com
Thu Oct 6 01:29:48 UTC 2016
Eric S. Raymond pushed to branch master at NTPsec / ntpsec
7ea66ceb by Eric S. Raymond at 2016-10-05T21:29:41-04:00
Remove misleading comment; ENABLE_ASYMMETRIC is now gone.
- - - - -
a27f37e5 by Eric S. Raymond at 2016-10-05T21:29:41-04:00
Some crucial corrections about the system call interface.
- - - - -
ddaeb18a by Eric S. Raymond at 2016-10-05T21:29:41-04:00
Note on non-PLL performance.
- - - - -
4 changed files:
@@ -5,9 +5,10 @@
This software should build on any operating system conformant to
POSIX.1-2001 and ISO/IEC 9899:1999 (C99). In addition, the operating
system must have either a Linux-like adjtimex(2) call or a BSD-like
-ntp_adjtime(2) call. Also, it must support the IPv6 API defined in
-RFC2493 and RFC2553. Finally, it must support iterating over active
-UDP interfaces via getifaddrs(3) or some equivalent facility.
+ntp_adjtime(2) call or the older BSD adjtime(2) call. Also, it must
+support the IPv6 API defined in RFC2493 and RFC2553. Finally, it must
+support iterating over active UDP interfaces via getifaddrs(3) or some
There are some prerequisites. Libraries need the binary installed
to run and in addition, the development headers installed to build.
@@ -52,7 +52,8 @@ POSIX threads *are* considered part of the standardized API and may be used.
Here are the non-standardized AIs that may be used:
-* Linux-style adjtimex() or BSD-style ntp_gettime()/ntp_adjtime().
+* Linux-style adjtimex() or BSD-style ntp_gettime(2)/ntp_adjtime(), or
+ the older BSD adjtime(2).
* Berkeley sockets and the IPv6 API defined in RFC2493 and RFC2553.
@@ -168,7 +168,8 @@ quite a while before NTPsec removed it.
All of ntpd's clock management is done through four system calls:
clock_gettime(2), clock_settime(2), and either ntp_adjtime(2) or (on
-some systems, including Linux) adjtimex(2).
+some systems, including Linux) adjtimex(2), or the older BSD
The clock_gettime(2) and clock_settime(2) calls are standardized in
POSIX; ntp_adjtime(3) and adjtimex(2) are not, exhibiting some
@@ -181,9 +182,9 @@ left a trail of abandoned experiments behind it.
Older BSD systems read the clock using gettimeofday(2)
(in POSIX but deprecated) and set it using settimeofday(2),
-which was never standardized. There was also an adjtime(2)
-call similar to, but less powerful than, ntp_adjtime(2)/adjtimex(2).
-None of these calls are still used in NTPsec.
+which was never standardized. Neither of these calls are still
+used in NTPsec, though the equally ancient BSD adjtime(2) call
+is on systems without kernel PLL support.
Also, glibc (and possibly other C libraries) implement two other
related calls, ntp_gettime(3) and ntp_gettimex(3). These are not used
@@ -230,6 +231,13 @@ much faster convergence from a cold start.
a thin userspace wrapper around adjtimex(2). The ntp_adjtime(2)
implementation uses only a subset of adjtimex(2)'s capabilities.)
+The older BSD adjtime(2) is used for slewing as well, but doesn't
+assume a kernel-level PLL is available. Some platforms, like OpenBSD
+and Mac OS X, use only this call because they lack
+ntp_adjtime(2)/adjtimex(2). Without the PLL calls, convergence to
+good time is observably a lot slower and tracking will accordingly be
Deep-in-the weeds details about the kernel PLL from Hal Murray follow.
If you can follow these you may be qualified to maintain this code...
@@ -417,11 +417,6 @@ def cmd_configure(ctx, config):
if not ctx.options.disable_dns_retry:
ctx.define("ENABLE_DNS_RETRY", 1, comment="Retry DNS lookups after an initial failure")
- # There is an ENABLE_ASYMMETRIC that enables a section of the
- # protocol code having to do with handling very long asymmetric
- # delays, as in space communications. Likely this code has never
- # been enabled for production.
# This is true under every Unix-like OS.
ctx.define("HAVE_WORKING_FORK", 1, comment="Whether a working fork() exists")
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/5f82a4b61d0b8bfea7724835ffdb7e0071a9c3f7...ddaeb18aafca7134d416d52315f8c01b06a90940
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vc