[ntp:hackers] refclock_atom.c

David L. Mills mills at udel.edu
Mon Dec 20 11:13:37 PST 2004


The present code does the huffpuff processing in the loop filter module 
after the clock combining algorithm, so major modifications would have 
to be made for a per-association design. Until/unless that is done, I 
have put in a wrinkle that will huff the puff either if no prefer peer 
is declared or if the prefer peer matches the peer for the clock opdate. 
That should fix your problem.


Mark Martinec wrote:

>>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.
>Documenting it turns a bug into a feature, or so that say :)
>In my case (talking about my home site, not the one at our institute),
>turning off the huffpuff is not an option. If I do that, every
>backup or a larger file transfer shifts all remote ntp peers
>some 4 ms off, and declares the local pps a falseticker.
>The sudden jump in offset also makes the frequency change
>not a pretty sight. I would rather turn off PPS that give
>away the huffpuff, which makes ntpd hover quite nicely across
>the one-way congestions on the cable connection.
>>I thought about doing it (only) for the prefer peer.
>>Do you have a preference?
>A preference? Like writing for presents to Santa Claus? :)
>The current assumption for huffpuff is that all reference clocks
>are on the other side of a single network connection, and it is the
>single 'last mile' line that gets into asymmetric congested state.
>It clearly isn't the case for local reference clock like atom,
>which have roundtrip delay of 0. More generally, it also
>isn't so for other peers, each of them may have a differently
>behaving network leading to it, and sometimes the congested
>lines are on the remote server side.
>The best solution would be for each peer to have
>its own huffpuff buffer. Apart from costing some memory,
>I don't think this is a heavy price to pay. If huffpuff
>could be configurable (at least: enabled/disabled) individually
>on each 'server' config line, so much the better.
>For cases where a change of a selected peer rarely happens,
>a huffpuff could apply to the currently selected peer, but then
>the huffpuff buffer needs to be discarded when a switch to a
>different peer occurs. It probably wouldn't behave too well
>at my home site, where switching between remote ntp peers (or pps)
>happens occasionally, and resetting the huffpuff buffer would
>probably be too frequent, making it hardly useful.
>  Mark

More information about the hackers mailing list