[ntp:questions] Re: ntpd PLL and clock overshoot

user at domain.invalid user at domain.invalid
Mon Oct 16 15:54:00 UTC 2006


David,

I beg to seriously differ. To the extent the z transform of the impulse 
response preserves the poles and zeros of the poplynomial 
representation, the digital NTP loop behaves as an analog loop, at least 
in the linear regime of operation.

The initial frequency estimate measures only the frequency offset; the 
phase offset is left to fend for itsel, which could indeed result in an 
initial offset exceeding the "overshoot" target. The purpose of the 
state machine in the first place is to allow large initial poll 
intervals, as with telephone modem services.

Look more carefully at the clock state machine. If the initial offset is 
greater than the step threshold, the clock is set, which results in an 
initial offset of zero. After the stepout interval the frequency is 
measured and corrected, but the phase at that time could be quite large, 
even greater than the step threshold, in which case the clock is set 
again, resulting in no initial offset at all. On the other hand, if the 
resulting offset when the frequency is measured is less than the step 
threshold, ordinary linear mode results. This is NOT overshoot, just an 
initial phase error.

If the initial offset is less than the step threshold, the freqjuency 
measurement is made, but the phase is disciplined normally during the 
stepout interval. Again, this could result in a phase offset after the 
stepout interval, but this is NOT overshoot.

Dave

David Woolley wrote:
> In article <egj4uk$a18$1 at scrotar.nss.udel.edu>,
> user at domain.invalid (probably David Mills with an IT department that is 
> overzealous about preventing spam) wrote:
> 
> 
>>The modern NTP feedback loop is much more intricate than you report. It 
>>is represented as a hybrid phase/frequency feedback loop with a 
> 
> 
> There may be various finesses, but it is still the essentially analogue
> nature of the process that causes people to complain about overshoots
> and runaway frequency excursions.
> 
> 
>>state-machine driven initial frequency measurement. Details are in the 
> 
> 
> As I understand it, the initial frequency measurement is only applied
> when cold started (no ntp.drift). Moreover, the perceived problem being
> reported here is about the initial phase correction.  It is normal
> to have to make phase corrections many times the mean phase error
> on a restart, even though it isn't normal to have to do a signficant
> frequency correction.
> 
> 
>>There are lots of nasty little approximations in the PLL/FLL code due to 
>>imprecise measurement of some time intervals. While the design targe for 
>>overshoot is 5-6 percent, I would not be surprised if in some cases it 
>>is 10 percent.
> 
> 
> I think the problem here is that a human trying to manually control the
> effective frequency might have overshot by only 0.1%.  They would have
> slewed the phase in at the maximum acceptable rate and then made a
> step change in frequency at the moment they crossed a measured phase
> error of zero, stepping by minus the average rate of phase change 
> during the slew in.  Only then would they start operating anything 
> like the current algorithm.
> 
> What they are seeing is 10% of the original error after about an hour,
> when they know that they could have achieved 0.1% in under 10 minutes,
> assuming a 500ppm slew rate limit.  (They'd probably need some automation
> to time the transition accurately enough to get to 100 microseconds, as
> assumed here.)
> 
> The best way of implementing this is probably to provide the system with
> memory about the likely phase measurement noise, but a simpler approach
> of detecting the first zero crossing would probably work quite well.
> 




More information about the questions mailing list