[ntp:hackers] Mitigation update

David Mills mills at udel.edu
Wed Apr 8 18:37:32 UTC 2009


Guys,

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 
http://www.eecis.udel.edu/~mills/ntp/html/prefer.html.

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 
to recover.

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.

Dave


More information about the hackers mailing list