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.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
