[ntp:questions] SIRF time output wobble, GPS or NTP fault?
Ron Frazier (NTP)
timekeepingntplist at c3energy.com
Thu Mar 8 13:32:44 UTC 2012
On 3/8/2012 3:36 AM, David J Taylor wrote:
> "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?
On the Status tab, that's where it displays all the offsets, similar to
the ntpq -p command. I don't know how it gets this data. On the
Statistics screen, if you select the directory where your statistics
files are, you can graph either loopstats or peerstats files. I think
clockstats is the third type. I don't know if there is anything to
graph in that or not.
>> 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.
OK. I see your point. They call that FIX_MODE on this page which you
I didn't see that field before.
>> 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.
Based on the aforementioned web page, it looks like the possible
validity fields are as follows:
GPRMC sentence - POS_STAT
GPGLL sentence - POS_STAT
GPGGA sentence - FIX_MODE
GPZDA sentence - none, as you observed
GPZDG sentence - V or maybe signal strength
I don't know if my GPS will do GPZDG. Otherwise I might try it. It may
be proprietary to some GPS's.
We still don't know if NTPD recognizes any of these fields, or if the
behavior is different in Windows and Linux. If it does, I might switch
back to another sentence. However, I already know it will increase my
NMEA jitter. If I can get PPS working, that won't matter as much.
That's not an option with the BU-353 though.
>> 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
>> enable stats
>> statsdir "C:\NTP Service\NTP\etc\"
>> statistics loopstats
>> Thanks for the help.
> 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.
Peerstats is now on. Not totally sure what to do with it, but it's there.
(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