Kernel PLL, microkernel and the simulator. - NTP

This is a discussion on Kernel PLL, microkernel and the simulator. - NTP ; 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 ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Kernel PLL, microkernel and the simulator.

  1. Kernel PLL, microkernel and the simulator.

    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

  2. Re: Kernel PLL, microkernel and the simulator.

    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


  3. Re: Kernel PLL, microkernel and the simulator.

    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


  4. Re: Kernel PLL, microkernel and the simulator.

    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.

  5. Re: Kernel PLL, microkernel and the simulator.

    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.


  6. Re: Kernel PLL, microkernel and the simulator.

    "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.


  7. Re: Kernel PLL, microkernel and the simulator.

    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.


+ Reply to Thread