[Git][NTPsec/ntpsec][master] Support g and G suffixes on the time1 fudge for GPS ara offsetting.
Eric S. Raymond
gitlab at mg.gitlab.com
Fri Aug 16 17:23:49 UTC 2019
Eric S. Raymond pushed to branch master at NTPsec / ntpsec
Commits:
553309e9 by Eric S. Raymond at 2019-08-16T17:22:45Z
Support g and G suffixes on the time1 fudge for GPS ara offsetting.
- - - - -
12 changed files:
- NEWS
- docs/driver_arbiter.adoc
- docs/driver_hpgps.adoc
- docs/driver_nmea.adoc
- docs/driver_oncore.adoc
- docs/driver_spectracom.adoc
- docs/driver_truetime.adoc
- docs/includes/clock-options.adoc
- docs/ntpsec.adoc
- − docs/pic/oncore_remoteant.jpg
- docs/rollover.adoc
- ntpd/ntp_scanner.c
Changes:
=====================================
NEWS
=====================================
@@ -12,6 +12,12 @@ on user-visible changes.
== Repository head ==
+The numeric literal argument of the 'time1' fudge option on a clock
+can now have one or more letter suffixes that compensate for era
+rollover in a GPS device. Each "g" adds the number of seconds in a
+1024-week (10-bit) GPS era. Each "G" adds the number of seconds in a
+8192-week (13-bit) GPS era.
+
== 2019-07-10: 1.1.6 ==
Fixes to code quality checks.
=====================================
docs/driver_arbiter.adoc
=====================================
@@ -21,6 +21,10 @@ system clock to be near correct before samples will be processed
properly. You will not be able to use it to run autonomously, nor will
it reliably recover from a trashed or zeroed system clock.
+It is likely any surving instances of this hardware will have
+era-rollover issues when reporting dates. One or more "g" suffixes
+on your 'time1' option may be useful as a workaround.
+
== Description
This driver supports the Arbiter 1088A/B Satellite Controlled Clock. The
=====================================
docs/driver_hpgps.adoc
=====================================
@@ -14,7 +14,9 @@ Serial Port: /dev/hpgps__u__; 9600bps 8N1, 19200bps 7N2 for the HP Z3801A
As of September 2017 we have reports that the internal clock on a
Z3801A was observed to roll over to 1998 (see
link:rollover.html[Rollover issues in time sources]). Users should
-audit for rollover before deploying any of these devices.
+audit for rollover before deploying any of these devices. One or more "g"
+suffixes on your 'time1' option may be useful as a workaround if
+your device does not support setting the era date.
== Description
=====================================
docs/driver_nmea.adoc
=====================================
@@ -49,6 +49,13 @@ The various GPS sentences that this driver recognises look like this
|$GPZDG,GPSTIME,DD,MM,YYYY,AA.BB,V*CS<cr><lf>|Accord
|=============================================================================
+Important caveats: If your NMEA device does not ship GPZDA, you cannot
+use it to run autonomously without a check peer, or expect recovery
+from a trashed system clock. Also, dates from old NMEA devices are
+vulnerable to era wraparound; the NMEA dtiver has an internal trick
+that attempts to detect this, but one or more "g" suffixes on your
+'time1' option may be useful as a workaround.
+
.NMEA data items
[cols="15%,85%",options="header"]
[options="header"]
@@ -221,6 +228,10 @@ switched on by sending the following string.
"$PGRMC,,,,,,,,,,,,2<cr><lf>"
-----------------------------
+It is likely any surving instances of this hardware will have
+era-rollover issues when reporting dates. One or more "g" suffixes
+on your 'time1' option may be useful as a workaround.
+
== Driver Options
+unit+ 'number'::
=====================================
docs/driver_oncore.adoc
=====================================
@@ -21,6 +21,10 @@ system clock to be near correct before samples will be processed
properly. You will not be able to use it to run autonomously, nor will
it reliably recover from a trashed or zeroed system clock.
+It is likely any surving instances of this hardware will have
+era-rollover issues when reporting dates. One or more "g" suffixes
+on your 'time1' option may be useful as a workaround.
+
== Description
This driver supports most models of the
=====================================
docs/driver_spectracom.adoc
=====================================
@@ -21,6 +21,10 @@ system clock to be near correct before samples will be processed
properly. You will not be able to use it to run autonomously, nor will
it reliably recover from a trashed or zeroed system clock.
+It is likely any surving instances of this hardware will have
+era-rollover issues when reporting dates. One or more "g" suffixes
+on your 'time1' option may be useful as a workaround.
+
== Description
This driver supports the "Type 2" format emitted by Spectracom time
=====================================
docs/driver_truetime.adoc
=====================================
@@ -20,6 +20,10 @@ system clock to be near correct before samples will be processed
properly. You will not be able to use it to run autonomously, nor will
it reliably recover from a trashed or zeroed system clock.
+It is likely any surving instances of this hardware will have
+era-rollover issues when reporting dates. One or more "g" suffixes
+on your 'time1' option may be useful as a workaround.
+
== Description
This driver supports several models of Kinemetrics/TrueTime
=====================================
docs/includes/clock-options.adoc
=====================================
@@ -35,11 +35,14 @@
range is 0 (1 sec) to 17 (36.4 hours) inclusive.
+time1+ _sec_;;
Specifies a constant to be added to the time offset produced by the
- driver, a fixed-point decimal number in seconds. This is used as a
+ driver, a fixed-point decimal number in seconds. Each "g" on the
+ end of the constant adds the number of seconds in a 10-bit GPS
+ era; each "G" adds the number of seconds in a 13-bit GPS era. This is used as a
calibration constant to adjust the nominal time offset of a
particular clock to agree with an external standard, such as a
precision PPS signal. It also provides a way to correct a systematic
- error or bias due to serial port or operating system latencies,
+ error or bias due to era wraparound from a GPS device,
+ serial port or operating system latencies,
different cable lengths or receiver internal delay. The specified
offset is in addition to the propagation delay provided by other
means, such as internal DIP switches. Where a calibration for an
=====================================
docs/ntpsec.adoc
=====================================
@@ -247,6 +247,11 @@ to the security-critical core.
each refclock page. One major feature of the new syntax is that
refclock drivers are referred to by names, not numbers.
+* Entries for GPS devices can be fudged for era wraparound using the
+ +time1+ offset. Each 'g' on the end of the offset adds the number of
+ seconds in a 10-bit GPS era (1024 weeks); each 'G' adds the number
+ of seconds in a 13-bit GPS era (8192 weeks).
+
* The unpeer command now takes a type-unit specification when
unpeering a clock.
=====================================
docs/pic/oncore_remoteant.jpg deleted
=====================================
Binary files a/docs/pic/oncore_remoteant.jpg and /dev/null differ
=====================================
docs/rollover.adoc
=====================================
@@ -170,9 +170,9 @@ constraints at the time the system was designed, the week counters are
only 10 bits long; thus, GPS time has a period of 1024 weeks (a bit
over 19 years) footnote:[It is planned that future GPS satellites will
increase the week counter length to 13 bits, for a period of 8192
-weeks or more than 157 years]. At time of writing, one GPS rollover
-has occurred at 1999-08-22T00:00:00 and the next will occur on
-2019-05-06.
+weeks or more than 157 years]. At time of writing, two GPS rollovers
+have occurred; the first at 1999-08-22T00:00:00 and the second at
+2019-05-06T00:00:00.
(GPS was originally designed for military geolocation, not time
service. It does not seem to have occurred to the originators that
@@ -217,7 +217,7 @@ 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 shipped 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
@@ -228,7 +228,7 @@ a GPS rollover has occurred and add 1024 weeks to the base date.
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
+ability to reconfigure the base date, the device will ship incorrect
reports forever afterwards. A few refclocks, like the HP-GPS line,
have that ability; most do not.
@@ -260,10 +260,16 @@ ready to compensate by dropping in a device with a newer pivot date.
Actionable advice that follows from this: If you don't know the
manufacturing date of a GPS-based device to within a couple of years,
-don't trust that it won't be rolled over and useless *the first time
+don't trust that it won't be rolled over *the first time
you start it*. Shopping for cheap refclocks at surplus houses or
on the Web is particularly hazardous this way.
+NTPsec includes a workaround option for these old devices. Each "g"
+suffix on the 'time1' offset option for a device adds the number of seconds
+in a 1024-week era; this corresponds to the 10-bit week counters used
+in today's GNSS. "G" adds the number of seconds in the 8192-week era
+of te future.
+
A fairly bulletproof mitigation strategy, if you are running
autonomously, is to have multiple GPS clocks per server and replace
each individual one at least once every nine years (half a GPS era).
=====================================
ntpd/ntp_scanner.c
=====================================
@@ -34,7 +34,11 @@
/* ntp_keyword.h declares finite state machine and token text */
#include "ntp_keyword.h"
-
+/* used to implement g and G suffixes for numeric literals in fudge offset declarations */
+#define SECONDS_IN_WEEK (7 * 24 * 60 * 60)
+#define GPS_ERA_10BIT (1024L * SECONDS_IN_WEEK)
+#define GPS_ERA_13BIT (8192L * SECONDS_IN_WEEK)
+#define ERA_SUFFIX(c) ((c) == 'g' || (c) == 'G')
/* SCANNER GLOBAL VARIABLES
* ------------------------
@@ -673,6 +677,10 @@ is_double(
while (lexeme[i] && isdigit((uint8_t)lexeme[i]))
i++;
+ /* Allow trailing multipliers */
+ while (ERA_SUFFIX(lexeme[i]))
+ i++;
+
/* Check if we are done */
if (!lexeme[i])
return true;
@@ -921,9 +929,19 @@ yylex(void)
token = T_U_int;
goto normal_return;
} else if (is_double(yytext)) {
+ double era_offset = 0;
yylval_was_set = true;
errno = 0;
- yylval.Double = atof(yytext);
+ while (ERA_SUFFIX(yytext[strlen(yytext)-1])) {
+ if (yytext[strlen(yytext)-1] == 'g') {
+ era_offset += GPS_ERA_10BIT;
+ }
+ if (yytext[strlen(yytext)-1] == 'G') {
+ era_offset += GPS_ERA_13BIT;
+ }
+ yytext[strlen(yytext)-1] = '\0';
+ }
+ yylval.Double = era_offset + atof(yytext);
if ( D_ISZERO_NS(yylval.Double) && errno == ERANGE) {
/* FIXME, POSIX says atof() never returns errors */
msyslog(LOG_ERR,
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/commit/553309e9ecc47f21874978ba8e4b06bfa8deb739
--
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/commit/553309e9ecc47f21874978ba8e4b06bfa8deb739
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/20190816/b0c9761f/attachment-0001.htm>
More information about the vc
mailing list