Hi Hal,
I can't offer much in the way of recommendations for GPS receivers,
but I have been doing some experimentation just lately with USB
serial devices for serial time code to NTP.
I'd be very interested in comparing results!
So far I've been using reasonably decent GPS clocks and a USB serial
port adapter, not the cheap USB GPS pucks. I've been meaning to pick
up one of the cheap pucks for comparison too, but haven't got that
point.
So far I have noticed that I can get a pretty decent notion of the
constant offset just using the NTP calibrate mode.
The random jitter is pretty noticeable too, but I've been surprised
by how mild it can be in more "ideal" circumstances. I was expecting
much worse.
I have two systems I am testing on, one ancient slow system that's
VERY busy (I use it as a main desktop for day to day use, and I can
routinely peg the CPU for minutes at a time). And one much newer
dual core laptop that pretty much sits doing only NTP. Yes I know
it's odd to use the older laptop for my day to day work, and leave
the newer one idle, but still use a lot of old software so...
Anyway, here's a little data:
Three random data points from the fast system, lowest jitter:
ntpq> peers
remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.1.90 .GPS. 1 u 66 128 377 0.529 0.061 0.068
+192.168.1.95 .GPS. 1 u 104 128 377 0.454 0.101 0.108
+192.168.1.101 .GPS. 1 u 76 128 377 0.557 0.053 0.065
+192.168.1.102 .GPS. 1 u 11 128 377 0.553 0.039 0.042
+192.168.1.103 .GPS. 1 u 78 128 377 0.523 0.024 0.049
-TRUETIME(0) .GPS. 1 l 35 64 377 0.000 -0.437 0.537
ntpq> peers
remote refid st t when poll reach delay offset jitter
==============================================================================
-192.168.1.90 .GPS. 1 u 73 128 377 0.610 0.001 0.016
-192.168.1.95 .GPS. 1 u 1 128 377 0.585 0.007 0.016
+192.168.1.101 .GPS. 1 u 95 128 377 0.546 0.058 0.043
*192.168.1.102 .GPS. 1 u 22 128 377 0.574 0.036 0.024
+192.168.1.103 .GPS. 1 u 91 128 377 0.506 0.026 0.028
-TRUETIME(0) .GPS. 1 l 24 64 377 0.000 0.233 0.360
ntpq> peers
remote refid st t when poll reach delay offset jitter
==============================================================================
-192.168.1.90 .GPS. 1 u 50 128 377 0.638 0.013 0.024
*192.168.1.95 .GPS. 1 u 97 128 377 0.575 0.051 0.041
-192.168.1.101 .GPS. 1 u 70 128 377 0.503 0.083 0.067
+192.168.1.102 .GPS. 1 u 1 128 377 0.623 0.022 0.015
-192.168.1.103 .GPS. 1 u 61 128 377 0.626 -0.011 0.020
-TRUETIME(0) .GPS. 1 l 62 64 377 0.000 0.064 0.287
ntpq>
Most of the clocks run fairly close. The serial time code swings
much more wildly than the direct Ethernet connections. Despite the
much larger bounce, it still usually stays in sync with everything
else within a swing of a millisecond or so.
On my other slower system the USB handling is much sloppier, no doubt
due to the system being slower, older, busier and so on. Don't read
too much into this, the system below is NOT a perfect comparison. I
just threw it in to show that USB can be very seriously impacted by
what else is going on with the system... A busy system with more USB
devices will degrade really badly compared to the gentler test case.
ntpq> peers
remote refid st t when poll reach delay offset jitter
==============================================================================
+192.168.1.90 .GPS. 1 u 89 128 377 0.545 0.055 0.059
+192.168.1.95 .GPS. 1 u 103 128 377 0.540 0.051 0.046
+192.168.1.100 .GPS. 1 u 98 128 377 0.422 0.042 0.031
*192.168.1.101 .GPS. 1 u 1 128 377 0.415 -0.003 0.043
+192.168.1.102 .GPS. 1 u 97 128 377 0.453 -0.011 0.038
+192.168.1.103 .GPS. 1 u 107 128 377 0.374 0.021 0.039
xTRUETIME(0) .GPS. 1 l 57 64 377 0.000 -23.338 21.204
ntpq> peers
remote refid st t when poll reach delay offset jitter
==============================================================================
+192.168.1.90 .GPS. 1 u 2 128 377 0.555 -0.036 0.031
*192.168.1.95 .GPS. 1 u 23 128 377 0.503 -0.055 0.028
+192.168.1.100 .GPS. 1 u 2 128 377 0.437 -0.085 0.024
+192.168.1.101 .GPS. 1 u 1 128 377 0.439 -0.086 0.040
+192.168.1.102 .GPS. 1 u 107 128 377 0.439 -0.015 0.238
+192.168.1.103 .GPS. 1 u 14 128 377 0.451 -0.093 0.026
-TRUETIME(0) .GPS. 1 l 51 64 377 0.000 0.779 0.431
ntpq>
Both systems have similar overall offsets for the USB service and
handling time. I am NOT using any special line disciplines, nor have
I connected the PPS. This is just plain serial time code.
I've been collecting NTP stats too, so when I have some time I will
try to generate some pretty graphs.
--
Russell
At 3:24 AM -0700 2009/05/06, Hal Murray wrote:
I'm looking for low cost GPS gadgets that are good for time keeping via ntpd.
Any suggestions?
I'm interested in not-so-good timing as well as the good stuff that attracts
time-nuts. As long as it's low cost.
USB doesn't support PPS and it has a bad reputation because it's polled. But
the polling is done in hardware with a 1 ms time scale. It won't be great,
but for lots of uses it's good enough.
The problem is that most of the low-cost GPS toys use the SiRF chip set. It
sucks for timing. It looks like the NMEA sentences are sent from a timer
with 100 ms ticks.
http://www.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif
The Garmin GPS 18 LVC used to be popular. It's been replaced by the GPS 18x
which is much more sensitive. Unfortunately, the timing went way downhill.
http://www.megapathdsl.net/~hmurray/ntp/GPS18LVCx-off.gif
Anybody know how well the u-Blox chips work? Are they used in any low cost
units? (USB ok.)
Just to make sure we are on the same wavelength. I don't care about a
constant offset. I can easily correct for that. It's the jitter that I
don't like. The time scale is wrong. It wanders too slowly. I can't filter
it out.
--
These are my opinions, not necessarily my employer's. I hate spam.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
