Rob schreef:
Hi Dennis,
I messed with it for a few hours this morning, and found that the
GPS time
was wildly inaccurate. I was getting offsets anywhere from -27 ms
to 16 ms,
and it's not consistent. It was flagged as a false ticker by ntpd
most of
the time. I wonder if disabling unnecessary NMEA sentences would
reduce the
offset, or at least make it more consistent.
How is the GPS time offset on your system?
Here is my ntpq -p :
remote refid st t when poll reach delay
offset jitter
==============================================================================
+time.nrc.ca 132.246.168.3 <http://132.246.168.3> 2 u 40
1024 377 30.031 1.885 2.743
xecmail2.cmc.ec <http://xecmail2.cmc.ec>. 18.26.4.105
<http://18.26.4.105> 2 u 76 512 377 28.707 -3.198 13.423
+ntp-1.cns.vt.ed 198.82.247.40 <http://198.82.247.40> 2 u 35
1024 377 52.726 3.585 0.228
+avi-lis.gw.ligh .CDMA. 1 u 32 1024 377 41.104
7.281 0.567
+SHM(0) .GPS. 0 l 10 16 377 0.000
6.968 2.744
*SHM(1) .PPS. 0 l 9 16 377 0.000
0.036 0.016
The GPS time will be erratic. It jumps plus or minus ms on my system
all the time. NTP also demotes it and then reinstates it continuously.
However, from what I read, so long as the PPS pulse is good, NTP will
figure out what to do. It basically will use the GPS time as a "stamp"
of time (to the second) which it aligns with the PPS pulse. If your
running your system connected to the net, you will probably want to
peer with a few "partners" to help tweak the time and to back you up
if you loose sat-lock. If your system is network isolated, running
with just GPS/PPS should work - even though you'll see NTP demoting
your sources every so often. In my not so scientific tests, NTP likes
the PPS signal much better when there are at least a handful of time
sources to choose from. That's not to say your system won't keep good
time without the other sources - I think this is just the way NTP
works - it constantly wants to evaluate other sources to make sure its
time is correct. Without the other sources it occasionally gets confused.
I presume you use gpsd with a receiver with PPS line on RS232? (the
ntpq -p output looks like that).
In that case, it is completely correct what you write. The
message-based time (SHM(0)) is very inaccurate because of deficiencies
in most GPS receivers and their comms protocols. It is completely
unclear what time the timestamp in the message refers to, and usually it
jitters wildly.
The PPS output pulse is accurate, and the message-based time is only
required to bring the local clock well within one second, at which time
the PPS should take over.
Indeed, the whole operation is much more reliable when you have a couple
of references for NTP to choose from.
Also, during initial experiments, when you stop and start ntpd all the
time (because the sucker cannot reload a config file without restarting,
much like old versions of Windows), it usually gets confused because
more than one time adjustment is ongoing in the kernel. The result is
that it wanders around the desired time, suddenly jumps a big fraction
of a second, loses lock, etc etc. Bad things.
This stops happening when you don't touch it for a couple of hours. So
don't keep fiddling until you get desperate, but just edit the config to
arrive at something like the above and then leave it alone for a day to
see what ntpq -p looks like (instead of looking every minute and asking
yourself what it is doing).
Rob
(original author of the time sync support in gpsd)
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
