From 70dc4221f5d1604b211865b3ffb26d45ef0297c4 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Fri, 27 Sep 2013 14:34:51 -0400 Subject: Note that NTP could be erroneous too. --- timebase.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'timebase.c') diff --git a/timebase.c b/timebase.c index e4c8df82..6a5ca488 100644 --- a/timebase.c +++ b/timebase.c @@ -69,7 +69,7 @@ a fixed (and possibly out of date) offset. Conclusion: if the system clock isn't accurate enough that we can deduce what rollover period we're in, we're utterly hosed. Furthermore, if it's not accurate to within a second and only NMEA devices are reporting, -we don't know what century it is! +we don't even know what century it is! Therefore, we must assume the system clock is reliable to within a second. @@ -77,7 +77,9 @@ However, none of these caveats affect the usefulness of PPS, which tells us top of second to 50ns accuracy and can be made to condition a local NTP instance that does *not* rely on the system clock. The combination of PPS with NTP time should be reliable regardless of -what the local system clock gets up to. +what the local system clock gets up to. That is, unless NTP clock +skew goes over 1 second, but this is unlikely to ever happen - and +if it does the reasons will have nothing to do with GPS idosyncracies. This file is Copyright (c) 2010 by the GPSD project BSD terms apply: see the file COPYING in the distribution root for details. -- cgit v1.2.1