[Git][NTPsec/ntpsec][master] 2 commits: Save a pointer to info on how to play with wildcard addresses.

Eric S. Raymond gitlab at mg.gitlab.com
Wed Mar 22 10:31:03 UTC 2017


Eric S. Raymond pushed to branch master at NTPsec / ntpsec


Commits:
fc1ea1b4 by Eric S. Raymond at 2017-03-22T06:30:52-04:00
Save a pointer to info on how to play with wildcard addresses.

- - - - -
13e2b4d6 by Eric S. Raymond at 2017-03-22T06:30:52-04:00
Documentation polishing.

- - - - -


3 changed files:

- devel/TODO
- docs/ntpspeak.txt
- include/ntp_fp.h


Changes:

=====================================
devel/TODO
=====================================
--- a/devel/TODO
+++ b/devel/TODO
@@ -2,11 +2,6 @@
 
 == Checklist for a quality 1.0 release ==
 
-=== Code ===
-
-* All the code relating to iteration over interfaces can and should be removed
-  in favor of binding to wildcard addresses.
-
 === Testing ===
 
 * We need to live-test various refclocks.  It would be nice
@@ -83,6 +78,10 @@ Neither is ideal, easy pickings for someone to code on.
   (and multiple inbound NTP connections, and a hole in your firewall) even when
   it has a known-good local timesource like a GPS.  This should be fixed.
 
+* All the code relating to iteration over interfaces can and should be removed
+  in favor of binding to wildcard addresses.  Information on how to do this
+  us here: https://blog.powerdns.com/2012/10/08/on-binding-datagram-udp-sockets-to-the-any-addresses/
+
 * We could open only V6 sockets and allow them to handle mapped PV4 addresses,
   as described at http://man7.org/linux/man-pages/man7/ipv6.7.html
 


=====================================
docs/ntpspeak.txt
=====================================
--- a/docs/ntpspeak.txt
+++ b/docs/ntpspeak.txt
@@ -34,6 +34,10 @@
   Old name for the PPS driver.  Origin lost in the mists of history,
   but probably related in some way to cesium atomic clocks.
 
+[[cycle]] cycle::
+  An <<era>>; code comments sometimes use tjis term to emphasize that
+  modular arithmetic is going on.
+
 [[drift]] drift::
   In an NTP context, drift refers to the frequency offset of a clock crystal
   in an NTP host that causes the system time to slowly drift.  It is
@@ -53,6 +57,19 @@
   and asymmetric network delays between server and client, but firmware
   bugs in GPS receivers have produced falsetickers.
 
+[[epoch]] epoch::
+  1. The zero date of an NTP era.  The "prime epoch" (of era 0) was
+  1900-00-00T00:00:00 in proleptic UTC (leap second correction was not
+  introduced until 1972). 2. Other calendar systems have other
+  definitions; notably, the Unix epoch is 1970-00-00T00:00:00.
+
+[[era]] era::
+  One complete revolution of a 64-bit NTP 64-bit timestamp; approximately
+  136 years. Eras are numbered from 0, but this era number is not
+  represented internally in NTP code because modular-arithmetic
+  trickery is used to deduce the nearest time that could fit a given
+  timestamp.
+
 [[fudge]] fudge::
   Can have one of two senses.  Either (1) an offset configured for a
   <<refclock>> or server to correct its time, reversing a fixed or
@@ -97,7 +114,7 @@
    interface.
 
 [[holdover]] holdover::
-   In connection with a <<GPSD0>> or <<time radio>> that may lose
+   In connection with a <<GPSDO>> or <<time radio>> that may lose
    signal from its time source, holdover is its ability to continue
    delivering accurate time from an internal oscillator. Due to
    <<drift>> in the oscillator, accuracy drops as holdover time (time


=====================================
include/ntp_fp.h
=====================================
--- a/include/ntp_fp.h
+++ b/include/ntp_fp.h
@@ -13,7 +13,7 @@
  * NTP uses two fixed point formats.
  *
  * The first (l_fp) is the "long" format and is 64 bits wide in units
- * of 1/2e32 seconds (which is between 232 and 233 decimal
+ * of 1/2^32 seconds (which is between 232 and 233 decimal
  * picoseconds).  The zero value signifies the zero date of the
  * current NTP era; era zero began on the date 1900-00-00T00:00:00 in
  * proleptic UTC (leap second correction was not introduced until
@@ -23,7 +23,7 @@
  * network byte order).  It is defined in RFC 5905 in Section 6 (Data
  * Types). In the on-the-wire context, it is always unsigned.
  *
- * When it is convenient to compute in float seconds, this type can
+ * When it is convenient to compute in seconds, this type can
  * be interpreted as a fixed-point float with the radix point between
  * bits 31 and 32. This is why there are macros to extract the low and
  * high halves.
@@ -32,7 +32,7 @@
  * context it is interpreted as signed and can only express offsets
  * up to a half cycle. Offsets are normally much, much smaller than that;
  * for an offset to have a value even as large as 1 second would be 
- * highly unusual.
+ * highly unusual after ntpd initialization.
  *
  * Anyway, an l_fp looks like:
  *



View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/772c36d7e12b6075d134f33cd8a6d4c00029f033...13e2b4d69f2800ade1e8422c35673d72e1bc0de9
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/vc/attachments/20170322/a9a639fd/attachment.html>


More information about the vc mailing list