On 4/4/2012 18:52, E-Mail Sent to this address will be added to the
BlackLists wrote:
Dave Hart wrote:
A C<[email protected]> 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
[email protected]
http://lists.ntp.org/listinfo/questions
