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 2 u 40 1024 377 30.031 1.885
2.743
xecmail2.cmc.ec. 18.26.4.105 2 u 76 512 377 28.707 -3.198
13.423
+ntp-1.cns.vt.ed 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.
One thing I should mention before I forget: I saw some really wacko results
on my system until I did 2 things:
1. get your computer clock synced as close to real time as possible. Use
ntpdate and point it to a valid time source and run that command at least
4-6 times to get your clock to < 100ms of real time. NTP does not work well
when its local clock is out of whack.
2. Use the calibrate
feature<http://www.ee.udel.edu/%7Emills/ntp/html/refclock.html#cal>to
figure out the fudge time1 specific to your GPS setup. The number I
provided in my last email was MY setting (found through calibration). Yours
will probably differ slightly.
Until I did the above 2 steps, my server was all over the place - even after
running for days!
The PPS signal was pretty accurate of course, although gpsd seemed to
> introduce extra noise and jitter than with shmpps, which my noise and
> jitter
> are almost always under 4 us, and offsets +- 4 us.
I was happy when I saw my offset go below 1ms! I'm not that much of time nut
and don't need anything lower. I think there are many factors that effect
the precision. The software is only part of it - your computer hardware ,
the kernel, other apps, interrupts on the motherboard, etc. all have
something to do with how precise time gets. In my searching, I had come
across an article a fellow wrote where he went as far as changing the
oscillator on his mother board! I can't seem to find the link now, otherwise
I'd send it to you.
> Thanks again for the information!
Glad it helped. It took me a few days and a ton of reading to get where I
am today. A bit frustrating - tons of info on the net, but nothing that puts
it all together. Typical of information these days I guess! ;-) I've cc'ed
the list to help "get the info I found - out!"
Thanks,
-Rob
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers