[Git][NTPsec/ntpsec][master] 2 commits: Add warnings about GPS wraparound.

[Eric S. Raymond]

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


Commits:
54d1dab3 by Eric S. Raymond at 2017-04-25T19:43:35-04:00
Add warnings about GPS wraparound.

- - - - -
2bd5e39c by Eric S. Raymond at 2017-04-25T20:12:36-04:00
Revision of GPS rollover warning.

- - - - -


3 changed files:

- docs/driver_arbiter.txt
- docs/driver_gpsd.txt
- docs/driver_nmea.txt


Changes:

=====================================
docs/driver_arbiter.txt
=====================================
--- a/docs/driver_arbiter.txt
+++ b/docs/driver_arbiter.txt
@@ -142,6 +142,20 @@ David L. Mills <mills at udel.edu>
 
 link:refclock.html[Reference Clock Drivers]
 
+== Known bugs ==
+
+If your Arbiter has firmware made more than 1024 weeks (19 years and 36
+weeks) in the past, its internal date counter may wrap around
+and generate spurious timestamps.
+
+This problem is fundamental and cannot be compensated for in code
+without relying on the accuracy of the local system clock, which
+is exactly what an NTP implementation may not do without risking
+perverse failure modes (especially at startup time).
+
+The only sure remedy is to be sure the Arbiter's firmware has been .
+updated within the current GPS era.
+
 '''''
 
 include::includes/footer.txt[]


=====================================
docs/driver_gpsd.txt
=====================================
--- a/docs/driver_gpsd.txt
+++ b/docs/driver_gpsd.txt
@@ -253,6 +253,29 @@ refclock gpsd mode 2 path /dev/tty.usbserial
 
 This is configured for the experimental automatic mode.
 
+== Known bugs ==
+
+If your GPS has firmware made more than 1024 weeks (19 years and 36
+weeks) in the past, its internal date counter may well wrap around
+and generate spurious timestamps.  Some newer GPSes may have a
+longer wraparound (8192 weeks, or 157 years and 28 weeks) but
+this is almost never documented and not safe to bet on. GPSD
+cannot tell what the device's wraparound time is, nor what
+any base-date assumption in its firmware might be.
+
+This problem is fundamental and cannot be compensated for in code
+without relying on the accuracy of the local system clock, which is
+what GPSD (primarily designed for geospatial location) does.  This
+choice creates a risk of perverse GIGO failure modes (especially at
+startup time). The only remedy is (a) not to use ancient GPS hardware,
+and (b) not to rely on GPSD to manage a time source if there is
+any serious risk that your NTP host might boot with a system clock time
+that is wildly off.
+
+Even with these constraints there is some risk of flaky failures
+in a time window around GPS defined by your host system's worst-case
+clock skew from UTC at boot time.
+
 '''''
 
 include::includes/footer.txt[]


=====================================
docs/driver_nmea.txt
=====================================
--- a/docs/driver_nmea.txt
+++ b/docs/driver_nmea.txt
@@ -261,4 +261,20 @@ link:refclock.html[Reference Clock Drivers]
 
 '''''
 
+== Known bugs ==
+
+If your GPS has firmware made more than 1024 weeks (19 years and 36
+weeks) in the past, its internal date counter will almost certainly
+wrap around and generate spurious timestamps.  Beginning in January
+2018, newer GPSes may have a longer wraparound (8192 weeks, or 157
+years and 28 weeks) but it is not safe to bet that any given receiver
+will have firmware updated to take advantage of this.
+
+This problem is fundamental and cannot be compensated for in code
+without relying on the accuracy of the local system clock, which
+is exactly what an NTP implementation may not do without risking
+perverse failure modes (especially at startup time). The only
+remedy is not to use ancient GPS hardware.
+
+'''''
 include::includes/footer.txt[]



View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/0d43e245898c621983cc7e09f24bec55fdc80e71...2bd5e39cb8d3b26077d2e3f5aca71678ff49a0f4

---
View it on GitLab: https://gitlab.com/NTPsec/ntpsec/compare/0d43e245898c621983cc7e09f24bec55fdc80e71...2bd5e39cb8d3b26077d2e3f5aca71678ff49a0f4
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/20170426/8487843c/attachment.html>