[ntp:questions] SIRF time output wobble, GPS or NTP fault?

David J Taylor david-taylor at blueyonder.co.uk.invalid
Thu Mar 8 08:36:03 UTC 2012

"Ron Frazier (NTP)" <timekeepingntplist at c3energy.com> wrote in message 
news:4F57CC17.3020708 at c3energy.com...
> I have an adapter based on the Prolific chipset which is supposed to 
> pass the handshaking signals.  It's the Trendnet TU-S9.  I'm going to 
> try that, but I'll certainly keep the one you mentioned in mind.

If you're lucky, that should work on Windows to get offsets within the 400 
microsecond level, and jitter I saw as ~45 microseconds using Windows XP.

> That is the $ 20,000 question.  From our prior discussion, it looks like 
> you're saying the Garmin has a jitter in the start time of the NMEA 
> sentence of about 170 ms.  I appear to be observing a similar phenomenon 
> here, but I'm not totally convinced it's real.

For the Garmin GPS 18x with 3.70 firmware, it's real.  I could see 
something similar on the 'scope here.  Whether other GPSs have similar 
values I don't know.

> I think the monitor program may be lying to me about the offsets of the 
> internet servers.  If it is real, the variation is very slow, and it 
> takes a day or two to swing from about + 80 ms from NIST to - 80 ms from 
> NIST.  I have nothing to explain that 900 ms jump I mentioned.  Is this 
> "wobble" effect something that has been observed with other GPS units?

Be aware that servers such as NIST's may well be overloaded.  Choose ones 
with a short network path and, ideally, one with little load.  My gut 
feeling is that until you have PPS, you may get better performance from a 
selection of Internet servers than a serial-only GPS,

>> Are you using that version or later?
> On Windows, I'm running 4.2.7p259.  On Ubuntu Linux, when I boot into 
> it, I'm running the version from the Ubuntu repositories which is about 
> 2 years old.  I did a manual upgrade to try to troubleshoot some abrupt 
> jumps in the reported offsets, but that didn't solve the problem.  I 
> retrograded back to the one that's in the repositories as doing a manual 
> install breaks several things.  It's better to use the package manager.

For use with the Sure, I suggest the latest NTP on Linux as well.  I had 
to ask here how to update FreeBSD and, apart from the time taken to 
recompile everything under the sun, it went well.

>> May I suggest using the $GPGGA sentence instead even if it is a little 
>> longer?  The $GPZDG sentence appears to be the only other one with a 
>> "valid" indicator.
> I think the satellite lock was good at the time but cannot prove it.  It 
> looks to me like the Meinberg monitor is reporting the server offsets 
> wrong.

I very much doubt that.

> I'm presuming it uses the ntpq command internally to get that data but I 
> don't know.

Doesn't it read the loopstats files for its graphs, though?

> I'm currently experimenting with all internet servers noselected to see 
> what happens.  I have a variation from my GPS time going from 11 of 12 
> internet servers within 9.99 ms (single digit before the decimal point) 
> to 4 of 12 internet servers within 9.99 ms.  I have not observed any 
> more 950 ms offsets to the internet servers.  I just checked while 
> typing this and 8 of 12 internet servers are within 9.99 ms.

The 950 ms sounds like the GPS getting the wrong second - slipping sync 
compared to the clock.

> It doesn't look like GPGGA has any validation in it.

The Fix Quality field.  0 = Invalid, 1 = GPS fix, 2 = DGPS fix.  I would 
hope that NTP rejects any data with 0 in this field, but I don't read the 
sources at all well.

> I am reluctant to switch to another sentence for a few reasons, assuming 
> NMEA only is ultimately usable at all for a few reasons:

Noted, and I see your reasons, but using only $GPZDA concerns me as it 
lacks any validity check.
> This is the part of my ntp.conf file in windows related to stats.  Do I 
> need to add anything else?  I think all the stats are already on in 
> Linux.
> enable stats
> statsdir "C:\NTP Service\NTP\etc\"
> statistics loopstats
> Thanks for the help.
> Sincerely,
> Ron

You may want to add peerstats:

statistics loopstats peerstats

so that you can look at the 5th column of the results, and read the offset 
for each clock.


More information about the questions mailing list