Brian,

The data actually used to update the clock can be as old as seven poll
periods old. This is the result of the clock filter and is expected.
However, the dynamics of the clock discipline, in particular the time
constant, are designed for this condition. Theory requires that the
sampling rate of the feedback loop be at least the Nyquist rate, which
is twice the bandwidth (inverse time constant) of the loop filter. In
particular, the sampling rate of the NTP loop, even using only every
seventh sample, is twice the Nyquist rate.

Dave

brian.utterback@gmail.com wrote:
> I am trying to track down some weird interactions in the Solaris
> kernel and the kernel PLL used by NTP. As such I have been looking
> very closely at the kernel simulator shipped with the microkernel
> reference code.
>
> As nearly as I can tell, it appears that the simulator calls the
> ntp_adjtime syscall simulation once every simulated 64 seconds with
> the current offset. With this system, we see the classic kernel PLL
> behavior, with the offset over-shooting and making a damping function
> until the correct frequency is achieved and the offset is zero. All
> well and good.
>
> The thing is, that isn't how NTP generally works. NTP may poll it's
> servers at regular intervals, but the times that it ends up calling
> ntp_adjtime are more irregular. Furthermore, because of storage of the
> last 8 offset values for each server, when ntp_adjtime is called, the
> offset may not even be the current offset. Instead it could be up to 8
> polling periods old, although I have not observed it be more than 5.
> But that is still up to 5 minutes old for a 64 second polling period,
> but could even be an hour and 1 half if the polling period goes up to
> 1024.
>
> Am I missing something here? Maybe I have misunderstood the simulator.
> Can anyone shed some light on this for me?
>
> Brian Utterback
> brian dot utterback at sun dot com

On Jul 21, 10:35*pm, "David L. Mills" wrote:
> Brian,
>
> The data actually used to update the clock can be as old as seven poll
> periods old. This is the result of the clock filter and is expected.
> However, the dynamics of the clock discipline, in particular the time
> constant, are designed for this condition. Theory requires that the
> sampling rate of the feedback loop be at least the Nyquist rate, which
> is twice the bandwidth (inverse time constant) of the loop filter. In
> particular, the sampling rate of the NTP loop, even using only every
> seventh sample, is twice the Nyquist rate.
>
> Dave
>

Okay, so how is the bandwidth equal to the inverse TC, and is that the
TC as in 3 or as in 2^3=7? I don't understand the meaning of the term
bandwidth in this context. And when you say that it works even if you
only use every seventh sample, is that even if the sample is seven
poll intervals old every time?

Brian Utterback
brian dot utterback at sun dot com

blu wrote:

>
> Okay, so how is the bandwidth equal to the inverse TC, and is that the
> TC as in 3 or as in 2^3=7? I don't understand the meaning of the term

The time constant as linear time, i.e. 8.

> bandwidth in this context. And when you say that it works even if you

ntpd implements a phase locked loop in software. Phase locked loops
measure a phase error, low pass filter that measurement, and feed it
back as a frequency correction. The bandwidth is that of the low pass
filter and it is a fairly fundamental consequence of definition of
frequency that it is inversely proportional to the length of the
(significant part of the the) impulse response, i.e. the time constant.

> only use every seventh sample, is that even if the sample is seven
> poll intervals old every time?

Where the reason is actually slightly flawed is that Nyquist says that
you can accurately reproduce a signal which is hard band limited, but
that assumes you know the sampling points. In any case, the error
signal is not limited to the bandwidth and the low pass filter is far
from a brick wall filter, meaning there will be aliasing effects, which
will cause a sensitivity on sample rate if you only sample at only twice
the filter nose bandwidth.

I'm not 100% sure, but I don't think that the ntpd processing
compensates fully for the positions of the samples.

David,

You quote the sampling theorem, which is a little more powerful than
Nyquist. However, you are correct in that the NTP filter is not
brick-wall. To compensate for that, the minimum sampling rate is at
least twice the Nyquist rate. Having said all that, the proof is in the
very many simulation runs with the actual code, which confirms the
expected risetime and overshoot.

Dave

David Woolley wrote:
> blu wrote:
>
>>
>> Okay, so how is the bandwidth equal to the inverse TC, and is that the
>> TC as in 3 or as in 2^3=7? I don't understand the meaning of the term
>
>
> The time constant as linear time, i.e. 8.
>
>> bandwidth in this context. And when you say that it works even if you
>
>
> ntpd implements a phase locked loop in software. Phase locked loops
> measure a phase error, low pass filter that measurement, and feed it
> back as a frequency correction. The bandwidth is that of the low pass
> filter and it is a fairly fundamental consequence of definition of
> frequency that it is inversely proportional to the length of the
> (significant part of the the) impulse response, i.e. the time constant.
>
>> only use every seventh sample, is that even if the sample is seven
>> poll intervals old every time?
>
>
> Where the reason is actually slightly flawed is that Nyquist says that
> you can accurately reproduce a signal which is hard band limited, but
> that assumes you know the sampling points. In any case, the error
> signal is not limited to the bandwidth and the low pass filter is far
> from a brick wall filter, meaning there will be aliasing effects, which
> will cause a sensitivity on sample rate if you only sample at only twice
> the filter nose bandwidth.
>
> I'm not 100% sure, but I don't think that the ntpd processing
> compensates fully for the positions of the samples.

