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

In article <3BE48DD0EC7D3948BC183931D9150C210438794D@ii0015exch001u.iprc.lucent.com>,
[email]suhasp@lucent.com[/email] (P B, Suhas Suhas) wrote:
[color=blue]
> 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[/color]

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.
[color=blue]
> below 32 msec offsets, hence max of 64 consecutive slew corrections and
> above 32 msec offset will result in step correction) .[/color]

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.)
[color=blue]
> 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.[/color]

What do you mean by "times to adjust the system clock".
[color=blue]
> What is the probability of ntp source based UTC time straying beyond 32 msec
> offsets due to network congestion, jitter - high / medium /low ? NTP[/color]

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.