[ntp:questions] SIRF time output wobble, GPS or NTP fault?
Ron Frazier (NTP)
timekeepingntplist at c3energy.com
Wed Mar 7 20:59:03 UTC 2012
On 3/7/2012 4:25 AM, David J Taylor wrote:
> "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.
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.
>> 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.
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. 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?
>> 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?
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.
>> 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.
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'm presuming it uses the ntpq command internally to get that
data but I don't know. 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
Based on the document you linked to, I can see only 2-3 ways to check
for a valid signal. One is the POS_STAT variable. One is the V
variable. And one is the AA.BB (signal strength) variable, maybe.
As far as I can tell, only GPRMC and GPGLL have the POS_STAT variable.
As you mentioned, only GPZDG has the V variable. It also has the signal
It doesn't look like GPGGA has any validation in it.
I do realize that the timing of the NMEA sentence is much less important
if you have PPS, but this is what I have to work with at the moment. It
would be good to know if NMEA can be used for at least a somewhat
reliable time signature. Of course, as you said, if there is a 170 ms
wobble in the NMEA data, the few ms of jitter in USB is irrelevant and
NMEA only is largely useless. One thing I'm trying to figure out is if
the NMEA data really has this wobble in the start times of the sentences
or if there is some kind of false reporting from the NTP subsystem. If
the wobble does exist, I'm wondering if it is intrinsic to all GPS's.
I am reluctant to switch to another sentence for a few reasons, assuming
NMEA only is ultimately usable at all for a few reasons:
A) The Trimble Resolution T manual specifically recommends GPZDA for
B) I was using GPGGA before, and was getting about + / - 12 ms accuracy
as I recall. Going to GPZDA improved it to + / - 6 ms.
C) I don't know if NTP even looks at the validity flags in the data.
D) Any NMEA sentence which reports position will be varying in length,
which will probably add more jitter to the communications path.
>> 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
>> No offense is intended in any way by anything I've said. As I said
>> before, I do appreciate all the help. 8-)
> 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 127.127.20.1 (or
> whatever for the NMEA ref clock), and plot their offsets.
The amount of time I have comes and goes. It may have to go, to a
point, since I have to do some things other than email like paying bills
and other household stuff.
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.
statsdir "C:\NTP Service\NTP\etc\"
Thanks for the help.
> May be worth doing if you have the time.
(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such. I don't always see new messages very quickly. If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)
timekeepingdude AT c3energy.com
More information about the questions