[ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.
snews at lordynet.org
Wed Mar 14 15:31:12 UTC 2012
Ron Frazier (NTP) wrote:
> On 3/14/2012 7:14 AM, David Lord wrote:
>> Ron Frazier (NTP) wrote:
>>> Based on advice from David Taylor, I just changed my configuration.
>>> Previously, I had only the GPS selectable and the internet servers
>>> noselected for testing purposes to try to determine where a slow
>>> drifting behavior is coming from. Now, I have changed that so the
>>> GPS is noselected and the New York NIST server is the preferred and
>>> only selectable peer. I am monitoring the GPS and other internet
>>> servers for comparison. So, it will be a couple of days before this
>>> configuration accumulates some stats files.
>>> Even though I have been tinkering with this GPS for a couple of
>>> months, I have never seen anything like the 50 second jump I started
>>> this thread about. That problem may not be reproducible for some
>>> time, if at all.
>> Faulty GPS, incorrect configuration, anybodies guess?
>> Internet servers give me an rms offset about 610us, whilst GPS
>> with PPS gives about 4us. There are day to day variations and
>> some rare 'events' when GPS or an internet server goes bad.
> You must LIVE on the internet backbone and have blazing fast routers to
> get performance like that. My typical performance from internet servers
> is offsets of + / - 60 ms.
I don't live on the internet backbone nor do I have blazingly
fast anything. I have a slow 2Mbit/s ADSL connection.
You must have a very broken internet connection to get offsets
that high. A few times I've been routed by satelite or some
wireless connection and I also sometimes use mobile broadband
but still don't see offsets as large as 60ms.
>> GPS without PPS, Globalsat BR304, wasn't worth using as ntp
>> source due to large variations in offset from the NMEA sentences
>> that were tried with RMC being best giving 50% of offsets under
>> 10ms but maximum offsets being near 100ms.
> With my BU-353, which is similar, by setting the baud rate to 57,600,
> programming for ONLY GPGGA sentence, and polling every 8 seconds, I can
> keep my offsets from the GPS's estimate of true time to usually around +
> / - 5 ms with spikes to 10 ms and almost never higher. If I use ONLY
> the GPZDA sentence, which is essentially fixed length and reports only
> time, I can get that down to + / - 3 ms most of the time with spikes to
> 6 ms. However, David Taylor pointed out that the GPZDA sentence doesn't
> have any validity check field, and the GPGGA sentence does. We verified
> that the refclock.c code does check for this. So, I'm back to using
> GPGGA even with a bit more jitter. That way, if the GPS fails, ntpd is
> more likely to react gracefully.
What are you using as a reference to verify the offsets you
get are offsets from UTC?
> The problem with using my BU-353 in this way is that the start times for
> the NMEA sentence seem to wander over about 60 ms in either direction
> over a period of about 4 days. So, over a few days, my computer's time
> will drift away from true UTC time by that amount, and back again.
> However, over the short term, my pc's clock is much more stable than if
> I use internet servers as my primary source.
Can you give your ntp.conf that result in that level of
offset from internet servers?
The ntp distribution might still have some advice and
tools for selection of suitable sources. I just select
from the list of uk public servers at ntp.org and try
each one to get rtt and their sources then select the
ones that are closest with different sources. If you
don't want to do that you can specify your local ntp
pool. You should select at least four sources. I have
about eight different sources split between
ntp0.lordynet.org and ntp1.lordynet.org.
More information about the questions