[ntp:hackers] refclock_atom.c

David L. Mills mills at udel.edu
Sun Dec 19 15:04:57 PST 2004


Mark,

You correctly concluded the huffpuff is global, not association 
specific. Naughty me; I intended to say that in the documentation, but 
at least the ntpd page doesn't say that. I thought about doing it (only) 
for the prefer peer. Do you have a preference?

Dave

Mark Martinec wrote:

>Dave,
>
>It looks I found the second bug which was giving me grey hair ever since
>I started playing with the addition of the pps atom driver to my setup.
>
>Remember, the symptoms were that, when the atom refclock was there
>but given a 'noselect' (and after widening the RANGEGATE in atom driver
>from 0.5 ms to 5 ms), everything looked nice and well, the logged
>offset samples from both the pps clock and from the remote ntp peer
>were in accordance with each other when examining the plot.
>
>As soon as I remove the 'noselect' on the pps, what started happening
>was the loop offset jumped to about +2ms or to about -2ms
>(altering between the two every couple of hours).
>
>The setup is: a remote ntp server is flagged as 'prefer' and is in charge
>or counting seconds, and the pps comes in via atom driver. No other
>clock driver is present.
>
>It was a mystery why the offset was kept for hours at some 2 ms,
>and the loop frequency was not adjusted to correct it.
>
>The quantum leap was when I realized that there is about 4ms
>difference between the upper and the lower stable offset,
>which happens to be about half the roundtrip delay to the
>remote preferred ntp server.
>
>Guess what, the 4ms correction was coming from a huffpuff buffer,
>and it was issuing correction even when the pps source became selected!!!
>
>So the pps was being kicked in and out of being selected.
>When it was in, it was inappropriately given a 4ms correction
>by a huffpuff filter (which should only apply to network peer).
>When pps was kicked out for being a falseticker, the offset
>was correct again for some time. The unfortunate and confused
>loop filter decided that the best truth was somewhere inbetween,
>so it was either +2ms or -2ms off.
>
>Turning off huffpuff avoided the problem entirely,
>and the plot is now as it should be.
>
>So:
>- ntp_loopfilter.c needs to be fixed to not apply huffpuff correction
>  to the pps signal;
>- the atom driver needs to have rangegate widened from 0.5 ms to 5ms
>  as is in its specifications
>
>Mark
>
>P.S. (sorry for the double mail, I posted the first one from a wrong address)
>  
>




More information about the hackers mailing list