Bill,
You have absolutely no idea what you are talking about and you do reveal
an abysmal lack of understudying of control theory. To incorporate past
history in future controls when the current control variable is measured
violates the time delay constrain. Go back to the books.
Dave
unruh wrote:
On 2010-11-04, David L. Mills <mi...@udel.edu> wrote:
Miroslav,
The NTP daemon purposely ignores the leftover from adjtime(). To do
otherwise would invite massive instability. Each time an NTP update is
received, a new offset estimate is available regardless of past history.
Therefore, the intent is to ignore all past history and start with a
fresh update. Note that the slew rate of adjtime() is not a factor with
the kernel discipline.
That is of course a philosophical position, and a strange one. Clocks
are largely predictable systems ( that is why they are used as clocks).
Thus the past history is strongly determinative of what the future
behaviour will be. To act as if this is not true, that each now
measurement should be treated as if it completely disconnected with the
past is a strange way of treating a highly predictable system. That is
of course one of the key places where ntpd and chrony differ. The
evidence is that properly taking account of the past does not create "massive
instability" but rather creates far more accurate discipling of the
clock than does past amnesia.
Dave
Miroslav Lichvar wrote:
On Wed, Nov 03, 2010 at 04:06:39PM +0000, Dave Hart wrote:
On Wed, Nov 3, 2010 at 09:24 UTC, Miroslav Lichvar <mlich...@redhat.com> wrote:
On Tue, Nov 02, 2010 at 10:03:30PM +0000, David L. Mills wrote:
I ran the same test here on four different machines with the
expected results. These included Solaris on both SPARC and Intel
machines, as well as two FreeBSD machines.
[...]
Ok, I think I have found the problem. The adj_systime() routine is
called from adj_host_clock() with adjustments over 500 microseconds,
which means ntpd is trying to adjust the clock at a rate higher than
what uses the Linux adjtime(). It can't keep up and the lost offset
correction is what makes the ~170ppm frequency error.
Congratulations on isolating the problem. If adjtime() is returning
failure, ntpd will log that mentioning adj_systime. Do you see any of
those?
No, it's not an error in usage, adjtime() just don't have enough time
to apply whole correction and ntpd doesn't check the leftover, so
the offset is adjusted actually slower than what ntpd is assuming.
Is it a feature or a bug that FreeBSD and Solaris can apparently slew
faster than 500 PPM using adjtime()?
If it's a feature, is there a way we can detect at configure time what
the adjtime() slew limit is without actually trying it? We don't want
to require root for configure.
Probably not. I think I saw on one BSD system only 100ppm rate, so it
will have to be clamped to either the lowest rate from all supported
systems or to a constant defined in the configure script based on
the system and version.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
