[ntp:questions] Strange jumps in PPM

unruh unruh at invalid.ca
Wed Aug 21 17:01:09 UTC 2013


On 2013-08-21, mike cook <michael.cook at sfr.fr> wrote:
>
> Le 21 ao?t 2013 ? 09:14, A C a ?crit :
>
>> On 8/20/2013 23:53, mike cook wrote:
>>> 
>>> Le 21 ao?t 2013 ? 08:33, mike cook a ?crit :
>>> 
>>>> 
>>>> Le 21 ao?t 2013 ? 08:03, A C a ?crit :
>>>> 
>>>>> Ok, so I saw the below event in the loops on my system which is
>>>>> controled by ATOM, SHM, and several internet servers.
>>>>> 
>>>>> I suspect it has to do with the GPS PPS output glitching during
>>>>> extreme satellite events (bad constellation arrangement, fringe
>>>>> signal, etc.)
>>>>> 
>>>>> Is there a way to have ntpd ignore the PPS quickly if it spins
>>>>> out of control?  The system recovers fairly quickly and the clock
>>>>> doesn't go too far out but it would be nice to avoid these
>>>>> jumps.
>>>>> 
>>>> 
>>> 
>>> I realize now that I didn't respond to the question :-( .  AFIK there
>>> are no knobs available to do this. It would be nice to be able to
>>> specify maximum acceptable offset or jitter by clock.
>> 
>> 
>> That would be very useful to have.  I could easily avoid these hiccups since they're so wildly different and sudden compared to the normal operation.

NTP of course cannnot tell the difference between your source going
wild, or your computer ( say a sidden temp rise due to heavy work load)
clock going wild. It HAS to trust the sources. Now if you have 5 sources
all of similar accuracy, then it could throw away one or two as false
tickers. but with only one PPS, it HAS to assume that the signal from
the source is good. It has nothing else to go by. 

You with hindsight could say-- clearly it was the source going wild--
but how could ntpd in the heat of the battle. 

>
>    It might be accomplished automatically by establishing a Figure Of Confidence over the life of the clock which could be the average of the previous n offsets and exclude the clock if an offset exceeding x times the average occurs. The clock offsets would then be monitored and the clock included when/if the offset over n samples returned to the previous average.
>
>> _______________________________________________
>> questions mailing list
>> questions at lists.ntp.org
>> http://lists.ntp.org/listinfo/questions



More information about the questions mailing list