NTP client - choice of 'step threshold value' forntp daemon - NTP

This is a discussion on NTP client - choice of 'step threshold value' forntp daemon - NTP ; Hi, We are trying to chose the 'step threshold value' for ntp daemon(ntp client) as 32 msec instead of the default value of 128 msec and do not plan to use -x option. This will help in minimising the number ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: NTP client - choice of 'step threshold value' forntp daemon

  1. NTP client - choice of 'step threshold value' forntp daemon

    Hi,

    We are trying to chose the 'step threshold value' for ntp daemon(ntp client)
    as 32 msec instead of the default value of 128 msec and do not plan to use
    -x option. This will help in minimising the number of times we adjust the
    system clock (as Not using -x option will result in using slew corrections
    below 32 msec offsets, hence max of 64 consecutive slew corrections and
    above 32 msec offset will result in step correction) .

    If anyone knows pluses / negatives of chosing the 'step threshold value' to
    be 32 msec as mentioned above (given the need to minimise the number of
    times to adjust system clock) - please let us know.

    What is the probability of ntp source based UTC time straying beyond 32 msec
    offsets due to network congestion, jitter - high / medium /low ? NTP
    documentations available seem to suggest - ntp source based UTC time
    straying beyond 128 msec is very rare.

    Any clarifications on this is deeply appreciated.

    Thanks,
    Ravi
    Suhas.P.B
    Lucent Technologies
    ST-1, Hosur Road, Bangalore - 560095.
    Tel: +91-80-51191355
    Mobile: +91-9886081128

    Lucent Technologies, Bell Labs Innovations






    <http://promos.hotbar.com/promos/prom...&RAND=53408&pa
    rtner=hbtools> Upgrade Your Email - Click here!

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. NTP client - choice of 'step threshold value' forntp daemon

    In article <3BE48DD0EC7D3948BC183931D9150C210438794D@ii0015exc h001u.iprc.lucent.com>,
    suhasp@lucent.com (P B, Suhas Suhas) wrote:

    > We are trying to chose the 'step threshold value' for ntp daemon(ntp client)
    > as 32 msec instead of the default value of 128 msec and do not plan to use
    > -x option. This will help in minimising the number of times we adjust the
    > system clock (as Not using -x option will result in using slew corrections


    I don't understand what you are trying to say. Doing this will increase
    the number of drastic adjustments (steps) and will probably increase
    the number of frequency tweaks, because the clock will be less stable,
    because of the disruption caused by the steps.

    > below 32 msec offsets, hence max of 64 consecutive slew corrections and
    > above 32 msec offset will result in step correction) .


    On good operating systems, slew corrections are being made all the time,
    or at least every clock tick and every time the time is read between ticks.

    On a system that is keeping good time there should be an infinite number of
    consecutive slew corrections, hunting around the ideal.

    For version 3 they were made at 4 second intervals, so assuming no
    static frequency error and a 500ppm slew, it would take 64s to clear
    the offset at the maximum rate, which would take 16 adjustment cycles.
    However, the response to an actual sudden change in offset will take
    considerably longer as the slew has to first accelerate and will start
    to decelerate as the offset is cleared.

    What model do you have of the adjustment process and what are you trying
    to achieve?

    (Note that, when you disable steps, there is a slew mode that tries to
    get back within the stepout limit, which is run at the maximum rate, if
    I remember correctly.)

    > If anyone knows pluses / negatives of chosing the 'step threshold value' to
    > be 32 msec as mentioned above (given the need to minimise the number of
    > times to adjust system clock) - please let us know.


    What do you mean by "times to adjust the system clock".

    > What is the probability of ntp source based UTC time straying beyond 32 msec
    > offsets due to network congestion, jitter - high / medium /low ? NTP


    Depends on the network. Unless you have a very high bandwidth connection
    to your reference clocks or you have extremely stable traffic patterns
    (so that differential delays are stable), it is almost certain that you
    will break 128ms sometimes, and 32ms quite often. Home users and small
    to medium businesses, using internet based servers are particularly
    likely to do this. Lunch time is a good time to break the limit in
    business systems. There is actually a tinker option to cope with this
    situation, it was getting so common.


+ Reply to Thread