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<[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
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
