[ntp:questions] Flash 400 on all peers; can't get ntpd to be happy

unruh unruh at wormhole.physics.ubc.ca
Tue Mar 8 17:00:44 UTC 2011


On 2011-03-08, Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
> On 3/8/2011 4:16 AM, Miroslav Lichvar wrote:
>> On Sun, Mar 06, 2011 at 11:22:34AM +0000, David Woolley wrote:
>>> Ralph wrote:
>>>
>>>> filtoffset= 67671.8 66534.8 65931.3 65118.0 63317.3 63029.5 62216.4 58156.6,
>>>
>>> Your frequency error is way outside any reasonable bounds, which is
>>> reflecting in a very high jitter, which is probably the ultimate
>>> cause of rejection.
>>>
>>> This system is not savable by NTP.
>>
>> This seems to be a common problem and with virtual machines getting
>> everywhere it will probably only get worse. I'm wondering how hard it
>> would be for ntpd to detect that the clock frequency is outside the
>> acceptable range and write a "your clock is broken" message to syslog?
>>
>
> NTP should be able to detect the problem without to much trouble.
>
> Fixing the problem will most likely prove to be more difficult.
>
> The political issues are likely to be most difficult of all.  I wouldn't 
> want to be the one to persuade Dave Mills to permit the necessary 
> modifications to the code.

Not at all sure how Mills comes into the picture. On a system where the
frequency fluctuates wildly, ntpd is not the right answer, nor is any
system. I suspect that the best you could do would be to run something
like ntpdate often and jump the clock around. At least it would probably
always jump in a positive direction, since the clock is most liable to
loose, not gain. And these frequency jumps ( which ntpd handles
particularly badly) are not gaussian at all. 





More information about the questions mailing list