[ntp:questions] Clock and Network Simulator
David L. Mills
mills at udel.edu
Thu Jul 1 19:47:02 UTC 2010
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.
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
>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
>That's not what I see in tests on real hw and simulations with
>>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:
>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.
More information about the questions