Mark.Martinec at ijs.si
Mon Dec 20 06:17:29 PST 2004
> 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.
More information about the hackers