On 2014-09-09, Harlan Stenn <[email protected]> wrote: > The issue is that the huff-n-puff filter will work in the case where a > symmetrical delay becomes asymmetric, and it will "tolerate" or > "accommodate" an asymmetric delay (caused by a large download, for > example) for some period of time. > > This is a case where there is reasonably-understood asymmetry for a > given server, or across a given interface. > > That one is really hard to figure out.
Not if you have gps reference at both ends, though why you would not use the gps as the timesource then I do not know. (I guess you could have it only temporarily). May home connections are much slower one way than the other, and an assymmetric delay is very possible. If it really is stable, it would be nice to be able to remove it (like the fudge time1 for refclocks). But I also could not see the equivalent for network clocks. I agree that huff and puff is for temporary assymmetry. There is not way a permanant assymmeter could be detected by ntpd. But if there was a sudden onset, then one could use the free running computer clock to notice that (delta t vs roundtrip would show it). > _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
