On 2014-01-14, Terje Mathisen <[email protected]> wrote: > Harlan Stenn wrote: >> William Unruh writes: >> >>> And a standard has no business to specify how a program achieves the >>> goals. It certainly has a business to specify what how the packets >>> are structured, and perhaps even suggest what standards it should >>> achieve in disciplining the clock, but how it does that should be no >>> business of the standard. It would be like saying that all editors >>> should only use ASCII. >> >> I disagree with you. > > You should probably state your reason(s) for doing so! > > There is one big & sufficient reason for including the underlying > algorithms in the standard, not just the packet format: > > The entire NTP ensemble, from the current machine and up to all its > sources, constitute a distributed control loop, right? > > This means that the stability and eventual precision of any given clock > depends upon exactly how all the source (server/peer) clocks behave, it > is easy to come up with scenarios that will become unstable and lead to > oscillating clocks. > > This is of course not an issue for any leaf node (pure client), as they > cannot propagate any introduced errors, but for server machines the > hybrid FLL/PLL control loop is very much a part of the standard.
Well, no. It is precisely to stop feedback loops that the whole issue of stratum was set up. A stratum x system cannot use a stratum y>x as a source or it becomes a stratum y+1 system. Without feedback you are not going to get instability. If this were possible, it would be a problem even with the ntpd algorithm. The specification could well set standards that a server should meet to act as a server. That would be well within its remit. But stating in detail how it should do so is not. Certainly making suggestions as to how an ntp device should work is fine. But demanding that they use a particular algoritm (for example Mill's statement that the Pool has ways of determining that a server runs ntpd and blackballing it if they do not is, I believe not appropriate, unless it can be shown that such servers harm the pool.) > > Terje _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
