Nero Imhard <n...@pipe.nl> writes: >Unruh schreef:
>>> We might even agree. It could be appropriate for ntp to include a >>> configurable frequency offset that can be used on OSs that lack such a >>> feature. That's much more reasonable than to stretch the frequency error >>> limit used in the disciplining algorithm. >> >>> So if anything in ntp needs to be changed for this, I'd rather see en >>> extra tuning knob. >> >> Again, a human should not be needed to turn that knob. It should be >> automated. ntp knows ( or can be programmed to know) if such an >> adjustment is needed, and can supply it. >Except that ntpd just wasn't designed to do this. It requires the >frequency error to be within certain bounds. I know that this is one of >your criticisms towards the reference implementation, but it doesn't >seem likely that this design choice is going to be revisited anytime >soon. So please stop lamenting this fact ad nauseam; you have made your >opinion very clear countless times already. >So I was suggesting a knob for calibrating those clocks that haven't >been and can't be calibrated otherwise, as a better alternative for >arbitrarily cranking up the frequency error limit. You misunderstand. I was not (necessarily) asing for increased limits on the slew. Your proposal requires a rewrite of ntpd which allows that extra knob to be inserted into the ntp.conf file, to be read by the program, and then implimented by the program. My suggestion is that that knob be automated by ntp itself. After all your knowledge of how much of a correction to the rate is needed in adjusting that knob comes from the evidence supplied by ntp itself. What I am saying is that that evidence should be collected by ntp itself and ntp itself should twiddle that knob, not stick in the extra step of having a human try to evaluate the output of ntp, determine how much that knob should be set, and then setting it. Remember the tickadjust is very crude. It jumps in amounts of 100PPM ntp should be able to, extremely rapidly, determine which of the 100PPM bins to set the tickadjust to and then leave it. It should not require human intervention. This would then leave the full 500PPM for adjusting offsets and responding to rate changes caused by thermal effects for example. As it is now, that 500PPM can be largely eaten up by compensating for the constant large drift rate of the clock. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
