[ntp:hackers] Mitigation update
mills at udel.edu
Wed Apr 8 18:37:32 UTC 2009
In an extended test with the modified mitigation algorithm two machines
drifted outside the intersection interval and became lost orphans. I
remodified the algorithm to avoid the intersection algorithm entirely if
orphan parents are about. Selection of the lowest distance parent is
done in the selection algorihtm, then passed along to step two in the
mitigation phase. It works now exactly as intended. I have updated the
Mitigation Rules and the prefer Peer page
In testing I found something else that might have been around for
awhile. In my tests the kernel discipline was enabled and that was okay.
After a day when no sources except two potential orphan parents were
available, the orphan children continued to hug the lowest distance
parent as expected. The unhugged orphan parent sailed away during the
interval, as it was undisciplined. However, when the sources were
restored, the huggable parent latched on just fine, but the unhuggable
parent showed sudden frequency offset of 160 PPM and took several hours
I suspect the kernel discipline may have an overflow bug, although it
might bite in only very rare circumstances. The discipline operates in
two modes, PLL below the Allan intercept and FLL above it. At the first
update after a day or so in FLL mode something might have overflowed.
Note that the lurch did not occured in only one machine.
I have advised previously not to use the kernel at very long update
intervals, as with the modem driver. This advice is extended to cases
where the update interval might ve very long due to orphan mode. The
original intent in the kernel design was that PLL or FLL mode be
selected by the user; however, what resulted was that FLL mode is hard
coded above the Allan intercept and optional below it.
More information about the hackers