Setting the maximum rate of change - NTP

This is a discussion on Setting the maximum rate of change - NTP ; Hello everyone, Is there a run-time parameter in NTP that defines the maximum rate at which the clock can be adjusted (slewed?). Is there a run-time parameter in NTP that defines the maximum rate at which the previous parameter can ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Setting the maximum rate of change

  1. Setting the maximum rate of change

    Hello everyone,

    Is there a run-time parameter in NTP that defines the maximum rate at
    which the clock can be adjusted (slewed?).

    Is there a run-time parameter in NTP that defines the maximum rate at
    which the previous parameter can change?

    Here's why I ask:

    I'm working with a standard that deals with 27 MHz clocks, and that
    standard states that the frequency must not change faster than 75 mHz
    per second.

    I'll try and think aloud, in case someone can see through my confusion.

    Consider H : a 26,999,900 Hz clock.

    Thus H has an offset of 100 Hz = 3.7 ppm

    In other words, H "misses" 100 ticks every second.

    I'd have to add 100 / 27e6 = 3.7 Ás every second to keep H from drifting
    away from the correct time.

    But I can't make that change all of a sudden, I can only change 0.075 Hz
    more (2.78 ns) every second.

    The 1st second, I'd add 2.78 ns.
    The 2nd second, I'd add 5.56 ns.
    The Nth second, I'd add 2.78*N ns.

    Until I reach 3.7 Ás for N = 1333

    Then I'd have to correct the amount H drifted while the adjustment
    slowly crept to the correct value.

    NB: my OS is Linux 2.6

    http://www.ntp.org/ntpfaq/NTP-s-algo...OCK-DISCIPLINE
    http://www.die.net/doc/linux/man/man8/adjtimex.8.html

    # ntpq -p
    remote refid st t when poll reach delay offset jitter
    ================================================== ======================
    *10.11.12.66 LOCAL(1) 13 u 24 32 377 0.123 0.004 0.003

    # adjtimex -p
    mode: 0
    offset: 3
    frequency: 4483200
    maxerror: 66258
    esterror: 1
    status: 1
    time_constant: 5
    precision: 1
    tolerance: 33554432
    tick: 10000
    raw time: 1174319208s 988507us = 1174319208.988507

    Apparently, the value of HZ has an influence on these values?

    Would I improve precision if I changed HZ from 100 to 250?

    Regards.

  2. Re: Setting the maximum rate of change

    >>> In article <45FEB162.40008@localhost.com>, Spoon writes:

    Spoon> Hello everyone, Is there a run-time parameter in NTP that defines the
    Spoon> maximum rate at which the clock can be adjusted (slewed?).

    There is probably a "tinker" variable to do this. Be amazingly careful when
    messing with these.

    But I don't think you will need to - see below.

    Spoon> Here's why I ask:

    Spoon> I'm working with a standard that deals with 27 MHz clocks, and that
    Spoon> standard states that the frequency must not change faster than 75 mHz
    Spoon> per second.

    If ntpd has the correct drift adjustment, you should be in good shape.

    Under what exact conditions must the "don't change faster than 75mHz/sec"be
    met?

    Spoon> I'll try and think aloud, in case someone can see through my
    Spoon> confusion.

    Spoon> Consider H : a 26,999,900 Hz clock.

    Spoon> Thus H has an offset of 100 Hz = 3.7 ppm

    Spoon> In other words, H "misses" 100 ticks every second.

    If left uncorrected, yes.

    Spoon> I'd have to add 100 / 27e6 = 3.7 Ás every second to keep H from
    Spoon> drifting away from the correct time.

    Once ntpd has achieved "state 4", ntpd will calculate the drift and will
    automatically handle this.

    Spoon> But I can't make that change all of a sudden, I can only change 0.075
    Spoon> Hz more (2.78 ns) every second.

    ntpd will apply the correction on a per-tick basis, not all at once, oncea
    second.

    Are you comfortable that the specs of the machines you are using will keep
    time well enough that their clocks can be kept in-sync by limiting
    adjustment to 75mHz/sec?

    Spoon> Would I improve precision if I changed HZ from 100 to 250?

    Exactly what do you mean by "precision"?

    Have you seen http://ntp.isc.org/Support/NTPRelatedDefinitions ?

    And have you read about the problems you can cause by having HZ at a value
    other than 100? Particularly with Linux kernels?

    H

  3. Re: Setting the maximum rate of change

    Harlan Stenn wrote:

    > Spoon wrote:
    >
    >> Is there a run-time parameter in NTP that defines the
    >> maximum rate at which the clock can be adjusted (slewed?).

    >
    > There is probably a "tinker" variable to do this. Be amazingly careful
    > when messing with these.


    The documented tinker options are:
    http://www.eecis.udel.edu/~mills/ntp/html/miscopt.html
    allan | dispersion | freq | huffpuff | panic | step | stepout
    I don't think any of these are appropriate.

    > But I don't think you will need to - see below.


    OK.

    >> Here's why I ask:
    >>
    >> I'm working with a standard that deals with 27 MHz clocks, and that
    >> standard states that the frequency must not change faster than 75 mHz
    >> per second.

    >
    > If ntpd has the correct drift adjustment, you should be in good shape.


    drift or skew?

    > Under what exact conditions must the "don't change faster than 75mHz/sec"
    > be met?


    Consider two systems A and B. At initialization, B's clock is set to A's
    clock (offset = 0 initially). After 30-60 seconds, it is acceptable to
    make a large correction to compensate for the average skew. From then
    on, B's skew correction parameter should not be changed faster than 75
    mHz per second.

    >> I'll try and think aloud, in case someone can see through my
    >> confusion.
    >>
    >> Consider H : a 26,999,900 Hz clock.
    >>
    >> Thus H has an offset of 100 Hz = 3.7 ppm


    I am talking about a frequency offset, i.e. what NTP calls skew AFAIU.

    >> In other words, H "misses" 100 ticks every second.

    >
    > If left uncorrected, yes.


    So far, so good.

    >> I'd have to add 100 / 27e6 = 3.7 Ás every second to keep H from
    >> drifting away from the correct time.

    >
    > Once ntpd has achieved "state 4", ntpd will calculate the drift and will
    > automatically handle this.


    According to the definition's page you've mentionned, drift is the
    variation in skew, I think you meant ntpd will calculate the skew?

    >> But I can't make that change all of a sudden, I can only change 0.075
    >> Hz more (2.78 ns) every second.

    >
    > ntpd will apply the correction on a per-tick basis, not all at once, once a
    > second.


    I know. I did not mean 2.78 ns added every second, I meant a rate of
    2.78 ns per second, i.e. 2.78 ppb.

    > Are you comfortable that the specs of the machines you are using will keep
    > time well enough that their clocks can be kept in-sync by limiting
    > adjustment to 75mHz/sec?


    I'm still testing this. Basically, the two machines will remain at
    constant temperature. I'm hoping that clock drift on either machine will
    be very small, i.e. skew between the two clocks should remain almost
    constant. Thus, once ntpd has computed the correct skew, everything
    should be OK.

    >> Would I improve precision if I changed HZ from 100 to 250?

    >
    > Exactly what do you mean by "precision"?


    Good question. I'll have to think about it ;-)

    > Have you seen http://ntp.isc.org/Support/NTPRelatedDefinitions ?


    Thanks.

    > And have you read about the problems you can cause by having HZ at a value
    > other than 100? Particularly with Linux kernels?


    No. Where is that?

    Regards.

  4. Re: Setting the maximum rate of change

    >>> In article <45ffa089$0$9851$426a74cc@news.free.fr>, Spoon writes:

    Spoon> Here's why I ask: I'm working with a standard that deals with 27 MHz
    Spoon> clocks, and that standard states that the frequency must not change
    Spoon> faster than 75 mHz per second.

    Harlan> If ntpd has the correct drift adjustment, you should be in good
    Harlan> shape.

    Spoon> drift or skew?

    The value in the driftfile.

    If you run 'ntpq -c rv' it will be the 'frequency=...' value.

    Harlan> Under what exact conditions must the "don't change faster than
    Harlan> 75mHz/sec" be met?

    Spoon> Consider two systems A and B. At initialization, B's clock is set to
    Spoon> A's clock (offset = 0 initially). After 30-60 seconds, it is

    You mean for the first 30-60 seconds, right?

    Spoon> acceptable to make a large correction to compensate for the average
    Spoon> skew. From then on, B's skew correction parameter should not be
    Spoon> changed faster than 75 mHz per second.

    OK.

    Spoon> I'll try and think aloud, in case someone can see through my
    Spoon> confusion. Consider H : a 26,999,900 Hz clock. Thus H has an offset
    Spoon> of 100 Hz = 3.7 ppm

    Spoon> I am talking about a frequency offset, i.e. what NTP calls skew
    Spoon> AFAIU.

    OK, I think we're on the same page now.

    Spoon> In other words, H "misses" 100 ticks every second.

    Harlan> If left uncorrected, yes.

    Spoon> So far, so good.

    Spoon> I'd have to add 100 / 27e6 = 3.7 Ás every second to keep H from
    Spoon> drifting away from the correct time.

    Harlan> Once ntpd has achieved "state 4", ntpd will calculate the drift and
    Harlan> will automatically handle this.

    Spoon> According to the definition's page you've mentionned, drift is the
    Spoon> variation in skew, I think you meant ntpd will calculate the skew?

    I'll have to reread the definitions page again. OK, it's directly neither
    skew nor drift. It's the frequency adjustment needed to keep the clock
    accurate, and it accomodates the actual frequency of the clock crystal and
    the value of HZ.

    Yes, ntpd will calculate it and adjust for it.

    Harlan> Are you comfortable that the specs of the machines you are using
    Harlan> will keep time well enough that their clocks can be kept in-sync by
    Harlan> limiting adjustment to 75mHz/sec?

    Spoon> I'm still testing this. Basically, the two machines will remain at
    Spoon> constant temperature. I'm hoping that clock drift on either machine
    Spoon> will be very small, i.e. skew between the two clocks should remain
    Spoon> almost constant. Thus, once ntpd has computed the correct skew,
    Spoon> everything should be OK.

    Harlan> And have you read about the problems you can cause by having HZ at a
    Harlan> value other than 100? Particularly with Linux kernels?

    Spoon> No. Where is that?

    I just looked and I thought I saw somebody post something about this here,
    although it might have been on hackers@. I just looked, and I could not
    find it.

    It was a discussion about how one had to be careful to make sure that theHZ
    value was "properly" divisible, and also not so fast that interrupts were
    lost.

    Have you just tried this yet?

    H

  5. Re: Setting the maximum rate of change

    Harlan Stenn wrote:

    > Spoon wrote:
    >
    >> Harlan Stenn wrote:
    >>
    >>> And have you read about the problems you can cause by having HZ at a
    >>> value other than 100? Particularly with Linux kernels?

    >>
    >> No. Where is that?

    >
    > I just looked and I thought I saw somebody post something about this here,
    > although it might have been on hackers@. I just looked, and I could not
    > find it.
    >
    > It was a discussion about how one had to be careful to make sure that the HZ
    > value was "properly" divisible, and also not so fast that interrupts were
    > lost.


    Are you referring to this discussion?
    http://lists.ntp.isc.org/pipermail/q...ead.html#11766

    > Have you just tried this yet?


    I didn't have time to yet :-(

    I had randomly thought it might be a good idea to crank HZ up to 250.

    Are you saying ntpd will break if I set HZ to 250 in Linux 2.6?

    Regards.

  6. Re: Setting the maximum rate of change

    Den Fri, 23 Mar 2007 16:07:32 +0100. skrev Spoon:


    >
    > I had randomly thought it might be a good idea to crank HZ up to 250.
    >
    > Are you saying ntpd will break if I set HZ to 250 in Linux 2.6?
    >
    > Regards.


    The (PPS?) kernel discipline only works with 100 HZ. That is a kernel
    issue. I am using 250 HZ on my ntp client PC and it works fine. If the
    clock lags behind and ntpd cannot correct that then there is a problem and
    it could be lost interrupts. With high HZ-values like 1000 lost interrupts
    are more likely.

    Regards Rune

  7. Re: Setting the maximum rate of change

    Spoon wrote:
    > Harlan Stenn wrote:
    >
    >> Spoon wrote:
    >>
    >>> Harlan Stenn wrote:
    >>>
    >>>> And have you read about the problems you can cause by having HZ at a
    >>>> value other than 100? Particularly with Linux kernels?
    >>>



    > Are you saying ntpd will break if I set HZ to 250 in Linux 2.6?
    >
    > Regards.


    It MAY not break. It certainly will NOT work any better!


  8. Re: Setting the maximum rate of change

    Rune Magnussen wrote:

    > Spoon wrote:
    >
    >> I had randomly thought it might be a good idea to crank HZ up to 250.
    >> Are you saying ntpd will break if I set HZ to 250 in Linux 2.6?

    >
    > The (PPS?) kernel discipline only works with 100 HZ. That is a kernel
    > issue. I am using 250 HZ on my ntp client PC and it works fine. If the
    > clock lags behind and ntpd cannot correct that then there is a problem and
    > it could be lost interrupts. With high HZ-values like 1000 lost interrupts
    > are more likely.


    I am confused.

    kernel/time/ntp.c defines int do_adjtimex(struct timex *txc)
    which contains the following comment:

    /* PPS is not implemented, so these are zero */

    http://lxr.linux.no/source/kernel/time/ntp.c#L193

    On a related note, there seems to be an effort to make the NTP
    kernel code independent of HZ.

    http://lkml.org/lkml/2006/12/12/236

    Regards.

+ Reply to Thread