Miroslav,
You have not revealed the result of the experiment I suggested, so I
don't know whether the Linux kernel performs as expected with the
original design parameters.
I think we are done with this discussion. The kernel discipline loop is
conservatively designed according to sound engineering practice. This is
the practice in the systems engineering course I taught over several
years. You are invited to obstruct that practice to your own ends, but
not in the public distribution.
Dave
Miroslav Lichvar wrote:
On Wed, Jun 30, 2010 at 10:00:06PM +0000, David L. Mills wrote:
Is there somebody around here that understands feedback control
theory? You are doing extreme violence to determine a really simple
thing, the discipline loop impulse response. There is a much simpler
way.
It was a demonstration of what clknetsim can do. You may be able
to predict the result, but I'm not. I think being able to verify a
theory with simulations is always a good thing.
Of particular importance is the damping factor, which is evident
from the overshoot. If SHIFT_PLL is radically changed, I would
expect the overshoot to be replaced by an exponentially decaying
ring characteristic.
That's not what I see in tests on real hw and simulations with
SHIFT_PLL 2.
The change in SHIFT_PLL would result
in unstable behavior below 5 (32 s), as well as serious transients
if the discipline shifts from the daemon to the kernel and back. All
feedback loops become unstable unless the time constant is at least
several times the frequency update interval, which is this case is
one second. If you do want to explore how stability may be affected,
restore the original design and recompile the distribution with
NTP_MINPOLL changed from 3 to 1.
Is poll 1 SHIFT_PLL 4 really equal to poll 3 SHIFT_PLL 2 in this
respect? If you can provide information how to demostrate the
instability with SHIFT_PLL 2 and normal polls, it'll be much easier to
convince the kernel folks to change it back to 4.
With polls 3-10 and SHIFT_PLL 2, the only instability I've seen is
with very long update intervals (e.g. when the network connection
repeatedly goes up and down), the frequency will eventually start
jumping between +500 and -500 ppm. But kernel loop with SHIFT_PLL 4
and daemon loop with small poll intervals have the same problem, the
threshold is just 4 times higher for them.
clknetsim has a pll_clamp option which can be enabled to avoid this
instability, it clamps the PLL update interval to
tc * (1 << (ntp_shift_pll + 1)), where tc is the time constant in
seconds. I will be doing more testing with it and possibly propose to
include a similar code in the kernel.
As for runtime switching between daemon and kernel discipline, I
haven't tried that. I didn't even know it is supported by ntpd.
To fix the original problem reported to me, change the frequency
gain (only) by the square of 100 divided by the new clock frequency
in Hz. For instance, to preserve the loop dynamics with a 1000-Hz
clock, divide the frequency gain parameter by 100. In the original
nanokernel routine ktime.c at line 60 there is a line
SHIFT_PLL * 2 + time_constant.
Replacing it by SHIFT_PLL * 20 + time_constant would fix the
progblem for 1000-Hz clocks.
I'm not a kernel developer, but I think this is already fixed. Current
kernels can be configured to use a dynamic HZ (CONFIG_NO_HZ aka
tickless mode), so the ntp code had to be rewritten to allow such
operation. With SHIFT_PLL 4, the response and the overshoot is exactly
as you describe it should be.
BTW, the effect of changing SHIFT_PLL to 2 on clock accuracy in
various network conditions is shown here:
http://fedorapeople.org/~mlichvar/clknetsim/test1_exp.png
With poll 6 and 10ppb/s wander, the crossover is around 10ms jitter.
With larger jitters SHIFT_PLL 2 can be up to 2 times worse (it seems
this can't be improved by lowering the poll interval) and with very
small jitters it can be about 50 times better.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
