ntp discipline of local time? - NTP

This is a discussion on ntp discipline of local time? - NTP ; How does ntp actually discipline the local clock? I have a gps received attached to a computer which is disciplined by a remote clock over an ADSL line. (Ie, the gps does not act as a refclock -- it is ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: ntp discipline of local time?

  1. ntp discipline of local time?

    How does ntp actually discipline the local clock? I have a gps received
    attached to a computer which is disciplined by a remote clock over an ADSL
    line. (Ie, the gps does not act as a refclock -- it is purely to measure
    the actual offset of the system. It is only the remote server that actaully
    acts the ntp reference source.)
    I can watch how ntp alters the local clock in response to remote
    offsets. The response is not linear. rather it is "curved" as though the
    rate of the local clock were exponentially eliminating the offset. But this
    is between two succesive runnings of the loopstats. Where is this behaviour
    determined? -- ie which routines determines the response of the system
    between to successive measurements of the offset?




  2. Re: ntp discipline of local time?

    On 2008-03-23, Unruh wrote:

    > How does ntp actually discipline the local clock?


    ntpd alters (i.e. increases or decreases) the clock frequency to steer
    the system clock toward the best available estimate of the chosen
    time-base.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

  3. Re: ntp discipline of local time?

    Steve Kostecke writes:

    >On 2008-03-23, Unruh wrote:


    >> How does ntp actually discipline the local clock?


    >ntpd alters (i.e. increases or decreases) the clock frequency to steer
    >the system clock toward the best available estimate of the chosen
    >time-base.


    Actually I was wondering exactly where in the code this happens, and if ntp
    actually keeps adjusting the system clock continuously (one per second?).




    >--
    >Steve Kostecke
    >NTP Public Services Project - http://support.ntp.org/


  4. Re: ntp discipline of local time?

    Unruh wrote:
    > How does ntp actually discipline the local clock? I have a gps received


    If you are using the kernel time discipline, which you should be using
    for high accuracy, nptd doesn't discipline the clock; it is the kernel
    code that does that, based on measurements provided by ntpd.

    > attached to a computer which is disciplined by a remote clock over an ADSL
    > line. (Ie, the gps does not act as a refclock -- it is purely to measure
    > the actual offset of the system. It is only the remote server that actaully
    > acts the ntp reference source.)
    > I can watch how ntp alters the local clock in response to remote
    > offsets. The response is not linear. rather it is "curved" as though the
    > rate of the local clock were exponentially eliminating the offset. But this


    That sounds very plausible. The clock discipline code solves for both
    frequency and phase errors. The phase error is probably being filtered
    using an IIR filter, and that is what you are seeing, and also the
    mechanism ntpd uses to stop wandering off if it stops receiving updates
    (the frequency measurement error can produce unbounded phase errors, but
    the phase error correction is bounded).


    > is between two succesive runnings of the loopstats. Where is this behaviour
    > determined? -- ie which routines determines the response of the system
    > between to successive measurements of the offset?


    If you don't use the kernel discipline, on Unix-like systems, it will
    implement the same filters in user space and apply phase adjustments at
    each kernel update. For ntpv3, those updates were every 4 seconds; for
    ntpv4, I believe it does them every second. A normal Unix-like system
    will implement the phase change by increasing or decreasing the amount
    by which the software clock is updated for every tick by +/- 500ppm,
    until the adjustment is complete.

    Windows has a different kernel interface, and I believe that ntpd
    modulates the effective length of a tick.

    Note, in spite of what other replies may imply, the physical clock
    frequency is never actually changed; what is actually changed is the
    amount by which the software clock is incremented for ever n-cycles of
    whatever is used for the reference frequency.

    If you want the actual code and fine details, you will be able to find
    them as easily as I will, so I'll leave that as an exercise for the reader.

    >
    >


  5. Re: ntp discipline of local time?

    David Woolley writes:

    >Unruh wrote:
    >> How does ntp actually discipline the local clock? I have a gps received


    >If you are using the kernel time discipline, which you should be using
    >for high accuracy, nptd doesn't discipline the clock; it is the kernel
    >code that does that, based on measurements provided by ntpd.


    I do not think that this is right, unless you are referring to a PPS
    sounce. ntp sets the frequency of the kerhel clock (Is that change in
    frequency what you mean by kernel time discipline) by a very simple second
    order PDE feedback, and the offset by and exponential first order feedback
    scheme. At least that is what it looks like to me trying to read
    ntp_loopfilter.c



    >> attached to a computer which is disciplined by a remote clock over an ADSL
    >> line. (Ie, the gps does not act as a refclock -- it is purely to measure
    >> the actual offset of the system. It is only the remote server that actaully
    >> acts the ntp reference source.)
    >> I can watch how ntp alters the local clock in response to remote
    >> offsets. The response is not linear. rather it is "curved" as though the
    >> rate of the local clock were exponentially eliminating the offset. But this


    >That sounds very plausible. The clock discipline code solves for both
    >frequency and phase errors. The phase error is probably being filtered
    >using an IIR filter, and that is what you are seeing, and also the
    >mechanism ntpd uses to stop wandering off if it stops receiving updates
    >(the frequency measurement error can produce unbounded phase errors, but
    > the phase error correction is bounded).



    >> is between two succesive runnings of the loopstats. Where is this behaviour
    >> determined? -- ie which routines determines the response of the system
    >> between to successive measurements of the offset?


    >If you don't use the kernel discipline, on Unix-like systems, it will
    >implement the same filters in user space and apply phase adjustments at
    >each kernel update. For ntpv3, those updates were every 4 seconds; for
    >ntpv4, I believe it does them every second. A normal Unix-like system
    >will implement the phase change by increasing or decreasing the amount
    >by which the software clock is updated for every tick by +/- 500ppm,
    >until the adjustment is complete.


    It is the linux system I am interested in. It looks to me like it adjusts
    the frequency with a simply second order feedback loop using the
    ntp_adjtime system call, and then drives the
    offset to zero with an exponential run once a second (?? I cannot
    disentangle the code to really be sure of this) using the adjtime system
    call. That exponential has a huge time constant-- something like 16 times
    the poll interval.



    >Windows has a different kernel interface, and I believe that ntpd
    >modulates the effective length of a tick.


    >Note, in spite of what other replies may imply, the physical clock
    >frequency is never actually changed; what is actually changed is the
    >amount by which the software clock is incremented for ever n-cycles of
    >whatever is used for the reference frequency.


    Of course. There is no way that the physical clock can be influenced by
    software. The system simply changes the relation between harware cpu cycle
    counts and time.


    >If you want the actual code and fine details, you will be able to find
    >them as easily as I will, so I'll leave that as an exercise for the reader.


    I guess I was hoping that perhaps the person/people who actually wrote the
    code could tell me what was going on in the code. While the code is
    reasonably annotated, those annotations do not give me at least a good
    sense of the overall picture.



    >>
    >>


  6. Re: ntp discipline of local time?

    Unruh,

    The kernel discipline is almost identical to the daemon discipline with
    the exception that the fancy code to combine the PLL and FLL near the
    Allan intercept is absent. Without the PPS signal, the discipline
    behaves as a second-order loop; with the PPS it behaves as two separate
    first-order loops, one for phase, the other for frequency. When
    necessary to set the freque directly, ther kernel is use for that. Note
    that the peripheral functions, like the clock state machine and
    poll-adjust algorithm continue in the daemon.

    Dave

    Unruh wrote:
    > David Woolley writes:
    >
    >
    >>Unruh wrote:
    >>
    >>>How does ntp actually discipline the local clock? I have a gps received

    >
    >
    >>If you are using the kernel time discipline, which you should be using
    >>for high accuracy, nptd doesn't discipline the clock; it is the kernel
    >>code that does that, based on measurements provided by ntpd.

    >
    >
    > I do not think that this is right, unless you are referring to a PPS
    > sounce. ntp sets the frequency of the kerhel clock (Is that change in
    > frequency what you mean by kernel time discipline) by a very simple second
    > order PDE feedback, and the offset by and exponential first order feedback
    > scheme. At least that is what it looks like to me trying to read
    > ntp_loopfilter.c
    >
    >
    >
    >
    >>>attached to a computer which is disciplined by a remote clock over an ADSL
    >>>line. (Ie, the gps does not act as a refclock -- it is purely to measure
    >>>the actual offset of the system. It is only the remote server that actaully
    >>>acts the ntp reference source.)
    >>>I can watch how ntp alters the local clock in response to remote
    >>>offsets. The response is not linear. rather it is "curved" as though the
    >>>rate of the local clock were exponentially eliminating the offset. But this

    >
    >
    >>That sounds very plausible. The clock discipline code solves for both
    >>frequency and phase errors. The phase error is probably being filtered
    >>using an IIR filter, and that is what you are seeing, and also the
    >>mechanism ntpd uses to stop wandering off if it stops receiving updates
    >>(the frequency measurement error can produce unbounded phase errors, but
    >> the phase error correction is bounded).

    >
    >
    >
    >>>is between two succesive runnings of the loopstats. Where is this behaviour
    >>>determined? -- ie which routines determines the response of the system
    >>>between to successive measurements of the offset?

    >
    >
    >>If you don't use the kernel discipline, on Unix-like systems, it will
    >>implement the same filters in user space and apply phase adjustments at
    >>each kernel update. For ntpv3, those updates were every 4 seconds; for
    >>ntpv4, I believe it does them every second. A normal Unix-like system
    >>will implement the phase change by increasing or decreasing the amount
    >>by which the software clock is updated for every tick by +/- 500ppm,
    >>until the adjustment is complete.

    >
    >
    > It is the linux system I am interested in. It looks to me like it adjusts
    > the frequency with a simply second order feedback loop using the
    > ntp_adjtime system call, and then drives the
    > offset to zero with an exponential run once a second (?? I cannot
    > disentangle the code to really be sure of this) using the adjtime system
    > call. That exponential has a huge time constant-- something like 16 times
    > the poll interval.
    >
    >
    >
    >
    >>Windows has a different kernel interface, and I believe that ntpd
    >>modulates the effective length of a tick.

    >
    >
    >>Note, in spite of what other replies may imply, the physical clock
    >>frequency is never actually changed; what is actually changed is the
    >>amount by which the software clock is incremented for ever n-cycles of
    >>whatever is used for the reference frequency.

    >
    >
    > Of course. There is no way that the physical clock can be influenced by
    > software. The system simply changes the relation between harware cpu cycle
    > counts and time.
    >
    >
    >
    >>If you want the actual code and fine details, you will be able to find
    >>them as easily as I will, so I'll leave that as an exercise for the reader.

    >
    >
    > I guess I was hoping that perhaps the person/people who actually wrote the
    > code could tell me what was going on in the code. While the code is
    > reasonably annotated, those annotations do not give me at least a good
    > sense of the overall picture.
    >
    >
    >
    >
    >>>


  7. Re: ntp discipline of local time?

    "David L. Mills" writes:

    >Unruh,


    >The kernel discipline is almost identical to the daemon discipline with
    >the exception that the fancy code to combine the PLL and FLL near the
    >Allan intercept is absent. Without the PPS signal, the discipline
    >behaves as a second-order loop; with the PPS it behaves as two separate
    >first-order loops, one for phase, the other for frequency. When
    >necessary to set the freque directly, ther kernel is use for that. Note
    >that the peripheral functions, like the clock state machine and
    >poll-adjust algorithm continue in the daemon.



    Let me concentrate on the situation without the PPS signal.
    Is the code in ntp_loopfilter.c the code which disciplines the clock?

    If so, then what it reads like to me is that ntp_adjtime (adjtimex in
    Linux) is used to alter the clock frequency each time a valid offset is
    delivered from the clock filter/peer finder routines. That frequency
    adjustment is a multiple of that offset (that multiple depending on the
    poll interval, etc) using the ntp_adjtime routine. Then that offset itself
    is driven to zero by using adjtime once per second and adjusting the clock
    by a small multiple of that offset. (something like 1/(16 times the poll
    interval) ) (let me not worry about the allan intercept stuff for now).

    Is my reading of the code correct? What I describe would, in the long term
    be a simple second order loop-- its interaction with the "clock-filter"
    algorithm is rather more complex than that, but lets leave that aside for
    now. Also the fact that the adjtime part of the routine simply throws away
    the part of the previous adjustment that was not completed-- I assume this
    is done because it almost never actually has any uncompleted adjustment.


    Is there anything else that is going on? Is "kernel discipline" anything
    more than the ability to change the frequency of the clock ( or rather
    change the factor that translates the CPU cycle counter to time)?

    Sorry to ask such detailed questions, but I am having a hard time
    disentangling the code to see what is really happening.


    >Dave


    >Unruh wrote:
    >> David Woolley writes:
    >>
    >>
    >>>Unruh wrote:
    >>>
    >>>>How does ntp actually discipline the local clock? I have a gps received

    >>
    >>
    >>>If you are using the kernel time discipline, which you should be using
    >>>for high accuracy, nptd doesn't discipline the clock; it is the kernel
    >>>code that does that, based on measurements provided by ntpd.

    >>
    >>
    >> I do not think that this is right, unless you are referring to a PPS
    >> sounce. ntp sets the frequency of the kerhel clock (Is that change in
    >> frequency what you mean by kernel time discipline) by a very simple second
    >> order PDE feedback, and the offset by and exponential first order feedback
    >> scheme. At least that is what it looks like to me trying to read
    >> ntp_loopfilter.c
    >>
    >>
    >>
    >>
    >>>>attached to a computer which is disciplined by a remote clock over an ADSL
    >>>>line. (Ie, the gps does not act as a refclock -- it is purely to measure
    >>>>the actual offset of the system. It is only the remote server that actaully
    >>>>acts the ntp reference source.)
    >>>>I can watch how ntp alters the local clock in response to remote
    >>>>offsets. The response is not linear. rather it is "curved" as though the
    >>>>rate of the local clock were exponentially eliminating the offset. But this

    >>
    >>
    >>>That sounds very plausible. The clock discipline code solves for both
    >>>frequency and phase errors. The phase error is probably being filtered
    >>>using an IIR filter, and that is what you are seeing, and also the
    >>>mechanism ntpd uses to stop wandering off if it stops receiving updates
    >>>(the frequency measurement error can produce unbounded phase errors, but
    >>> the phase error correction is bounded).

    >>
    >>
    >>
    >>>>is between two succesive runnings of the loopstats. Where is this behaviour
    >>>>determined? -- ie which routines determines the response of the system
    >>>>between to successive measurements of the offset?

    >>
    >>
    >>>If you don't use the kernel discipline, on Unix-like systems, it will
    >>>implement the same filters in user space and apply phase adjustments at
    >>>each kernel update. For ntpv3, those updates were every 4 seconds; for
    >>>ntpv4, I believe it does them every second. A normal Unix-like system
    >>>will implement the phase change by increasing or decreasing the amount
    >>>by which the software clock is updated for every tick by +/- 500ppm,
    >>>until the adjustment is complete.

    >>
    >>
    >> It is the linux system I am interested in. It looks to me like it adjusts
    >> the frequency with a simply second order feedback loop using the
    >> ntp_adjtime system call, and then drives the
    >> offset to zero with an exponential run once a second (?? I cannot
    >> disentangle the code to really be sure of this) using the adjtime system
    >> call. That exponential has a huge time constant-- something like 16 times
    >> the poll interval.
    >>
    >>
    >>
    >>
    >>>Windows has a different kernel interface, and I believe that ntpd
    >>>modulates the effective length of a tick.

    >>
    >>
    >>>Note, in spite of what other replies may imply, the physical clock
    >>>frequency is never actually changed; what is actually changed is the
    >>>amount by which the software clock is incremented for ever n-cycles of
    >>>whatever is used for the reference frequency.

    >>
    >>
    >> Of course. There is no way that the physical clock can be influenced by
    >> software. The system simply changes the relation between harware cpu cycle
    >> counts and time.
    >>
    >>
    >>
    >>>If you want the actual code and fine details, you will be able to find
    >>>them as easily as I will, so I'll leave that as an exercise for the reader.

    >>
    >>
    >> I guess I was hoping that perhaps the person/people who actually wrote the
    >> code could tell me what was going on in the code. While the code is
    >> reasonably annotated, those annotations do not give me at least a good
    >> sense of the overall picture.
    >>
    >>
    >>
    >>
    >>>>


  8. Re: ntp discipline of local time?

    Unruh wrote:
    > David Woolley writes:
    >
    >
    >> If you are using the kernel time discipline, which you should be using
    >> for high accuracy, nptd doesn't discipline the clock; it is the kernel
    >> code that does that, based on measurements provided by ntpd.

    >
    > I do not think that this is right, unless you are referring to a PPS
    > sounce. ntp sets the frequency of the kerhel clock (Is that change in
    > frequency what you mean by kernel time discipline) by a very simple second
    > order PDE feedback, and the offset by and exponential first order feedback
    > scheme. At least that is what it looks like to me trying to read
    > ntp_loopfilter.c
    >


    2.4 kernel (2.4.33): /usr/src/linux/kernel/timer.c

    417 /*
    418 * Compute the phase adjustment for the next second. In
    419 * PLL mode, the offset is reduced by a fixed factor
    420 * times the time constant. In FLL mode the offset is
    421 * used directly. In either mode, the maximum phase
    422 * adjustment for each second is clamped so as to spread
    423 * the adjustment over not more than the number of
    424 * seconds between updates.
    425 */

    loopfilter.c feeds the kernel with offset when it has a time update and
    it is in PLL mode. Note that a simple exponential decay is an IIR filter:

    From ntp v4.2p4: ntpd/ntp_loopfilter.c

    172 #define MOD_BITS (MOD_OFFSET | MOD_MAXERROR | MOD_ESTERROR | \
    173 MOD_STATUS | MOD_TIMECONST)

    gives the default set of ntpadjtime mode options.

  9. Re: ntp discipline of local time?

    David Woolley writes:

    >Unruh wrote:
    >> David Woolley writes:
    >>
    >>
    >>> If you are using the kernel time discipline, which you should be using
    >>> for high accuracy, nptd doesn't discipline the clock; it is the kernel
    >>> code that does that, based on measurements provided by ntpd.

    >>
    >> I do not think that this is right, unless you are referring to a PPS
    >> sounce. ntp sets the frequency of the kerhel clock (Is that change in
    >> frequency what you mean by kernel time discipline) by a very simple second
    >> order PDE feedback, and the offset by and exponential first order feedback
    >> scheme. At least that is what it looks like to me trying to read
    >> ntp_loopfilter.c
    >>


    >2.4 kernel (2.4.33): /usr/src/linux/kernel/timer.c


    > 417 /*
    > 418 * Compute the phase adjustment for the next second. In
    > 419 * PLL mode, the offset is reduced by a fixed factor
    > 420 * times the time constant. In FLL mode the offset is
    > 421 * used directly. In either mode, the maximum phase
    > 422 * adjustment for each second is clamped so as to spread
    > 423 * the adjustment over not more than the number of
    > 424 * seconds between updates.
    > 425 */


    The program interacts with the kernel through ntp_adjtime ( adjtimex on
    linux) I believe, so lets keep the discussion at that level.

    From what I see in ntp_loopfilter.c in




    >loopfilter.c feeds the kernel with offset when it has a time update and
    >it is in PLL mode. Note that a simple exponential decay is an IIR filter:


    NO, it also feeds it a frequency offset.
    I am not objecting to a simple exponential decay being an IIR filter. It is
    a very specific IIR filter.



    > From ntp v4.2p4: ntpd/ntp_loopfilter.c


    > 172 #define MOD_BITS (MOD_OFFSET | MOD_MAXERROR | MOD_ESTERROR | \
    > 173 MOD_STATUS | MOD_TIMECONST)


    >gives the default set of ntpadjtime mode options.


    And then line 595-597
    ntv.modes |= MOD_FREQUENCY;
    ntv.freq = (int32)((clock_frequency +
    drift_comp) * 65536e6);


    And then the whole of
    /*
    * adj_host_clock - Called once every second to update the local clock.
    *
    * LOCKCLOCK: The only thing this routine does is increment the
    * sys_rootdispersion variable.
    */

    whose key line is
    adjustment = clock_offset / (CLOCK_PLL * min(ULOGTOD(sys_poll),
    allan_xpt));
    clock_offset -= adjustment;
    adj_systime(adjustment + drift_comp);

    Now it is not clear to me that this is actually run once a second, or if
    this is only run once a second under certain conditions, or what.

    This certainly produces an exponential decay.




  10. Re: ntp discipline of local time?

    Unruh wrote:

    >
    > And then line 595-597
    > ntv.modes |= MOD_FREQUENCY;
    > ntv.freq = (int32)((clock_frequency +
    > drift_comp) * 65536e6);


    This is immediately preceded by:

    /*
    * The frequency is set directly only if
    * clock_frequency is nonzero coming out of FREQ
    * state.
    */
    if (clock_frequency != 0) {

    I.e. the frequency setting is a one off.


    >
    >
    > And then the whole of
    > /*
    > * adj_host_clock - Called once every second to update the local clock.
    > *
    > * LOCKCLOCK: The only thing this routine does is increment the
    > * sys_rootdispersion variable.
    > */


    Which starts with:

    /*
    * If clock discipline is disabled or if the kernel is enabled,
    * get out of Dodge quick.
    */
    if (!ntp_enable || mode_ntpdate || (pll_control &&
    kern_enable))
    return;

    I.E. the routine does nothing if the kernel discipline code is in use.

    >
    > This certainly produces an exponential decay.


    And is used for the user space clock discipline code.

  11. Re: ntp discipline of local time?

    "David L. Mills" writes:

    >Unruh,


    >The kernel discipline is almost identical to the daemon discipline with
    >the exception that the fancy code to combine the PLL and FLL near the
    >Allan intercept is absent. Without the PPS signal, the discipline
    >behaves as a second-order loop; with the PPS it behaves as two separate
    >first-order loops, one for phase, the other for frequency. When
    >necessary to set the freque directly, ther kernel is use for that. Note
    >that the peripheral functions, like the clock state machine and
    >poll-adjust algorithm continue in the daemon.


    OK, I have now gazed at the code some more, and see where the information
    is passed to the kernel discipline. But I am still confused. The discipline
    does two things-- set the system clock frequency (ie adjust the conversion
    factor from CPU cycles to time) and get rid of the offset. I am having a
    hard time figuring out exactly how it does the former. The later I
    understand is done by driving the offset to zero over a time scale
    something like 16 times the poll interval. But I do not understand the
    former. I think it looks something like

    F'=F+(offset)/constant.
    But I cannot figure out where this is actually done, and what that constant
    is.
    Thus, if you feed the system with an offset, the time goes like

    t=(F'T +offset (1-exp (T/C))
    where t is the clock time, T is the "raw" time,(CPU cycles) ,C is some
    constant like 16 times the poll interval,

    Bill



    >Dave


    >Unruh wrote:
    >> David Woolley writes:
    >>
    >>
    >>>Unruh wrote:
    >>>
    >>>>How does ntp actually discipline the local clock? I have a gps received

    >>
    >>
    >>>If you are using the kernel time discipline, which you should be using
    >>>for high accuracy, nptd doesn't discipline the clock; it is the kernel
    >>>code that does that, based on measurements provided by ntpd.

    >>
    >>
    >> I do not think that this is right, unless you are referring to a PPS
    >> sounce. ntp sets the frequency of the kerhel clock (Is that change in
    >> frequency what you mean by kernel time discipline) by a very simple second
    >> order PDE feedback, and the offset by and exponential first order feedback
    >> scheme. At least that is what it looks like to me trying to read
    >> ntp_loopfilter.c
    >>
    >>
    >>
    >>
    >>>>attached to a computer which is disciplined by a remote clock over an ADSL
    >>>>line. (Ie, the gps does not act as a refclock -- it is purely to measure
    >>>>the actual offset of the system. It is only the remote server that actaully
    >>>>acts the ntp reference source.)
    >>>>I can watch how ntp alters the local clock in response to remote
    >>>>offsets. The response is not linear. rather it is "curved" as though the
    >>>>rate of the local clock were exponentially eliminating the offset. But this

    >>
    >>
    >>>That sounds very plausible. The clock discipline code solves for both
    >>>frequency and phase errors. The phase error is probably being filtered
    >>>using an IIR filter, and that is what you are seeing, and also the
    >>>mechanism ntpd uses to stop wandering off if it stops receiving updates
    >>>(the frequency measurement error can produce unbounded phase errors, but
    >>> the phase error correction is bounded).

    >>
    >>
    >>
    >>>>is between two succesive runnings of the loopstats. Where is this behaviour
    >>>>determined? -- ie which routines determines the response of the system
    >>>>between to successive measurements of the offset?

    >>
    >>
    >>>If you don't use the kernel discipline, on Unix-like systems, it will
    >>>implement the same filters in user space and apply phase adjustments at
    >>>each kernel update. For ntpv3, those updates were every 4 seconds; for
    >>>ntpv4, I believe it does them every second. A normal Unix-like system
    >>>will implement the phase change by increasing or decreasing the amount
    >>>by which the software clock is updated for every tick by +/- 500ppm,
    >>>until the adjustment is complete.

    >>
    >>
    >> It is the linux system I am interested in. It looks to me like it adjusts
    >> the frequency with a simply second order feedback loop using the
    >> ntp_adjtime system call, and then drives the
    >> offset to zero with an exponential run once a second (?? I cannot
    >> disentangle the code to really be sure of this) using the adjtime system
    >> call. That exponential has a huge time constant-- something like 16 times
    >> the poll interval.
    >>
    >>
    >>
    >>
    >>>Windows has a different kernel interface, and I believe that ntpd
    >>>modulates the effective length of a tick.

    >>
    >>
    >>>Note, in spite of what other replies may imply, the physical clock
    >>>frequency is never actually changed; what is actually changed is the
    >>>amount by which the software clock is incremented for ever n-cycles of
    >>>whatever is used for the reference frequency.

    >>
    >>
    >> Of course. There is no way that the physical clock can be influenced by
    >> software. The system simply changes the relation between harware cpu cycle
    >> counts and time.
    >>
    >>
    >>
    >>>If you want the actual code and fine details, you will be able to find
    >>>them as easily as I will, so I'll leave that as an exercise for the reader.

    >>
    >>
    >> I guess I was hoping that perhaps the person/people who actually wrote the
    >> code could tell me what was going on in the code. While the code is
    >> reasonably annotated, those annotations do not give me at least a good
    >> sense of the overall picture.
    >>
    >>
    >>
    >>
    >>>>


  12. Re: ntp discipline of local time?

    David,

    In the code you cite the interplay between the deamon frequency and
    kernel frequency was fragile and hard to follow. It is now more direct
    and easy to follow. It's in the ntp-dev branch as part of the general
    cleanup.

    I put a good deal of effort into the ornamental commentary, but not as
    much zeal as in the code itself, so sometimes the code might not do
    exactly what the ornament says.

    Dave

    David Woolley wrote:

    > Unruh wrote:
    >
    >>
    >> And then line 595-597
    >> ntv.modes |= MOD_FREQUENCY;
    >> ntv.freq = (int32)((clock_frequency +
    >> drift_comp) * 65536e6);

    >
    >
    > This is immediately preceded by:
    >
    > /*
    > * The frequency is set directly only if
    > * clock_frequency is nonzero coming out of FREQ
    > * state.
    > */
    > if (clock_frequency != 0) {
    >
    > I.e. the frequency setting is a one off.
    >
    >
    >>
    >>
    >> And then the whole of /*
    >> * adj_host_clock - Called once every second to update the local clock.
    >> *
    >> * LOCKCLOCK: The only thing this routine does is increment the
    >> * sys_rootdispersion variable.
    >> */

    >
    >
    > Which starts with:
    >
    > /*
    > * If clock discipline is disabled or if the kernel is enabled,
    > * get out of Dodge quick.
    > */
    > if (!ntp_enable || mode_ntpdate || (pll_control &&
    > kern_enable))
    > return;
    >
    > I.E. the routine does nothing if the kernel discipline code is in use.
    >
    >>
    >> This certainly produces an exponential decay.

    >
    >
    > And is used for the user space clock discipline code.


  13. Re: ntp discipline of local time?

    Bill,

    You are going about this the wrong way. The discipline has its own
    chapter in my book, but you might not want to go there. An appendix of
    rfc 1305 discussed it in a primitive way. The Clock Discipline
    Principles and Precision Time Synchronization briefings on the NTP
    project page are old but applicable. The details you are asking for are
    carefully explained in the NTPv4 spec.

    Notice the second-order transfer function given both in my book and rfc
    1395 hss components of both phase and frequency. So the proper question
    for you to ask is whether the implementation faithfully computes that
    function. I claim it does and confirm by empirical verification of the
    impulse response as reported previously, both for the kernel and for the
    daemon. For the same time constant they both have the same response.

    Dave

    Bill Unruh wrote:

    > "David L. Mills" writes:
    >
    >
    >>Unruh,

    >
    >
    >>The kernel discipline is almost identical to the daemon discipline with
    >>the exception that the fancy code to combine the PLL and FLL near the
    >>Allan intercept is absent. Without the PPS signal, the discipline
    >>behaves as a second-order loop; with the PPS it behaves as two separate
    >>first-order loops, one for phase, the other for frequency. When
    >>necessary to set the freque directly, ther kernel is use for that. Note
    >>that the peripheral functions, like the clock state machine and
    >>poll-adjust algorithm continue in the daemon.

    >
    >
    > OK, I have now gazed at the code some more, and see where the information
    > is passed to the kernel discipline. But I am still confused. The discipline
    > does two things-- set the system clock frequency (ie adjust the conversion
    > factor from CPU cycles to time) and get rid of the offset. I am having a
    > hard time figuring out exactly how it does the former. The later I
    > understand is done by driving the offset to zero over a time scale
    > something like 16 times the poll interval. But I do not understand the
    > former. I think it looks something like
    >
    > F'=F+(offset)/constant.
    > But I cannot figure out where this is actually done, and what that constant
    > is.
    > Thus, if you feed the system with an offset, the time goes like
    >
    > t=(F'T +offset (1-exp (T/C))
    > where t is the clock time, T is the "raw" time,(CPU cycles) ,C is some
    > constant like 16 times the poll interval,
    >
    > Bill
    >
    >
    >
    >
    >>Dave

    >
    >
    >>Unruh wrote:
    >>
    >>>David Woolley writes:
    >>>
    >>>
    >>>
    >>>>Unruh wrote:
    >>>>
    >>>>
    >>>>>How does ntp actually discipline the local clock? I have a gps received
    >>>
    >>>
    >>>>If you are using the kernel time discipline, which you should be using
    >>>>for high accuracy, nptd doesn't discipline the clock; it is the kernel
    >>>>code that does that, based on measurements provided by ntpd.
    >>>
    >>>
    >>>I do not think that this is right, unless you are referring to a PPS
    >>>sounce. ntp sets the frequency of the kerhel clock (Is that change in
    >>>frequency what you mean by kernel time discipline) by a very simple second
    >>>order PDE feedback, and the offset by and exponential first order feedback
    >>>scheme. At least that is what it looks like to me trying to read
    >>>ntp_loopfilter.c
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>>>attached to a computer which is disciplined by a remote clock over an ADSL
    >>>>>line. (Ie, the gps does not act as a refclock -- it is purely to measure
    >>>>>the actual offset of the system. It is only the remote server that actaully
    >>>>>acts the ntp reference source.)
    >>>>>I can watch how ntp alters the local clock in response to remote
    >>>>>offsets. The response is not linear. rather it is "curved" as though the
    >>>>>rate of the local clock were exponentially eliminating the offset. But this
    >>>
    >>>
    >>>>That sounds very plausible. The clock discipline code solves for both
    >>>>frequency and phase errors. The phase error is probably being filtered
    >>>>using an IIR filter, and that is what you are seeing, and also the
    >>>>mechanism ntpd uses to stop wandering off if it stops receiving updates
    >>>>(the frequency measurement error can produce unbounded phase errors, but
    >>>>the phase error correction is bounded).
    >>>
    >>>
    >>>
    >>>>>is between two succesive runnings of the loopstats. Where is this behaviour
    >>>>>determined? -- ie which routines determines the response of the system
    >>>>>between to successive measurements of the offset?
    >>>
    >>>
    >>>>If you don't use the kernel discipline, on Unix-like systems, it will
    >>>>implement the same filters in user space and apply phase adjustments at
    >>>>each kernel update. For ntpv3, those updates were every 4 seconds; for
    >>>>ntpv4, I believe it does them every second. A normal Unix-like system
    >>>>will implement the phase change by increasing or decreasing the amount
    >>>>by which the software clock is updated for every tick by +/- 500ppm,
    >>>>until the adjustment is complete.
    >>>
    >>>
    >>>It is the linux system I am interested in. It looks to me like it adjusts
    >>>the frequency with a simply second order feedback loop using the
    >>>ntp_adjtime system call, and then drives the
    >>>offset to zero with an exponential run once a second (?? I cannot
    >>>disentangle the code to really be sure of this) using the adjtime system
    >>>call. That exponential has a huge time constant-- something like 16 times
    >>>the poll interval.
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>>Windows has a different kernel interface, and I believe that ntpd
    >>>>modulates the effective length of a tick.
    >>>
    >>>
    >>>>Note, in spite of what other replies may imply, the physical clock
    >>>>frequency is never actually changed; what is actually changed is the
    >>>>amount by which the software clock is incremented for ever n-cycles of
    >>>>whatever is used for the reference frequency.
    >>>
    >>>
    >>>Of course. There is no way that the physical clock can be influenced by
    >>>software. The system simply changes the relation between harware cpu cycle
    >>>counts and time.
    >>>
    >>>
    >>>
    >>>
    >>>>If you want the actual code and fine details, you will be able to find
    >>>>them as easily as I will, so I'll leave that as an exercise for the reader.
    >>>
    >>>
    >>>I guess I was hoping that perhaps the person/people who actually wrote the
    >>>code could tell me what was going on in the code. While the code is
    >>>reasonably annotated, those annotations do not give me at least a good
    >>>sense of the overall picture.
    >>>
    >>>
    >>>
    >>>
    >>>


  14. Re: ntp discipline of local time?

    "David L. Mills" writes:

    >Bill,


    >You are going about this the wrong way. The discipline has its own
    >chapter in my book, but you might not want to go there. An appendix of


    I finally did order your book, but it will take a while to get here.

    >rfc 1305 discussed it in a primitive way. The Clock Discipline
    >Principles and Precision Time Synchronization briefings on the NTP
    >project page are old but applicable. The details you are asking for are
    >carefully explained in the NTPv4 spec.


    Thanks. 1305 is just the start I want.
    Where is the NTPv4 spec located?

    >Notice the second-order transfer function given both in my book and rfc
    >1395 hss components of both phase and frequency. So the proper question
    >for you to ask is whether the implementation faithfully computes that
    >function. I claim it does and confirm by empirical verification of the


    I am willing to believe, barring contrary evidence, that your faithfully
    implimented the protocol. (and that the Linux people faithfully implimented
    the protocol in the kernel discipline routines).

    I am still trying to get a handle on why ntp has much worse behaviour than
    chrony does. I think I understand the chrony model ( although I would like
    to find somewhere where the raw adjtime ( not adjtimex) routine (or should
    I say the adjtimex SINGLESHOT routine) works.

    Anyway, thanks.


    >impulse response as reported previously, both for the kernel and for the
    >daemon. For the same time constant they both have the same response.


    >Dave


    >Bill Unruh wrote:


    >> "David L. Mills" writes:
    >>
    >>
    >>>Unruh,

    >>
    >>
    >>>The kernel discipline is almost identical to the daemon discipline with
    >>>the exception that the fancy code to combine the PLL and FLL near the
    >>>Allan intercept is absent. Without the PPS signal, the discipline
    >>>behaves as a second-order loop; with the PPS it behaves as two separate
    >>>first-order loops, one for phase, the other for frequency. When
    >>>necessary to set the freque directly, ther kernel is use for that. Note
    >>>that the peripheral functions, like the clock state machine and
    >>>poll-adjust algorithm continue in the daemon.

    >>
    >>
    >> OK, I have now gazed at the code some more, and see where the information
    >> is passed to the kernel discipline. But I am still confused. The discipline
    >> does two things-- set the system clock frequency (ie adjust the conversion
    >> factor from CPU cycles to time) and get rid of the offset. I am having a
    >> hard time figuring out exactly how it does the former. The later I
    >> understand is done by driving the offset to zero over a time scale
    >> something like 16 times the poll interval. But I do not understand the
    >> former. I think it looks something like
    >>
    >> F'=F+(offset)/constant.
    >> But I cannot figure out where this is actually done, and what that constant
    >> is.
    >> Thus, if you feed the system with an offset, the time goes like
    >>
    >> t=(F'T +offset (1-exp (T/C))
    >> where t is the clock time, T is the "raw" time,(CPU cycles) ,C is some
    >> constant like 16 times the poll interval,
    >>
    >> Bill
    >>
    >>
    >>
    >>
    >>>Dave

    >>
    >>
    >>>Unruh wrote:
    >>>
    >>>>David Woolley writes:
    >>>>
    >>>>
    >>>>
    >>>>>Unruh wrote:
    >>>>>
    >>>>>
    >>>>>>How does ntp actually discipline the local clock? I have a gps received
    >>>>
    >>>>
    >>>>>If you are using the kernel time discipline, which you should be using
    >>>>>for high accuracy, nptd doesn't discipline the clock; it is the kernel
    >>>>>code that does that, based on measurements provided by ntpd.
    >>>>
    >>>>
    >>>>I do not think that this is right, unless you are referring to a PPS
    >>>>sounce. ntp sets the frequency of the kerhel clock (Is that change in
    >>>>frequency what you mean by kernel time discipline) by a very simple second
    >>>>order PDE feedback, and the offset by and exponential first order feedback
    >>>>scheme. At least that is what it looks like to me trying to read
    >>>>ntp_loopfilter.c
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>>>attached to a computer which is disciplined by a remote clock over an ADSL
    >>>>>>line. (Ie, the gps does not act as a refclock -- it is purely to measure
    >>>>>>the actual offset of the system. It is only the remote server that actaully
    >>>>>>acts the ntp reference source.)
    >>>>>>I can watch how ntp alters the local clock in response to remote
    >>>>>>offsets. The response is not linear. rather it is "curved" as though the
    >>>>>>rate of the local clock were exponentially eliminating the offset. But this
    >>>>
    >>>>
    >>>>>That sounds very plausible. The clock discipline code solves for both
    >>>>>frequency and phase errors. The phase error is probably being filtered
    >>>>>using an IIR filter, and that is what you are seeing, and also the
    >>>>>mechanism ntpd uses to stop wandering off if it stops receiving updates
    >>>>>(the frequency measurement error can produce unbounded phase errors, but
    >>>>>the phase error correction is bounded).
    >>>>
    >>>>
    >>>>
    >>>>>>is between two succesive runnings of the loopstats. Where is this behaviour
    >>>>>>determined? -- ie which routines determines the response of the system
    >>>>>>between to successive measurements of the offset?
    >>>>
    >>>>
    >>>>>If you don't use the kernel discipline, on Unix-like systems, it will
    >>>>>implement the same filters in user space and apply phase adjustments at
    >>>>>each kernel update. For ntpv3, those updates were every 4 seconds; for
    >>>>>ntpv4, I believe it does them every second. A normal Unix-like system
    >>>>>will implement the phase change by increasing or decreasing the amount
    >>>>>by which the software clock is updated for every tick by +/- 500ppm,
    >>>>>until the adjustment is complete.
    >>>>
    >>>>
    >>>>It is the linux system I am interested in. It looks to me like it adjusts
    >>>>the frequency with a simply second order feedback loop using the
    >>>>ntp_adjtime system call, and then drives the
    >>>>offset to zero with an exponential run once a second (?? I cannot
    >>>>disentangle the code to really be sure of this) using the adjtime system
    >>>>call. That exponential has a huge time constant-- something like 16 times
    >>>>the poll interval.
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>>Windows has a different kernel interface, and I believe that ntpd
    >>>>>modulates the effective length of a tick.
    >>>>
    >>>>
    >>>>>Note, in spite of what other replies may imply, the physical clock
    >>>>>frequency is never actually changed; what is actually changed is the
    >>>>>amount by which the software clock is incremented for ever n-cycles of
    >>>>>whatever is used for the reference frequency.
    >>>>
    >>>>
    >>>>Of course. There is no way that the physical clock can be influenced by
    >>>>software. The system simply changes the relation between harware cpu cycle
    >>>>counts and time.
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>>If you want the actual code and fine details, you will be able to find
    >>>>>them as easily as I will, so I'll leave that as an exercise for the reader.
    >>>>
    >>>>
    >>>>I guess I was hoping that perhaps the person/people who actually wrote the
    >>>>code could tell me what was going on in the code. While the code is
    >>>>reasonably annotated, those annotations do not give me at least a good
    >>>>sense of the overall picture.
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>


  15. Re: ntp discipline of local time?


    >I am willing to believe, barring contrary evidence, that your faithfully
    >implimented the protocol. (and that the Linux people faithfully implimented
    >the protocol in the kernel discipline routines).


    Don't be so quick to believe that things work as expected.

    I seem to remember a report of some tweaks to some kernel software
    (probably Linux) to make it converge faster or something like that.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  16. Re: ntp discipline of local time?

    Unruh,

    The NTPv4 spec is an Internet Draft and can be found in the usual way.
    It can also be found on the NTP project page
    www.eecis.udel.edu/~mills/ntp.html. Look for NTPv4 specification project
    documents.

    Dave

    Unruh wrote:
    > "David L. Mills" writes:
    >
    >
    >>Bill,

    >
    >
    >>You are going about this the wrong way. The discipline has its own
    >>chapter in my book, but you might not want to go there. An appendix of

    >
    >
    > I finally did order your book, but it will take a while to get here.
    >
    >
    >>rfc 1305 discussed it in a primitive way. The Clock Discipline
    >>Principles and Precision Time Synchronization briefings on the NTP
    >>project page are old but applicable. The details you are asking for are
    >>carefully explained in the NTPv4 spec.

    >
    >
    > Thanks. 1305 is just the start I want.
    > Where is the NTPv4 spec located?
    >
    >
    >>Notice the second-order transfer function given both in my book and rfc
    >>1395 hss components of both phase and frequency. So the proper question
    >>for you to ask is whether the implementation faithfully computes that
    >>function. I claim it does and confirm by empirical verification of the

    >
    >
    > I am willing to believe, barring contrary evidence, that your faithfully
    > implimented the protocol. (and that the Linux people faithfully implimented
    > the protocol in the kernel discipline routines).
    >
    > I am still trying to get a handle on why ntp has much worse behaviour than
    > chrony does. I think I understand the chrony model ( although I would like
    > to find somewhere where the raw adjtime ( not adjtimex) routine (or should
    > I say the adjtimex SINGLESHOT routine) works.
    >
    > Anyway, thanks.
    >
    >
    >
    >>impulse response as reported previously, both for the kernel and for the
    >>daemon. For the same time constant they both have the same response.

    >
    >
    >>Dave

    >
    >
    >>Bill Unruh wrote:

    >
    >
    >>>"David L. Mills" writes:
    >>>
    >>>
    >>>
    >>>>Unruh,
    >>>
    >>>
    >>>>The kernel discipline is almost identical to the daemon discipline with
    >>>>the exception that the fancy code to combine the PLL and FLL near the
    >>>>Allan intercept is absent. Without the PPS signal, the discipline
    >>>>behaves as a second-order loop; with the PPS it behaves as two separate
    >>>>first-order loops, one for phase, the other for frequency. When
    >>>>necessary to set the freque directly, ther kernel is use for that. Note
    >>>>that the peripheral functions, like the clock state machine and
    >>>>poll-adjust algorithm continue in the daemon.
    >>>
    >>>
    >>>OK, I have now gazed at the code some more, and see where the information
    >>>is passed to the kernel discipline. But I am still confused. The discipline
    >>>does two things-- set the system clock frequency (ie adjust the conversion
    >>>factor from CPU cycles to time) and get rid of the offset. I am having a
    >>>hard time figuring out exactly how it does the former. The later I
    >>>understand is done by driving the offset to zero over a time scale
    >>>something like 16 times the poll interval. But I do not understand the
    >>>former. I think it looks something like
    >>>
    >>>F'=F+(offset)/constant.
    >>>But I cannot figure out where this is actually done, and what that constant
    >>>is.
    >>>Thus, if you feed the system with an offset, the time goes like
    >>>
    >>>t=(F'T +offset (1-exp (T/C))
    >>>where t is the clock time, T is the "raw" time,(CPU cycles) ,C is some
    >>>constant like 16 times the poll interval,
    >>>
    >>>Bill
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>>Dave
    >>>
    >>>
    >>>>Unruh wrote:
    >>>>
    >>>>
    >>>>>David Woolley writes:
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>>Unruh wrote:
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>How does ntp actually discipline the local clock? I have a gps received
    >>>>>
    >>>>>
    >>>>>>If you are using the kernel time discipline, which you should be using
    >>>>>>for high accuracy, nptd doesn't discipline the clock; it is the kernel
    >>>>>>code that does that, based on measurements provided by ntpd.
    >>>>>
    >>>>>
    >>>>>I do not think that this is right, unless you are referring to a PPS
    >>>>>sounce. ntp sets the frequency of the kerhel clock (Is that change in
    >>>>>frequency what you mean by kernel time discipline) by a very simple second
    >>>>>order PDE feedback, and the offset by and exponential first order feedback
    >>>>>scheme. At least that is what it looks like to me trying to read
    >>>>>ntp_loopfilter.c
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>>>attached to a computer which is disciplined by a remote clock over an ADSL
    >>>>>>>line. (Ie, the gps does not act as a refclock -- it is purely to measure
    >>>>>>>the actual offset of the system. It is only the remote server that actaully
    >>>>>>>acts the ntp reference source.)
    >>>>>>>I can watch how ntp alters the local clock in response to remote
    >>>>>>>offsets. The response is not linear. rather it is "curved" as though the
    >>>>>>>rate of the local clock were exponentially eliminating the offset. But this
    >>>>>
    >>>>>
    >>>>>>That sounds very plausible. The clock discipline code solves for both
    >>>>>>frequency and phase errors. The phase error is probably being filtered
    >>>>>>using an IIR filter, and that is what you are seeing, and also the
    >>>>>>mechanism ntpd uses to stop wandering off if it stops receiving updates
    >>>>>>(the frequency measurement error can produce unbounded phase errors, but
    >>>>>>the phase error correction is bounded).
    >>>>>
    >>>>>
    >>>>>
    >>>>>>>is between two succesive runnings of the loopstats. Where is this behaviour
    >>>>>>>determined? -- ie which routines determines the response of the system
    >>>>>>>between to successive measurements of the offset?
    >>>>>
    >>>>>
    >>>>>>If you don't use the kernel discipline, on Unix-like systems, it will
    >>>>>>implement the same filters in user space and apply phase adjustments at
    >>>>>>each kernel update. For ntpv3, those updates were every 4 seconds; for
    >>>>>>ntpv4, I believe it does them every second. A normal Unix-like system
    >>>>>>will implement the phase change by increasing or decreasing the amount
    >>>>>>by which the software clock is updated for every tick by +/- 500ppm,
    >>>>>>until the adjustment is complete.
    >>>>>
    >>>>>
    >>>>>It is the linux system I am interested in. It looks to me like it adjusts
    >>>>>the frequency with a simply second order feedback loop using the
    >>>>>ntp_adjtime system call, and then drives the
    >>>>>offset to zero with an exponential run once a second (?? I cannot
    >>>>>disentangle the code to really be sure of this) using the adjtime system
    >>>>>call. That exponential has a huge time constant-- something like 16 times
    >>>>>the poll interval.
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>>Windows has a different kernel interface, and I believe that ntpd
    >>>>>>modulates the effective length of a tick.
    >>>>>
    >>>>>
    >>>>>>Note, in spite of what other replies may imply, the physical clock
    >>>>>>frequency is never actually changed; what is actually changed is the
    >>>>>>amount by which the software clock is incremented for ever n-cycles of
    >>>>>>whatever is used for the reference frequency.
    >>>>>
    >>>>>
    >>>>>Of course. There is no way that the physical clock can be influenced by
    >>>>>software. The system simply changes the relation between harware cpu cycle
    >>>>>counts and time.
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>>If you want the actual code and fine details, you will be able to find
    >>>>>>them as easily as I will, so I'll leave that as an exercise for the reader.
    >>>>>
    >>>>>
    >>>>>I guess I was hoping that perhaps the person/people who actually wrote the
    >>>>>code could tell me what was going on in the code. While the code is
    >>>>>reasonably annotated, those annotations do not give me at least a good
    >>>>>sense of the overall picture.
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>>


  17. Re: ntp discipline of local time?

    "David L. Mills" writes:

    >Unruh,


    >The NTPv4 spec is an Internet Draft and can be found in the usual way.
    >It can also be found on the NTP project page
    >www.eecis.udel.edu/~mills/ntp.html. Look for NTPv4 specification project
    >documents.


    Thanks
    Bill


    >Dave


    >Unruh wrote:
    >> "David L. Mills" writes:
    >>
    >>
    >>>Bill,

    >>
    >>
    >>>You are going about this the wrong way. The discipline has its own
    >>>chapter in my book, but you might not want to go there. An appendix of

    >>
    >>
    >> I finally did order your book, but it will take a while to get here.
    >>
    >>
    >>>rfc 1305 discussed it in a primitive way. The Clock Discipline
    >>>Principles and Precision Time Synchronization briefings on the NTP
    >>>project page are old but applicable. The details you are asking for are
    >>>carefully explained in the NTPv4 spec.

    >>
    >>
    >> Thanks. 1305 is just the start I want.
    >> Where is the NTPv4 spec located?
    >>
    >>
    >>>Notice the second-order transfer function given both in my book and rfc
    >>>1395 hss components of both phase and frequency. So the proper question
    >>>for you to ask is whether the implementation faithfully computes that
    >>>function. I claim it does and confirm by empirical verification of the

    >>
    >>
    >> I am willing to believe, barring contrary evidence, that your faithfully
    >> implimented the protocol. (and that the Linux people faithfully implimented
    >> the protocol in the kernel discipline routines).
    >>
    >> I am still trying to get a handle on why ntp has much worse behaviour than
    >> chrony does. I think I understand the chrony model ( although I would like
    >> to find somewhere where the raw adjtime ( not adjtimex) routine (or should
    >> I say the adjtimex SINGLESHOT routine) works.
    >>
    >> Anyway, thanks.
    >>
    >>
    >>
    >>>impulse response as reported previously, both for the kernel and for the
    >>>daemon. For the same time constant they both have the same response.

    >>
    >>
    >>>Dave

    >>
    >>
    >>>Bill Unruh wrote:

    >>
    >>
    >>>>"David L. Mills" writes:
    >>>>
    >>>>
    >>>>
    >>>>>Unruh,
    >>>>
    >>>>
    >>>>>The kernel discipline is almost identical to the daemon discipline with
    >>>>>the exception that the fancy code to combine the PLL and FLL near the
    >>>>>Allan intercept is absent. Without the PPS signal, the discipline
    >>>>>behaves as a second-order loop; with the PPS it behaves as two separate
    >>>>>first-order loops, one for phase, the other for frequency. When
    >>>>>necessary to set the freque directly, ther kernel is use for that. Note
    >>>>>that the peripheral functions, like the clock state machine and
    >>>>>poll-adjust algorithm continue in the daemon.
    >>>>
    >>>>
    >>>>OK, I have now gazed at the code some more, and see where the information
    >>>>is passed to the kernel discipline. But I am still confused. The discipline
    >>>>does two things-- set the system clock frequency (ie adjust the conversion
    >>>>factor from CPU cycles to time) and get rid of the offset. I am having a
    >>>>hard time figuring out exactly how it does the former. The later I
    >>>>understand is done by driving the offset to zero over a time scale
    >>>>something like 16 times the poll interval. But I do not understand the
    >>>>former. I think it looks something like
    >>>>
    >>>>F'=F+(offset)/constant.
    >>>>But I cannot figure out where this is actually done, and what that constant
    >>>>is.
    >>>>Thus, if you feed the system with an offset, the time goes like
    >>>>
    >>>>t=(F'T +offset (1-exp (T/C))
    >>>>where t is the clock time, T is the "raw" time,(CPU cycles) ,C is some
    >>>>constant like 16 times the poll interval,
    >>>>
    >>>>Bill
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>>Dave
    >>>>
    >>>>
    >>>>>Unruh wrote:
    >>>>>
    >>>>>
    >>>>>>David Woolley writes:
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>Unruh wrote:
    >>>>>>>
    >>>>>>>
    >>>>>>>
    >>>>>>>>How does ntp actually discipline the local clock? I have a gps received
    >>>>>>
    >>>>>>
    >>>>>>>If you are using the kernel time discipline, which you should be using
    >>>>>>>for high accuracy, nptd doesn't discipline the clock; it is the kernel
    >>>>>>>code that does that, based on measurements provided by ntpd.
    >>>>>>
    >>>>>>
    >>>>>>I do not think that this is right, unless you are referring to a PPS
    >>>>>>sounce. ntp sets the frequency of the kerhel clock (Is that change in
    >>>>>>frequency what you mean by kernel time discipline) by a very simple second
    >>>>>>order PDE feedback, and the offset by and exponential first order feedback
    >>>>>>scheme. At least that is what it looks like to me trying to read
    >>>>>>ntp_loopfilter.c
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>>attached to a computer which is disciplined by a remote clock over an ADSL
    >>>>>>>>line. (Ie, the gps does not act as a refclock -- it is purely to measure
    >>>>>>>>the actual offset of the system. It is only the remote server that actaully
    >>>>>>>>acts the ntp reference source.)
    >>>>>>>>I can watch how ntp alters the local clock in response to remote
    >>>>>>>>offsets. The response is not linear. rather it is "curved" as though the
    >>>>>>>>rate of the local clock were exponentially eliminating the offset. But this
    >>>>>>
    >>>>>>
    >>>>>>>That sounds very plausible. The clock discipline code solves for both
    >>>>>>>frequency and phase errors. The phase error is probably being filtered
    >>>>>>>using an IIR filter, and that is what you are seeing, and also the
    >>>>>>>mechanism ntpd uses to stop wandering off if it stops receiving updates
    >>>>>>>(the frequency measurement error can produce unbounded phase errors, but
    >>>>>>>the phase error correction is bounded).
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>>is between two succesive runnings of the loopstats. Where is this behaviour
    >>>>>>>>determined? -- ie which routines determines the response of the system
    >>>>>>>>between to successive measurements of the offset?
    >>>>>>
    >>>>>>
    >>>>>>>If you don't use the kernel discipline, on Unix-like systems, it will
    >>>>>>>implement the same filters in user space and apply phase adjustments at
    >>>>>>>each kernel update. For ntpv3, those updates were every 4 seconds; for
    >>>>>>>ntpv4, I believe it does them every second. A normal Unix-like system
    >>>>>>>will implement the phase change by increasing or decreasing the amount
    >>>>>>>by which the software clock is updated for every tick by +/- 500ppm,
    >>>>>>>until the adjustment is complete.
    >>>>>>
    >>>>>>
    >>>>>>It is the linux system I am interested in. It looks to me like it adjusts
    >>>>>>the frequency with a simply second order feedback loop using the
    >>>>>>ntp_adjtime system call, and then drives the
    >>>>>>offset to zero with an exponential run once a second (?? I cannot
    >>>>>>disentangle the code to really be sure of this) using the adjtime system
    >>>>>>call. That exponential has a huge time constant-- something like 16 times
    >>>>>>the poll interval.
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>Windows has a different kernel interface, and I believe that ntpd
    >>>>>>>modulates the effective length of a tick.
    >>>>>>
    >>>>>>
    >>>>>>>Note, in spite of what other replies may imply, the physical clock
    >>>>>>>frequency is never actually changed; what is actually changed is the
    >>>>>>>amount by which the software clock is incremented for ever n-cycles of
    >>>>>>>whatever is used for the reference frequency.
    >>>>>>
    >>>>>>
    >>>>>>Of course. There is no way that the physical clock can be influenced by
    >>>>>>software. The system simply changes the relation between harware cpu cycle
    >>>>>>counts and time.
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>If you want the actual code and fine details, you will be able to find
    >>>>>>>them as easily as I will, so I'll leave that as an exercise for the reader.
    >>>>>>
    >>>>>>
    >>>>>>I guess I was hoping that perhaps the person/people who actually wrote the
    >>>>>>code could tell me what was going on in the code. While the code is
    >>>>>>reasonably annotated, those annotations do not give me at least a good
    >>>>>>sense of the overall picture.
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>


  18. Re: ntp discipline of local time?

    Unruh wrote:
    > "David L. Mills" writes:
    >
    >> Bill,

    >
    >> You are going about this the wrong way. The discipline has its own
    >> chapter in my book, but you might not want to go there. An appendix of

    >
    > I finally did order your book, but it will take a while to get here.
    >
    >> rfc 1305 discussed it in a primitive way. The Clock Discipline
    >> Principles and Precision Time Synchronization briefings on the NTP
    >> project page are old but applicable. The details you are asking for are
    >> carefully explained in the NTPv4 spec.

    >
    > Thanks. 1305 is just the start I want.
    > Where is the NTPv4 spec located?


    http://www.ietf.org/internet-drafts/...4-proto-09.txt

    Danny

+ Reply to Thread