[ntp:questions] Increase maximum frequency offset to deal with really bad clock

David Woolley david at ex.djwhome.demon.co.uk.invalid
Tue Mar 10 07:40:25 UTC 2009

Frank Wayne wrote:
> While several people suggested that Jeff use guest/host synchronization, no one ever answered the first question, "is it possible to override the maximum offset PPM?"
> -----Original Message-----
> From: questions-bounces+fwayne=frankwayne.com at lists.ntp.org [mailto:questions-bounces+fwayne=frankwayne.com at lists.ntp.org] On Behalf Of jeff at sailorfej.net
> Sent: Wednesday, 28 January 2009 14:46
> To: questions at lists.ntp.org
> Subject: Increase maximum frequency offset to deal with really bad clock
> Hi folks,
> I have a some FreeBSD systems running as guests in Microsoft Virtual
> Server.  There is a known problem with these were the clocks run very
> fast.  I am trying to use ntpd to keep their clocks in sync, but the
> frequency error offset is exceeding (I think) ntpd's maximum of 500,
> my driftfile always contains a value of "-500.000".  If understand the
> way this works correctly, if I could get the frequency error offset to
> represent the real error rate which I believe to be much higher that
> 500 PPM, then ntpd would be able to keep the clocks in sync, as it is
> now, it slowly falls behind until it fails to correct altogether.
> So is it possible to override the maximum offset PPM in the driftfile,
> or is there a better way to fix this?

You can re-centre the frequency error in 100ppm steps, using tickadj. 
However, for VMWare, at least, the effective frequency varies wildly 
over relatively short durations, as it attempts to maintain a correct 
long term tick rate.  These are likely to confuse ntpd, whatever the 
frequency correction limits are set to.

Before recompiling with a higher limit, one should also check the kernel 
limits; this limit may still apply if one doesn't use the kernel PLL. 
In ntpd V3, the 500ppm limit was actually set by the kernel, not by 
ntpd, and was less on some systems.  It also used scaled integer 
arithmetic, which might have suffered overflows if some limits were 
changed - I'm not sure if ntpd V4 is completely immune from that.

More information about the questions mailing list