Hi > On Nov 10, 2014, at 1:59 AM, Poul-Henning Kamp <[email protected]> wrote: > > -------- > In message <[email protected]>, Bob Camp writes: >> Hi >> >> Here’s what I’m saying: >> >> The NTP algorithm as it is written and as it is implemented results >> in an output clock that does *not* improve when a number of very >> good clocks are being used [...] > > The crucial word here is "good clocks". > > A "good clock" in NTP is nearby and because it is nearby, the chances > of several of them overlapping is usually not high enough for any > clock combining to happen.
Yes, in normal NTP land it’s not in any way worth worrying about. > > The NTP algorithms were built for 10-100msec packet delays, not > low microsecond packet delays. NTP is designed to do something very different. Bob > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [email protected] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
