[Git][NTPsec/ntpsec][master] 23 commits: more typo fixes etc
Gary E. Miller
gitlab at mg.gitlab.com
Sat Aug 11 00:37:15 UTC 2018
Gary E. Miller pushed to branch master at NTPsec / ntpsec
Commits:
006f96b9 by Paul Theodoropoulos at 2018-08-07T22:22:27Z
more typo fixes etc
- - - - -
f0f97aed by Paul Theodoropoulos at 2018-08-07T23:10:02Z
typos; wordsmithing; other fixes
- - - - -
99e19c43 by Paul Theodoropoulos at 2018-08-08T17:19:45Z
conform remaining urls to available https
- - - - -
c1c05768 by Paul Theodoropoulos at 2018-08-08T17:42:43Z
another stab at stratum
- - - - -
c545691c by Paul Theodoropoulos at 2018-08-08T18:01:15Z
clarify pool server explanation
- - - - -
f2c172b1 by Paul Theodoropoulos at 2018-08-08T21:20:19Z
addition typo fixes, cleanup, style adjustments, etc
- - - - -
f6b0f34f by Paul Theodoropoulos at 2018-08-08T21:51:10Z
one more try on "pool" entry
- - - - -
7f55413d by Paul Theodoropoulos at 2018-08-08T21:54:19Z
rm final slashes, correct pool url
- - - - -
0064dfe9 by Paul Theodoropoulos at 2018-08-08T22:23:17Z
Merge branch 'textual-fixes'
all fixes in one.
- - - - -
0d44c9c0 by Paul Theodoropoulos at 2018-08-09T19:26:01Z
add netdata monitoring
- - - - -
c3a9b704 by Paul Theodoropoulos at 2018-08-09T20:07:01Z
pps textual fixes
- - - - -
5f8c9dbb by Paul Theodoropoulos at 2018-08-09T21:02:12Z
please vet temperature commentary, perhaps best elsewhere
- - - - -
04ae56fb by Paul Theodoropoulos at 2018-08-09T21:26:30Z
typos, wordsmith
- - - - -
512b0662 by Paul Theodoropoulos at 2018-08-09T21:29:29Z
add pointer to pool discussion in quick-start
- - - - -
864acf42 by Paul Theodoropoulos at 2018-08-10T22:56:25Z
three ways of utilizing pps
- - - - -
4476a3eb by Paul Theodoropoulos at 2018-08-11T00:22:07Z
Merge branch 'master' of gitlab.com:NTPsec/ntpsec
- - - - -
80aeb81c by Paul Theodoropoulos at 2018-08-11T00:23:03Z
add netdata monitoring
- - - - -
76a756e9 by Paul Theodoropoulos at 2018-08-11T00:23:03Z
pps textual fixes
- - - - -
85a81635 by Paul Theodoropoulos at 2018-08-11T00:23:03Z
please vet temperature commentary, perhaps best elsewhere
- - - - -
8d7b8cea by Paul Theodoropoulos at 2018-08-11T00:23:03Z
typos, wordsmith
- - - - -
2bd61bc8 by Paul Theodoropoulos at 2018-08-11T00:23:03Z
add pointer to pool discussion in quick-start
- - - - -
b832695e by Paul Theodoropoulos at 2018-08-11T00:23:03Z
three ways of utilizing pps
- - - - -
88079e71 by Paul Theodoropoulos at 2018-08-11T00:24:31Z
Merge branch 'more-text-fixes' of gitlab.com:anastrophe/ntpsec into more-text-fixes
- - - - -
6 changed files:
- docs/discipline.txt
- docs/ntpspeak.txt
- docs/outside-tools.txt
- docs/pps.txt
- docs/quick.txt
- docs/rollover.txt
Changes:
=====================================
docs/discipline.txt
=====================================
@@ -18,8 +18,8 @@ parameter, hybrid phase/frequency-lock feedback loop. It is an
intricately crafted algorithm that automatically adapts for optimum
performance while minimizing network overhead. Operation is in two
modes, phase-lock loop (PLL), which is used at poll intervals below the
-Allan intercept, by default 2048 s, and frequency-lock loop (FLL), which
-is used above that.
+Allan intercept - by default 2048 s - and frequency-lock loop (FLL),
+which is used above that.
image::pic/discipline.gif[align="center"]
@@ -70,7 +70,7 @@ intervals are expressed as exponents of 2. By construction, the time
constant exponent is five times the poll interval exponent. Thus, the
default poll exponent of 6 corresponds to a poll interval of 64 s and a
time constant of 2048 s. A change in the poll interval changes the time
-constant by a corresponding amount.. The Nyquist criterion requires the
+constant by a corresponding amount. The Nyquist criterion requires the
sample interval to be not more than half the time constant or 1024 s.
The clock filter guarantees at least one sample in eight poll intervals,
so the sample interval is not more than 512 s. This would be described
@@ -133,8 +133,9 @@ If left running continuously, an NTP client on a fast LAN in a home or
office environment can maintain synchronization nominally within one
millisecond. When the ambient temperature variations are less than a
degree Celsius, the clock oscillator frequency is disciplined to within
-one part per million (PPM), even when the clock oscillator native
-frequency offset is 100 PPM or more.
+one part per million (PPM), even when the clock oscillator native frequency
+offset is 100 PPM or more. A temperature-compensated crystal oscillator,
+if available, will be even less affected by thermal influences.
For laptops and portable devices when the power is turned off, the
battery backup clock offset error can increase as much as one second per
@@ -143,7 +144,7 @@ offset and oscillator frequency errors must be resolved by the clock
discipline algorithm, but this can take several hours without specific
provisions.
-The provisions described in this section insure that, in all but
+The provisions described in this section ensure that, in all but
pathological situations, the startup transient is suppressed to within
nominal levels in no more than five minutes after a warm start or ten
minutes after a cold start. Following is a summary of these provisions.
@@ -180,7 +181,7 @@ clock. The +iburst+ option of the link:assoc.html#burst[+server+]
command changes the behavior at restart and is recommended for
client/server configurations. When this option is enabled, the client
sends a volley of six requests at intervals of two seconds. This usually
-insures a reliable estimate is available in about ten seconds before
+ensures a reliable estimate is available in about ten seconds before
setting the clock. Once this initial volley is complete, the procedures
described above are executed.
=====================================
docs/ntpspeak.txt
=====================================
@@ -10,7 +10,7 @@
[[ACTS]] ACTS::
https://www.nist.gov/pml/time-and-frequency-division/services/automated-computer-time-service-acts[NIST
Automated Computer Time Service]. NIST provides a civil time reference for
- computers equipped with analog modems that can dial to its phone
+ computers equipped with analog modems that can dial in to its phone
lines. Due to variability of delays in the analog phone network
accuracy is not very good, around 4 milliseconds compared to
around a microsecond for <<PPS>>. But the service is still
@@ -45,14 +45,14 @@
nominal frequency. It changes, slowly, in response to environmental
factors (mainly ambient temperature). ntpd measures drift by
sampling the clock and performing clock recovery against a
- phase-locked loop. The drift measurement is occasionally stored
+ phase-locked loop. The drift measurement can be stored and updated
locally to a drift file so that when ntpd is stopped and restarted
it doesn't have to go through the entire resampling and resynchronization
process before providing reliable time.
[[falseticker]] falseticker::
<<Mills-speak>> for a timeserver identified as not
- reliable by statistical filtering. Usually this does not imply any
+ reliable by statistical filtering. Usually this does not imply a
problem with the timeserver itself but rather with highly variable
and asymmetric network delays between server and client, but firmware
bugs in GPS receivers have produced falsetickers.
@@ -64,7 +64,7 @@
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
+ One complete revolution of an 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
@@ -87,13 +87,13 @@
now long gone, but have left a few traces in the NTP codebase.
[[GPS]] GPS::
- Global Positioning System; also, "a GPS" is a radio receiver
+ Global Positioning System; in common parlance "a GPS" is a radio receiver
designed to get position and time fixes from the system. GPS fixes
are derived from spherical trigonometry using the precisely known
positions of satellites in a geocentric coordinate system. GPS
also provides time service; those that emit <<PPS>> are suitable
as clock sources for Stratum 1 timeservers. In timekeeping, the
- term is used to refer not only to the US original GPS system,
+ term is used to refer not only to the original U.S. GPS system,
but newer constellations that work on the same principles, such
as ГЛОНАСС (the Russian GLONASS), 北斗 (the Chinese BeiDou-2),
and the EU's Galileo.
@@ -108,7 +108,7 @@
GPS antenna.
[[GPSD]] GPSD::
- The http://www.catb.org/gpsd/[GPS Daemon], an open-source device
+ The http://www.catb.org/gpsd[GPS Daemon], an open-source device
manager for GPSes and other geodetic sensors. Frequently used as
a clock source by Stratum 1 sites via the link:driver_shm.html[SHM]
interface.
@@ -140,16 +140,16 @@
serial link is called "in-band time" to contrast it with the
out-of-band <<PPS>> signal. Abbreviated IBT. Seldom useful
by itself as it tends to have a large random wander from top
- of second. It is however, useful as a count of seconds.
+ of second. However, it is useful as a count of seconds.
[[leap second]] leap second::
Because the earth's rotation varies in irregular ways (gradually
- slowing due to tidal drag) and the second is now defined in
- absolute terms rather than as a fraction of day length, keeping
+ slowing due to tidal drag among other forces) and the second is now defined
+ in absolute terms rather than as a fraction of day length, keeping
time of day synchronized with mean solar time requires occasional,
unpredictable insertions of a standard second in the calendar. Leap
second notifications are issued as Bulletin C by the
- http://www.iers.org/IERS/EN/Home/home_node.html[International
+ https://www.iers.org/IERS/EN/Home/home_node.html[International
Earth Rotation Service] when required, and obeyed by national time
authorities. The current leap-second offset is automatically
propagated through the <<GPS>> system.
@@ -169,17 +169,17 @@
include <<falseticker>>, <<proventic>>, and <<truechimer>>. The
close-to-definitive reference is
https://lists.ntp.org/pipermail/questions/2007-December/016592.html[The
- NTP dictionary], though not all those terms are still in use.
+ NTP dictionary], though not all of those terms are still in use.
[[mode 6]] mode 6::
Mode 6 is a control protocol used to get various kinds of
status information from a running ntpd and configure it on
- the fly. So called from the value 6 (0110) in the packet mode
+ the fly. So-called from the value 6 (0110) in the packet mode
field. It is described in detail mode6.html[here].
[[NIST]] NIST::
- http://www.nist.gov/[National Institute of Standards and
- Technology]. The civilian national time authority of the USA;
+ https://www.nist.gov[National Institute of Standards and
+ Technology]. The civilian national time authority of the U.S.;
runs <<WWVB>>. Responsible for keeping U.S. civil time
coordinated with UTC. Civil <<NIST>> and military <<USNO>>
time agree to within nanoseconds.
@@ -187,7 +187,7 @@
[[NTP-classic]] NTP Classic::
The original reference implementation of NTP by Dave Mills, later
maintained by the Network Time Foundation. It is available at
- http://www.ntp.org/ . NTPsec forked from it on June 6th, 2015.
+ http://www.ntp.org . NTPsec forked from it on June 6th, 2015.
[[nonce]] nonce::
An arbitrary number that may only be used once. A random or
@@ -229,10 +229,16 @@
[[pool]] pool::
In an NTP context, "the pool" is usually the
- http://www.pool.ntp.org/en/[NTP Pool Project], a collection of
- thousands of NTP servers accessible through DNS servers that hand
- out "nearby" server addresses from the pool. These servers are
- usually run by volunteers, and available via well-known DNS names.
+ https://www.ntppool.org/en[NTP Pool Project], a collection of
+ thousands of NTP servers around the world that you can use to keep
+ time. The DNS names are designed to keep the timeservers you select
+ relatively "close" to you on the internet, with varying degrees of
+ specificity, e.g. using north-america.pool.ntp.org may connect you
+ to timeservers from Canada to Panama, while us.pool.ntp.org is more
+ likely to connect you to timeservers within the continental U.S..
+ These pool timeservers are usually run by volunteers. See
+ the https://docs.ntpsec.org/latest/quick.html#pool[Quick Start for
+ Client Configurations] for a more in-depth discussion of pools.
[[proventic]] proventic:: <<Mills-speak>> for "the transitive
completion of the authentication relationship", defined in RFC 5906.
@@ -247,14 +253,13 @@
[[stratum]] stratum::
A "stratum" is a layer in the hierarchy of time servers. A
- <<refclock>> is considered stratum 0; a computer directly attached to
+ <<refclock>> is stratum 0; a computer directly attached to
a refclock is stratum 1; and a client served by a stratum N is
stratum N+1. Often capitalized, especially when referring to all
- members of a stratum. While strata up to 15 are defined, it is
- unusual to see a public timeserver with stratum greater than 3,
- and thus almost all NTP clients are at Stratum 4 or lower.
- Notice that a 'lower' stratum is closer to the reference clock than
- a 'higher'.
+ members of a stratum. The larger the number, the further away from
+ the source clock, thus the less accurate. Stratum 16 is the maximum, and
+ indicates a device that is unreachable and unsynchronized. The majority
+ of public timeservers are Stratum 1 and Stratum 2.
[[time-radio]] time radio::
A radio receiver specialized for picking up accurate time reference
@@ -275,7 +280,7 @@
the server itself than it is of favorable network topology.
[[USNO]] USNO::
- http://www.usno.navy.mil/USNO[The United States Naval Observatory],
+ https://www.usno.navy.mil/USNO[The United States Naval Observatory],
one of the two U.S. national time authorities and the source of the
U.S. military time reference, now delivered primarily by GPS
signals. U.S. civil <<NIST>> and military <<USNO>> time agree to
=====================================
docs/outside-tools.txt
=====================================
@@ -17,6 +17,7 @@ include::includes/hand.txt[]
* link:#introduction[Introduction]
* link:#wireshark[Wireshark]
* link:#nagios[Nagios]
+* link:#netdata[Netdata]
'''''
@@ -42,6 +43,13 @@ The https://www.nagios.org/[Nagios] monitoring suite has native
support for querying NTP servers. The 'check_ntp_peer' and
'check_ntp_time' programs may be of particular interest.
+[[netdata]]
+== Netdata ==
+
+The https://github.com/firehol/netdata/wiki[Netdata] monitoring
+solution has native support for realtime monitoring of ntpd,
+among a vast number of other system metrics.
+
'''''
include::includes/footer.txt[]
=====================================
docs/pps.txt
=====================================
@@ -67,24 +67,24 @@ driver, and may be added to other drivers in future. Alternatively,
the PPS driver described on the link:driver_pps.html[PPS Clock
Discipline] page can be used. It operates in conjunction with another
source that provides seconds numbering. The selected source is
-designate a prefer peer, as using the +prefer+ option, as described on
+designated as a 'prefer peer' using the +prefer+ option, as described on
the link:prefer.html[Mitigation Rules and the +prefer+ Keyword]
page. The prefer peer is ordinarily the radio clock that provides the
PPS signal, but in principle another radio clock or even a remote
-Internet server could be designated preferred Note that the +pps+
+Internet server could be designated preferred. Note that the +pps+
configuration command has been obsoleted by this driver.
[[use]]
== Using the Pulse-per-Second (PPS) Signal ==
-The PPS signal can be used in either of two ways, one using the NTP
-grooming and mitigation algorithms and the other using the kernel PPS
+The PPS signal can be used in three ways: using the NTP
+grooming and mitigation algorithms, or using the kernel PPS
signal support described in the link:kern.html[Kernel Model for
-Precision Timekeeping] page. The presence of kernel support is
-automatically detected during the NTP build process and supporting code
-automatically compiled. In either case, the PPS signal must be present
-and within nominal jitter and wander tolerances. In addition, the prefer
-peer must be a truechimer; that is, survive the sanity checks and
+Precision Timekeeping] page, or via the shared-memory interface. The presence
+of kernel support is automatically detected during the NTP build process and
+supporting code automatically compiled. Regardles of mechanism, the PPS signal
+must be present and within nominal jitter and wander tolerances. Additionally,
+the prefer peer must be a truechimer; that is, survive the sanity checks and
intersection algorithm. Finally, the offset of the system clock relative
to the prefer peer must be within ±0.5 s. The kernel maintains a
watchdog timer for the PPS signal; if the signal has not been heard or
@@ -92,11 +92,12 @@ is out of tolerance for more than some interval, currently two minutes,
the kernel discipline is disabled and operation continues as if it were
not present.
-An option flag in the driver determines whether the NTP algorithms or
-kernel support is enabled (if available). For historical reasons, the
-NTP algorithms are selected by default, since performance is
-generally better using older, slower systems. However, performance is
-generally better with kernel support using newer, faster systems.
+An option flag in the driver determines whether the NTP algorithms, the
+kernel support, or the shared-memory interface is enabled (depending upon
+availability). For historical reasons, the NTP algorithms are selected by
+default, since performance is generally better when using older, slower
+systems. However, performance is generally better with kernel support or
+shared-memory support when using newer, faster systems.
'''''
=====================================
docs/quick.txt
=====================================
@@ -51,7 +51,7 @@ address-allocation time to use the NTP servers provided by DHCP.
NTPsec, unlike legacy versions, can also be configured using an
Apache-style directory /etc/ntp.d of configuration-file segments.
-This is intended to make like easier for software configurators, which
+This is intended to make life easier for software configurators, which
can write independent segments rather than having to do the kind of
edit-in-place on a flat ntp.conf that comes naturally to a human.
@@ -127,8 +127,8 @@ server 2.ubuntu.pool.ntp.org
server 3.ubuntu.pool.ntp.org
------------------------------------------------------------------
-Multiple declarations of individual pool servers are not the best you can
-do; they're a workaround for a historical bug in NTP Classic. It's
+Multiple declarations of individual pool servers is not the best
+method; they're a workaround for a historical bug in NTP Classic. It's
better to say
------------------------------------------------------------------
@@ -227,7 +227,7 @@ accurate time, provided it has link:ntpspeak.html[PPS] capability.
want check servers from the pool.)
The easiest way to arrange this is by installing
-http://catb.org/gpsd/[GPSD] to watch the GPS, and configuring your
+http://catb.org/gpsd[GPSD] to watch the GPS, and configuring your
+ntpd+ to accept time from it. It is also possible to do this with
native +ntpd+ drivers (nmea, trimble, oncore), though these are less
flexible and a bit more difficult to configure.
=====================================
docs/rollover.txt
=====================================
@@ -22,26 +22,26 @@ lifetime of the universe (or whatever portion of it concerns you).
On real-world hardware you will seldom be that lucky.
This page discusses calendar cycles related to NTP, the ways they
-interact, the consequences of rollover, and common workarounds for
+interact, the consequences of rollover and common workarounds for
rollover problems.
[[terminology]]
== Terminology ==
Every calendar cycle has at least three basic properties: a start date
-(usually referred to a solar astronomical date in the Gregorian
+(usually referenced to a solar astronomical date in the Gregorian
calendar), a unit (such as seconds) and a rollover time or cycle
length in that unit. It also matters what the calendar does about
leap seconds.
As an important example, the basic time representation used on
computers running Unix has a start date of 1970-01-01T00:00:00
-(midnight of Janary 1st 1970), a unit of seconds, and a rollover time
+(midnight of January 1st 1970), a unit of seconds and a rollover time
of either 2^31^ seconds or 2^63^ seconds, depending on the word size
of the hardware. Negative times represent seconds before the start
date.
-The start date is often called the "epoch", and a rollover period may
+The start date is often called the "epoch" and a rollover period may
be called an "era". Beware that eras are often numbered zero-origin;
it is likely that Unix software will refer to dates immediately before
the 2038 rollover as "era 0", not "era 1".
@@ -65,7 +65,7 @@ are so often used as primary time sources).
A well-known historical rollover problem was "Y2K", which derived from
the use of two-digit decimal year counters in mainframe software
-(written when storage was so extensive that longer counters would have
+(written when storage was so limited that longer counters would have
been dramatically more expensive). Expensive preparation and
mitigation work prevented any major disasters in the year 2000, but
this was in part because there were many fewer vulnerable systems than
@@ -91,7 +91,7 @@ such as Spectracom's "Type 2".
There is an internal workaround to deal with two-digit dates in
{ntpdman}, but it relies on the system clock being at least roughly
correct - it won't work (for example) at boot time if the clock
-has been trashed or zeroed due to a failed battery backup, and
+has been trashed or zeroed due to a failed battery backup and
you have no remote check peers yet.
Warnings have been attached to the documentation of NTP clock drivers
@@ -118,7 +118,7 @@ The possibility of stutter or skip also means that in order to compute
elapsed time in seconds between two Unix times, you need to know
the leap-second offset at each time. It is not guaranteed that
these offsets are the same if the interval crosses midnight at the
-end of any calendar month. To date in 2017, IERS (the International
+end of any calendar month. To date in 2018, IERS (the International
Earth Rotation service) has performed all corrections just after
midnight of June 31 and December 31 respectively.
@@ -183,8 +183,8 @@ to compose this with message data to report time at subsecond
precision. Many, however, do not, and those that do are often
inaccurate; consumer-grade hardware often has jitter of over a tenth
of a second (100ms). On the other hand, carefully designed GPSes
-easily deliver 1ms accuracy, and some do 20 times better than that. A
-more detailed discussion of accuracy budgets see the
+easily deliver 1ms accuracy, and some do 1000 times better than that. For
+a more detailed discussion of accuracy budgets see the
http://www.catb.org/gpsd/time-service-intro.html[Introduction to Time
Service].
@@ -212,11 +212,11 @@ but rather the behavior near GPS and century rollovers.
To yield a UTC date, the weeks+second information from the GPS satellites
has to be used as an offset to a base date.
-The most naive way to do this would to simply use the zero date of the
+The most naive way to do this would be to simply use the zero date of the
current GPS era (1024-week cycle) as the base. Some very early GPS
equipment seems to have worked this way, but it has the drawback that
the device time-warps at the next GPS era rollover - which, if your
-device first ship is only a few years before that rollover, is a
+device first shipped only a few years before that rollover - is a
serious drawback.
There is a relatively simple way to extend the useful life of a GPS
@@ -224,7 +224,7 @@ used as a clock. That is to choose a pivot date in GPS weeks. When
your device reports a week number *before* the pivot, you assume that
a GPS rollover has occurred and add 1024 weeks to the base date.
-This technique will postpones time-warping to a full 1024 weeks after
+This technique will postpone time-warping to a full 1024 weeks after
the pivot date - which the vendor typically makes the release date
of the device firmware. But it won't do any better than that; without the
ability to change the base date, the device will ship incorrect
@@ -233,7 +233,7 @@ have that ability; most do not.
This is where careless, low-budget design begins to matter. GPS vendors
do not document even the fact that they use base or pivot dates, let
-alone what the base and pivot dates for their devices are. As of 2017,
+alone what the base and pivot dates for their devices are. As of 2018,
NTP's developers do not know of any devices for which you can even
query these parameters, let alone set them. The best you can generally
do (and on only some devices) is get the firmware release date; from this,
@@ -250,7 +250,7 @@ manager daemon that shares some developers with NTPsec, works around a
lot of the general messiness, but can't solve this problem
because the device capabilities to address it are simply absent.
-Finally, when you buy a GPS you do not know - and often will not be
+Finally, when you buy a GPS device, you do not know - and often will not be
able to discover - how far in the past its hidden pivot date is. This
means that time service operators using a GPS as a local Stratum 0
need to be aware of the possibility that their device could roll over
@@ -274,9 +274,9 @@ For purposes of this discussion, a 'resolved' timestamp is one that
has been mapped from a 32-bit seconds offset in some era to a full
64-bit timestamp implicitly based in some known era.
-When {ntpdman} receives a unresolved timestamp from an upstream server
+When {ntpdman} receives an unresolved timestamp from an upstream server,
that timestamp could be based in any era prior to the current
-wall-clock date - but, by definition, we may not know the wall-clock
+wall-clock date - but by definition we may not know the wall-clock
date with confidence yet (not having achieved sync).
To resolve this ambiguity, NTP also uses an internal pivot date. It
@@ -289,7 +289,7 @@ is within a half-cycle of a rollover time resolve to either the
previous or the next era.
An {ntpdman} instance's pivot date will be the date it was compiled
-and built.
+and built.
It is fairly easy to see that this guarantees correct resolution if the
pivot dates of the communicating ntpds are within a half-cycle
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/86de22020e873a542e85364122c52a6c79cdb941...88079e7169b974754a283aee01f0b9f0249796f4
--
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/86de22020e873a542e85364122c52a6c79cdb941...88079e7169b974754a283aee01f0b9f0249796f4
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/vc/attachments/20180811/82e0d9d5/attachment-0001.html>
More information about the vc
mailing list