[Git][NTPsec/ntpsec][master] 2 commits: Added "atom", "in-band time" and "popcorn spike" to glossary.
Eric S. Raymond
gitlab at mg.gitlab.com
Fri Jul 1 19:04:01 UTC 2016
Eric S. Raymond pushed to branch master at NTPsec / ntpsec
Commits:
2c970b33 by Eric S. Raymond at 2016-07-01T14:59:03-04:00
Added "atom", "in-band time" and "popcorn spike" to glossary.
- - - - -
b20dd2b5 by Eric S. Raymond at 2016-07-01T15:02:12-04:00
STI -> IBT. Apparently perly didn't know the common term for this.
- - - - -
3 changed files:
- docs/driver_gpsd.txt
- docs/ntpspeak.txt
- ntpd/refclock_gpsd.c
Changes:
=====================================
docs/driver_gpsd.txt
=====================================
--- a/docs/driver_gpsd.txt
+++ b/docs/driver_gpsd.txt
@@ -48,9 +48,9 @@ of _GPSD_!) Running without TOFF objects has a negative impact on the
jitter and offset of the serial timing information; if possible, a
version of _GPSD_ with support for TOFF objects should be used.
-The acronym [underline]#STI# is used here as a synonym for _serial
-time information_ from the data channel of the receiver, no matter
-what objects were used to obtain it.
+The acronym [underline]#IBT# is used here as a synonym for "in-band
+time" from the data channel of the receiver, no matter what objects
+were used to obtain it.
== Naming a Device ==
@@ -83,10 +83,10 @@ A few operation modes can be selected with the mode word.
|===========================================================================
3+|The Mode Word
|Bits |Value |Description
-.4+<.>|0..1 | 0 |STI (serial time information) only operation. This mode is affected by the timing
+.4+<.>|0..1 | 0 |IBT only operation. This mode is affected by the timing
stability of whatever protocol is used between the GPS and GPSD
-Running on STI only is not recommended in general. Possible use cases include:
+Running on IBT only is not recommended in general. Possible use cases include:
* The receiver does not provide a PPS signal.
* The receiver _does_ provide a PPS signal and the secondary PPS unit is used.
@@ -94,8 +94,8 @@ Running on STI only is not recommended in general. Possible use cases include:
* You have other time sources available and want to establish a useful
fudge value for +time2+.
| 1 |Strict operation. This mode needs a valid PPS and a valid
-STI to combine the absolute time from the STI with the time stamp from
-the PPS record. Does not feed clock samples if no valid PPS+STI pair is available.
+IBT to combine the absolute time from the IBT with the time stamp from
+the PPS record. Does not feed clock samples if no valid PPS+IBT pair is available.
This type of operation results in an ordinary clock with a very low
jitter as long as the PPS data is available, but the clock fails once
@@ -104,15 +104,15 @@ a PPS signal most of the time but have an unstable serial timing that
cannot be fudge-compensated.
| 2 |Automatic mode. Tries to operate in strict mode unless it fails to process valid samples for some time, currently 120s. Then
-it reverts to STI-only operation until the PPS is stable again for
+it reverts to IBT-only operation until the PPS is stable again for
40s, when strict mode is engaged again.
*Important Notice: This is an experimental feature!*
-Switching between strict and STI-only mode will cause changes in offset
-and jitter. Use this mode only if STI-only works fairly well with your
+Switching between strict and IBT-only mode will cause changes in offset
+and jitter. Use this mode only if IBT-only works fairly well with your
setup, or if you expect longer dropouts of the PPS signal and prefer to
-use STI alone over not getting synchronised at all.
+use IBT alone over not getting synchronised at all.
| 3 |'(reserved for future extension, do not use)'
| 2..31 2+|'(reserved for future extension, do not use)'
|===========================================================================
@@ -219,7 +219,7 @@ since the last poll.
+flag4 {0 | 1}+::
_[Primary Unit]_ If set, write a clock stats line on every poll cycle.
+mode+::
- Control STI and strict operating modes.
+ Control IBT and strict operating modes.
[[fn1]]link:#fn1bl[^1^)]Data transmission and decoding is done only once by the
primary unit. The decoded data is then processed independently in both
=====================================
docs/ntpspeak.txt
=====================================
--- a/docs/ntpspeak.txt
+++ b/docs/ntpspeak.txt
@@ -28,6 +28,11 @@ association::
for discovering association partners, creating and maintaining
associations, and preventing attackers from forming associations.
+[[atom]]
+atom::
+ Old name for the PPS driver. Origin lost in the mists of history,
+ but probably related in some way to cesium atomic clocks.
+
[[drift]]
drift::
In an NTP context, drift refers to the frequency offset of a clock crystal
@@ -100,6 +105,15 @@ holdover::
<<drift>> in the oscillator, accuracy drops as holdover time (time
since last signal lock) increases.
+[[in-band time]]
+in-band time::
+ GPS-based time sources often deliver two channels of time
+ information. The timestamp delivered as ASCII data over the
+ 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.
+
[[leap second]]
leap second::
Because the earth's rotation varies in irregular ways (gradually
@@ -155,11 +169,19 @@ nonce::
[[parse-driver]]
parse driver::
- A refclock link:driver_generic.html[generic] which, uniquely, handles
- multiple <<time radio>> protocols - two dozen mostly European
- precision time radios mostly using DCF, the broadcast time from the
- German national authority. Each clock type is internally represented
- as a few parse methods and table entries in a table-driven parser.
+ A refclock, now known as link:driver_generic.html[generic], which
+ handles multiple <<time radio>> protocols - two dozen mostly
+ European precision time radios mostly using DCF, the broadcast time
+ from the German national authority. Each clock type is internally
+ represented as a few parse methods and table entries in a
+ table-driven parser. Older documentation used the term "parse
+ driver" interchangeably with "generic driver".
+
+[[popcorn spike]]
+popcorn spike::
+ A packet from a particular peer that has a computed theta more than
+ three standard deviations from the prevous sample. These are
+ normally treated as random outliers and suppressed.
[[PPS]]
PPS::
@@ -168,12 +190,11 @@ PPS::
is often connected to a RS-232 modem control signal pin.
A PPS signal doesn't tell you which second a pulse corresponds to
so it must be used with an ancillary signal, typically text over
- the same RS-232 connector.
+ the same RS-232 connector (see <<in-band time>>).
The advantage of a PPS signal is improved accuracy. Most OSes have
provisions to grab a timestamp at interrupt time. The API is described
in RFC-2783.
-
[[PTP]]
PTP::
https://en.wikipedia.org/wiki/Precision_Time_Protocol[Precision Time
=====================================
ntpd/refclock_gpsd.c
=====================================
--- a/ntpd/refclock_gpsd.c
+++ b/ntpd/refclock_gpsd.c
@@ -145,7 +145,7 @@ typedef unsigned long int json_uint;
/* get operation modes from mode word.
- * + SERIAL (default) evaluates only serial time information ('STI') as
+ * + SERIAL (default) evaluates only in-band time ('IBT') as
* provided by TPV and TOFF records. TPV evaluation suffers from a
* bigger jitter than TOFF, sine it does not contain the receive time
* from GPSD and therefore the receive time of NTPD must be
@@ -162,18 +162,18 @@ typedef unsigned long int json_uint;
* feeding samples when GPSD says that the time information is
* effectively unreliable.
*
- * + STRICT means only feed clock samples when a valid STI/PPS pair is
- * available. Combines the reference time from STI with the pulse time
+ * + STRICT means only feed clock samples when a valid IBT/PPS pair is
+ * available. Combines the reference time from IBT with the pulse time
* from PPS. Masks the serial data jitter as long PPS is available,
* but can rapidly deteriorate once PPS drops out.
*
- * + AUTO tries to use STI/PPS pairs if available for some time, and if
- * this fails for too long switches back to STI only until the PPS
+ * + AUTO tries to use IBT/PPS pairs if available for some time, and if
+ * this fails for too long switches back to IBT only until the PPS
* signal becomes available again. See the HTML docs for this driver
* about the gotchas and why this is not the default.
*/
#define MODE_OP_MASK 0x03
-#define MODE_OP_STI 0
+#define MODE_OP_IBT 0
#define MODE_OP_STRICT 1
#define MODE_OP_AUTO 2
#define MODE_OP_MAXVAL 2
@@ -1031,9 +1031,9 @@ eval_auto(
if (!up->fl_sti)
return;
- /* check how to handle STI+PPS: Can PPS be used to augment STI
+ /* check how to handle IBT+PPS: Can PPS be used to augment IBT
* (or vice versae), do we drop the sample because there is a
- * temporary missing PPS signal, or do we feed on STI time
+ * temporary missing PPS signal, or do we feed on IBT time
* stamps alone?
*
* Do a counter/threshold dance to decide how to proceed.
@@ -1782,9 +1782,9 @@ gpsd_parse(
eval_pps_secondary(
up->pps_peer, up->pps_peer->procptr, up);
- /* check PPS vs. STI receive times:
- * If STI is before PPS, then clearly the STI is too old. If PPS
- * is before STI by more than one second, then PPS is too old.
+ /* check PPS vs. IBT receive times:
+ * If IBT is before PPS, then clearly the IBT is too old. If PPS
+ * is before IBT by more than one second, then PPS is too old.
* Weed out stale time stamps & flags.
*/
if (up->fl_pps && up->fl_sti) {
@@ -1800,7 +1800,7 @@ gpsd_parse(
/* dispatch to the mode-dependent processing functions */
switch (up->mode) {
default:
- case MODE_OP_STI:
+ case MODE_OP_IBT:
eval_serial(peer, pp, up);
break;
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/ed5062a76e59972d4431777b7b65d0852f8bc77f...b20dd2b51cae5c08fa64da7b5bd9c0b77e6069b7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/vc/attachments/20160701/a834d4a5/attachment.html>
More information about the vc
mailing list