"David L. Mills" writes:

>David,

>You quote the sampling theorem, which is a little more powerful than
>Nyquist. However, you are correct in that the NTP filter is not
>brick-wall. To compensate for that, the minimum sampling rate is at
>least twice the Nyquist rate. Having said all that, the proof is in the
>very many simulation runs with the actual code, which confirms the
>expected risetime and overshoot.

Have those simulations also been run with weird clockfilter selection
simulations. Eg, the best one is always the 7th oldest, or it keeps
switching or.... Ie, the input is not a nice regular sampling, but has a
large random component. (Mind you I am not at all sure that this does not
make the sampling better, as the aliasing is spread out and becomes noise
rather than a regular low frequency feature.)
I suspect that it is fine even with that-- ie the random elimination by the
clock filter does not matter for the stability or reliability of the
scheme. The conservative values do make it very slow to respond, and much
worse than it could be in situations where there are changes in the system
parameter (eg temp changes during the day due to regular periods of use and
non-use of the computers) but that has been extensively discussed in the
past.


>Dave

>David Woolley wrote:
>> blu wrote:
>>
>>>
>>> Okay, so how is the bandwidth equal to the inverse TC, and is that the
>>> TC as in 3 or as in 2^3=7? I don't understand the meaning of the term
>>
>>
>> The time constant as linear time, i.e. 8.
>>
>>> bandwidth in this context. And when you say that it works even if you
>>
>>
>> ntpd implements a phase locked loop in software. Phase locked loops
>> measure a phase error, low pass filter that measurement, and feed it
>> back as a frequency correction. The bandwidth is that of the low pass
>> filter and it is a fairly fundamental consequence of definition of
>> frequency that it is inversely proportional to the length of the
>> (significant part of the the) impulse response, i.e. the time constant.
>>
>>> only use every seventh sample, is that even if the sample is seven
>>> poll intervals old every time?
>>
>>
>> Where the reason is actually slightly flawed is that Nyquist says that
>> you can accurately reproduce a signal which is hard band limited, but
>> that assumes you know the sampling points. In any case, the error
>> signal is not limited to the bandwidth and the low pass filter is far
>> from a brick wall filter, meaning there will be aliasing effects, which
>> will cause a sensitivity on sample rate if you only sample at only twice
>> the filter nose bandwidth.
>>
>> I'm not 100% sure, but I don't think that the ntpd processing
>> compensates fully for the positions of the samples.

Bill,

See the papes and reports on the NTP project page, including extensive
simulations and evaluations of the NTP algorithms, and then let's talk.

Davde

Unruh wrote:
> "David L. Mills" writes:
>
>
>>David,
>
>
>>You quote the sampling theorem, which is a little more powerful than
>>Nyquist. However, you are correct in that the NTP filter is not
>>brick-wall. To compensate for that, the minimum sampling rate is at
>>least twice the Nyquist rate. Having said all that, the proof is in the
>>very many simulation runs with the actual code, which confirms the
>>expected risetime and overshoot.
>
>
> Have those simulations also been run with weird clockfilter selection
> simulations. Eg, the best one is always the 7th oldest, or it keeps
> switching or.... Ie, the input is not a nice regular sampling, but has a
> large random component. (Mind you I am not at all sure that this does not
> make the sampling better, as the aliasing is spread out and becomes noise
> rather than a regular low frequency feature.)
> I suspect that it is fine even with that-- ie the random elimination by the
> clock filter does not matter for the stability or reliability of the
> scheme. The conservative values do make it very slow to respond, and much
> worse than it could be in situations where there are changes in the system
> parameter (eg temp changes during the day due to regular periods of use and
> non-use of the computers) but that has been extensively discussed in the
> past.
>
>
>
>>Dave
>
>
>>David Woolley wrote:
>>
>>>blu wrote:
>>>
>>>
>>>>Okay, so how is the bandwidth equal to the inverse TC, and is that the
>>>>TC as in 3 or as in 2^3=7? I don't understand the meaning of the term
>>>
>>>
>>>The time constant as linear time, i.e. 8.
>>>
>>>
>>>>bandwidth in this context. And when you say that it works even if you
>>>
>>>
>>>ntpd implements a phase locked loop in software. Phase locked loops
>>>measure a phase error, low pass filter that measurement, and feed it
>>>back as a frequency correction. The bandwidth is that of the low pass
>>>filter and it is a fairly fundamental consequence of definition of
>>>frequency that it is inversely proportional to the length of the
>>>(significant part of the the) impulse response, i.e. the time constant.
>>>
>>>
>>>>only use every seventh sample, is that even if the sample is seven
>>>>poll intervals old every time?
>>>
>>>
>>>Where the reason is actually slightly flawed is that Nyquist says that
>>>you can accurately reproduce a signal which is hard band limited, but
>>>that assumes you know the sampling points. In any case, the error
>>>signal is not limited to the bandwidth and the low pass filter is far
>>>from a brick wall filter, meaning there will be aliasing effects, which
>>>will cause a sensitivity on sample rate if you only sample at only twice
>>>the filter nose bandwidth.
>>>
>>>I'm not 100% sure, but I don't think that the ntpd processing
>>>compensates fully for the positions of the samples.