In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
