[ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

David Lord snews at lordynet.org
Wed Mar 14 11:14:23 UTC 2012


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 
>>>>> internet
>>>>> servers.
>>>>>
>>>>> http://dl.dropbox.com/u/9879631/drifting01-peerstats.20120312.jpg
>>>> 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 why.
>>>>
>>>> The internet servers appear to be 100% reliable seeing as they all 
>>>> agree.
>>>>
>>>> These kinds of things are why some hobbysts end up buying multiple GPS
>>>> (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.
>>>
>>> http://dl.dropbox.com/u/9879631/drifting02b%20-%20peerstats%20insane.jpg
>>
>> 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.
>>
>>
>> David
>>
>>
>>> When I get the Sure board, I plan to hang it on the pc in tandem with 
>>> this GPS and compare.
>>>
>>> Sincerely,
>>>
>>> Ron
>>>
>>>
> 
> 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.

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.

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:

loopstats.20120313
loop 71, 368+/-1360.5, rms 608.7, freq 1.24+/-0.173, var 0.112

peerstats.20120313
        ident     cnt     mean     rms      max     delay     dist     disp
==========================================================================
81.187.61.74      70   -0.123    0.506    1.255    0.416   21.959   10.600
158.152.1.76      69    0.118    0.927    2.025   17.864   28.174   10.205
130.88.200.4      70    6.099    1.686    3.553   23.694   33.833   10.345
90.155.53.94      68   -0.034    1.127    2.952   17.376   29.720   10.938
79.135.97.79      71    0.573    0.722    1.388   31.522   38.183   10.618
130.159.196.117   75    0.313    0.967    1.830   27.958   35.916    9.516


(2) GPS with PPS, local and internet servers, rms offset 3.4us:

loopstats.20120313
loop 1350, 4+/-25.6, rms 3.4, freq -35.28+/-0.222, var 0.067

peerstats.20120313
        ident     cnt     mean     rms      max     delay     dist     disp
==========================================================================
127.127.20.2    1350    0.000    0.003    0.028    0.000    0.928    0.928
##############   280    0.448    0.408    0.852    0.579    5.576    2.596
##############    77    0.730    1.043    2.351    1.142   23.142   10.625
##############   283    0.760    0.803    2.113    1.202    7.220    2.845
81.187.61.69      74    1.307    0.890    2.208    0.684   23.250   11.537
##############    67    0.676    0.882    1.779    0.598   22.961   10.411
81.187.61.74      71    1.113    0.542    1.359    0.956   21.766   10.415


David



More information about the questions mailing list