[ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.
Ron Frazier (NTP)
timekeepingntplist at c3energy.com
Wed Mar 14 14:05:58 UTC 2012
On 3/14/2012 7:14 AM, David Lord wrote:
> Ron Frazier (NTP) wrote:
>> On 3/13/2012 5:39 PM, David Lord wrote:
>>> Ron Frazier (NTP) wrote:
>>>> On 3/13/2012 2:40 PM, Chris Albertson wrote:
>>>>> On Tue, Mar 13, 2012 at 9:52 AM, Ron Frazier (NTP)
>>>>> <timekeepingntplist at c3energy.com> wrote:
>>>>>> Hi all,
>>>>>> I just woke up to a 50 SECOND clock error. Prior to the error,
>>>>>> with my PC
>>>>>> locked into the GPS and the internet servers noselected, here's
>>>>>> what my
>>>>>> peerstats looked like. Baseline is the GPS. Colored lines are
>>>>> Looks to me like that GPS, maybe lock lock and was able to "coast" on
>>>>> hold over for a while then fell off a cliff. If you have a log of
>>>>> satellite signal to noise ratios you might be able to figure out
>>>>> The internet servers appear to be 100% reliable seeing as they all
>>>>> These kinds of things are why some hobbysts end up buying multiple
>>>>> (different brands) Otherwise it is hard to sort out a GPS firmware
>>>>> bug from a solar storm or just that there were not sats visable to
>>>>> your indoor antenna for a few minutes
>>>>> I think your goal is to learn about all of this so these problems are
>>>>> a good thing. No one learns much from working systems. But if the
>>>>> goal is a reliable NTP server, the pool NTP servers can't be beat
>>>>> except by a good timing mode GPS, that has good self diagnostics and
>>>>> PPS. The self diagnostics part is important
>>>> The link you quoted just now is not the one that bugs me so much
>>>> today. This one is the one that bugs me today, where my clock was
>>>> stepped by 50 seconds for some reason.
>>> I'm on a text mostly system so why do you require me to use
>>> a web browser to help you?
>>> What is your current ntp.conf, ntpd version, operating system
>>> and response of "ntpq -crv -p" after ntpd has had at least
>>> a day to stabilise?
>>> Not so long ago you posted that you had an offset within
>>> +/- 6 ms but didn't give any evidence. Response from
>>> "ntpq -crv -p" or better a day from peer_summary or couple
>>> of days from loop_summary would be enough.
>>>> When I get the Sure board, I plan to hang it on the pc in tandem
>>>> with this GPS and compare.
>> Hi David L.,
>> I just figured the images and dropbox would be the fastest way to
>> distribute the information. I didn't think I could attach files to
>> messages going to the NTP questions mailing list.
>> I'll be glad to provide stats files if anyone is interested. Just
>> tell me how to distribute them.
>> 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.
> 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.
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.
> MSF radioclock mostly has offset below 1500us.
> DCF radioclock can have offset below 100us but reception is too
> variable being non existant for some periods each day.
> I use mrtg to monitor my servers because it's easy to see when
> a fault occurs but the graphs don't help to locate the cause.
> (1) Internet servers only, rms offset 609us:
> loop 71, 368+/-1360.5, rms 608.7, freq 1.24+/-0.173, var 0.112
> ident cnt mean rms max delay dist
> 220.127.116.11 70 -0.123 0.506 1.255 0.416 21.959
> 18.104.22.168 69 0.118 0.927 2.025 17.864 28.174
> 22.214.171.124 70 6.099 1.686 3.553 23.694 33.833
> 126.96.36.199 68 -0.034 1.127 2.952 17.376 29.720
> 188.8.131.52 71 0.573 0.722 1.388 31.522 38.183
> 184.108.40.206 75 0.313 0.967 1.830 27.958 35.916
> (2) GPS with PPS, local and internet servers, rms offset 3.4us:
> loop 1350, 4+/-25.6, rms 3.4, freq -35.28+/-0.222, var 0.067
> ident cnt mean rms max delay dist
> 127.127.20.2 1350 0.000 0.003 0.028 0.000 0.928
> ############## 280 0.448 0.408 0.852 0.579 5.576
> ############## 77 0.730 1.043 2.351 1.142 23.142
> ############## 283 0.760 0.803 2.113 1.202 7.220
> 220.127.116.11 74 1.307 0.890 2.208 0.684 23.250
> ############## 67 0.676 0.882 1.779 0.598 22.961
> 18.104.22.168 71 1.113 0.542 1.359 0.956 21.766
(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