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

David J Taylor david-taylor at blueyonder.co.uk.invalid
Wed Mar 7 09:25:17 UTC 2012

"Ron Frazier (NTP)" <timekeepingntplist at c3energy.com> wrote in message 
news:4F567490.1030007 at c3energy.com...
> David and others,
> I do appreciate the help and advice you've given me to this point.  I 
> read all the replies up to this point on the ESR thread and this thread. 
> That includes David's mention of NMEA variances on the Garmin and 
> Chris's mention that NMEA "within the second" is within spec.  I still 
> think something is wrong with the NTP subsystem in my opinion.  I'm not 
> going to lose a lot of sleep over it.  I report it here just in case 
> someone who knows how wants to investigate it.

All reports are appreciated.

> Just because PPS and RS-232 work better, doesn't mean the NMEA driver 
> and / or the Meinberg monitor shouldn't work properly.  I will NEVER be 
> able to use RS-232 on this computer without a USB - serial adapter 
> (which I intend to try).  It doesn't exist.

The box I tried (a Sitecom USB hub) actually carried the DCD signal over 
USB, and allowed a much lower jitter than Internet servers alone.

> The capabilities of a USB GPS are perfectly adequate for my application. 
> + / - 6 ms is just fine.  There are, by the way, many other applications 
> where 6 ms would be acceptable.

Yes, I completely agree.  The problem is that we don't know how much 
jitter may be present on the NMEA output of your particular GPS.  If it's 
like the GPS 18x LVC, then using the serial output alone may not be much 
better than using Internet servers, as the jitter from sending over USB 
may well be insignificant compared to the GPS NMEA jitter.

> For comparison, the best I can get on Windows polling exclusively from 
> the internet, with any kind of reasonable polling interval and not 
> pounding the internet servers all the time, is about + / - 80 ms.  So, 
> using the USB GPS is about a 12 fold improvement.  Also, there are many 
> many computers where there is no RS-232 port.  ESR's application is an 
> example.  So, the question is not is NMEA great, the question is - is it 
> good enough for me?  I will be pursuing PPS with the Sure board for 
> intellectual reasons, but there is no reason that I have to do that.

There is a question about the Windows port of NTP which I don't have the 
answer to.  Dave Hart has put a lot of work into the Windows port, both in 
the serial data handling, and the serial port driver itself.  What I don't 
know is whether his enhancement to the serial port time-stamping also 
apply to the virtual COM port drivers such as would be used for NMEA over 
USB.  I expect they would, though.  I would recommend using at least ntp 
4.2.7p258 with Windows for the best results, and also setting the system 
environment variable NTPD_USE_SYSTEM_CLOCK to any value when using Windows 
Vista or Windows 7.


Are you using that version or later?

> There is no way in the world I should have an offset from internet 
> servers of 950 ms one minute and then show an offset from internet 
> servers of 50 ms thirty seconds later after I restart NTPD, when I'm 
> locked to my GPS time in both cases.

Agreed, but it suggests that the NMEA data may be timed so that it is 
ambiguous as to which second it means.  I did also wonder whether your GPS 
might have lost lock, and not indicated that to NTP.  I don't recall 
whether all sentences include a "lock" or "valid" indicator, and whether 
NTP looks at all such indicators.  Could someone check or confirm this, pr 
provide a pointer to the Web page with this information?

> I can tell when my GPS is working consistently and when it's not. 
> Something is wonky here and I don't think it's the GPS.  I'm trying to 
> figure out if the GPS is "drifting" or if NTP is reporting internet 
> server offsets wrong or if there is a problem with the Meinberg monitor. 
> If everything is running properly, I should be able to maintain that + 
> / - 6 ms all day, every day, and the variance between my clock and at 
> least one NIST clock should be minimal and consistent.  I don't expect 
> great results from NMEA.  But I do expect acceptable results, and 
> consistent results.  My GPS should be more than capable of outputting 
> NMEA sentences consistently.  I've seen it maintain that + / - 6 ms 
> performance for days.

.. suggesting that it may be a loss of GPS lock which is the issue, as 
that may not happen very often.

> It's only outputting the GPZDA sentence, and that only has time in it.

.. and it doesn't carry any indicator of whether that time is valid or 
not, according to:


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.

> The unit has nothing better to do than to tell me the time.  It should 
> not be "drifting".  But, SOMETHING is drifting, and I'd just like to 
> know what it is.  I REALLY think there is a problem with NTP or 
> Meinberg, but I could be wrong.  It would be nice to know if I have to 
> avoid all SIRF GPS's for this purpose.  I think NTP should be able to 
> work just fine, within the limits of the equipment, on NMEA only.
> No offense is intended in any way by anything I've said.  As I said 
> before, I do appreciate all the help.  8-)
> Sincerely,
> Ron

I agree with you, Ron, that providing a serial output is steady, NTP 
should work perfectly with it.  By using a very high baud rate, and a 
single sentence, you are making the best attempt to reduce the ambiguity 
between the beginning and the end of the NMEA data.

I recall that there is a way of monitoring one source against another. 
Someone will correct me, but it's something like using NOSELECT against 
that source.  Use the Internet servers as a reference, and monitor 
peerstats.  Then look for all the lines with (or whatever for 
the NMEA ref clock), and plot their offsets.

May be worth doing if you have the time.


More information about the questions mailing list