[ntp:questions] Falseticker determination

A C agcarver+ntp at acarver.net
Thu Apr 5 19:42:49 UTC 2012


I did read that but unfortunately none of the advice worked for solving 
various issues.  ATOM was a falseticker initially because there was no 
prefer peer.  If I do add a prefer peer, ATOM starts working but it 
places the system at the mercy of that single prefer peer, ignoring all 
other peers for time adjustment.  I was able to see this when the single 
prefer peer (didn't matter which one) would spike and cause the system 
to go out of control.

I didn't really use a hacksaw in this case, more of a scalpel once I 
understood the program flow in clock_select.  I simply dropped the 
requirement that a prefer peer exist for ATOM to be enabled.

The additional trace lines were placed in extra locations in 
clock_select where no debugging statements existed.  I wanted to 
determine if flags or other settings were being met as the peers flowed 
through the clock_select routine.

On 4/5/2012 11:56, David L. Mills wrote:
> A C,
>
> Before you take a hacksaw to code, you should see the How NTP Works
> collection in the online documentation, in particular the clock select
> algorithm page. It includes advice on how to avoid falsetickers in cases
> like yours, including the use of tinker and/or tos commands. There
> should be no need of additional trace lines in the code, as there
> already are some that demonstrate the results of the clock select and
> clluster algorithms.
>
> D M
>
> A C wrote:
>
>> On 4/4/2012 18:52, E-Mail Sent to this address will be added to the
>> BlackLists wrote:
>>
>>> Dave Hart wrote:
>>>
>>>> A C<agcarver+ntp at acarver.net> wrote:
>>>>
>>>>> Where in the code of 4.2.7p270 is the determination that
>>>>> a peer is a falseticker? I'm looking through ntp_proto.c
>>>>> but I don't think I'm fully grasping how the determination
>>>>> is made and the peer marked.
>>>>>
>>>>> I want to put some debug lines in the area of the code
>>>>> where the falseticker is determined so I can figure out
>>>>> what conditions are causing the PPS to be marked as a
>>>>> false ticker.
>>>>
>>>>
>>>> Line 2519 of ntp_proto.c (in clock_select):
>>>> peer->new_status = CTL_PST_SEL_SANE;
>>>>
>>>> All survivors to that point in the code get the x, fleetingly. Those
>>>> that keep it fail to survive to line 2688:
>>>> peers[i].peer->new_status = CTL_PST_SEL_SELCAND;
>>>>
>>>
>>> I would have thought 2835 - 2855 might be where he would
>>> want to take a closer look.
>>
>>
>> Well that was a fun exercise. The end result is that the PPS is no
>> longer a false ticker and I don't need a prefer peer either. :)
>>
>> Believe it or not, it's actually working better this way. For
>> starters, the offset is staying within +/- 10 us of the PPS pulse.
>> Additionally, allowing the system to select the rest of the clocks
>> using the normal clock selection instead of a prefer peer has actually
>> quieted the sys_fuzz messages. Usually I was seeing a sys_fuzz message
>> perhaps once every couple minutes. Now I see one maybe once in a few
>> hours or more. Plus if any of the peers explodes for whatever reason
>> it doesn't wipe out my clock because the averaged time doesn't move much.
>> _______________________________________________
>> questions mailing list
>> questions at lists.ntp.org
>> http://lists.ntp.org/listinfo/questions
>
>
>



More information about the questions mailing list