Mischanko, Edward T wrote:
Is there a way to configure ntpd so that when the offset exceeds 1 millisecond polling will automatically be set to 64 seconds or less?
Although you can't do this, if you do have a situation where the time measurements never have an error more than x, but there is a fault, that can't be rectified, which occasionally causes the local clock to permanently jump by much more than x, you can tinker step to be a little more than x. Although it will take some time for ntpd to verify the fault, it will then remove all the offset.
ALthough tinkering stepout will reduce the time to verify the fault, there are warnings against this in the documentation.
I find that most people want to increase step, rather than reduce it.
If I understand correctly, polling currently is adjusted by the speed of change in offset. It takes forever for a large offset to be skewed at
That's not my understanding. I would expect it to be based on something like offset > n*jitter, but I'm not sure of the details.
On a quick look at the code, that is what it does. If the offset is more than 4 times the jitter for a number of samples that depends on the current poll rate, it will reduce the poll interval one notch. (It uses an IIR filter for the jitter, whereas an FIR one might be slightly better for dealing with local clock jumps.)
large polling time cycles when the drift is so small that it doesn't trigger a polling adjustment. Maybe additional code is needed to configure this function?
You really should be investigating why you are getting the large offsets, including how much of the offset is attributable to the time measurements, and how much to problems with the local clock.
_______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
