On Tue, Sep 9, 2014 at 6:58 PM, Harlan Stenn <st...@ntp.org> 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.
I was overly casual. If you follow the breadcrumbs you find that there is no general solution to the problem. On Thu, Sep 11, 2014 at 9:35 AM, Martin Burnicki <martin.burni...@meinberg.de> wrote: > The case mentioned by the original poster is just one possible reason. Not to suggest that someone is doing something unreasonable but again why does time derived from the back-up clock need to be as accurate as the local clock (say .5ms versus 2ms)? If there's a legitimate need then trying to solve the problem with the wrong tool will only lead to frustration and complaints that NTP is buggy. If I *needed* highly available and accurate time at home I'd get a constellation of stable oscillators to drive time rather than hoping a remote clock or set of clocks was going to solve my problem. As an aside has anyone tried shaping traffic to make the upstream/downstream latencies similar? It would seem more efficient to apply network solutions to network problems if possible. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
