Re: [tlug] Serious clock wrongness

["Michael(tm) Smith" <smith@example.com>]

Arwyn Hainsworth <arwynh@example.com>, 2007-04-03 19:31 +0900:

> Your ntpd is actually being very disciplined and doing exactly what it is
> supposed to do. Ntpd does adjust for 'natural drift', but natural drift is
> usually only a few ms per day or so. If it detects a large difference it
> will refuse to update the clock, assuming some kind of error has occurred.
> It would be right. A drift of a few seconds per minute is very large and
> means something somewhere is not working as it is supposed to. I suspect
> parallels is to blame, since it is the one providing the 'hardware' clock,
> but there are a number of other things it could be so I'm not certain. If
> you can't find out what is causing it, it might be possible to configure
> ntpd to adjust the time even if the drift is larger than expected. If your
> drift is constant, then that'll solve the problem.

I found something similar reported in the Parallels support forum:

  http://forum.parallels.com/archive/index.php/t-8821.html

To quote:

  the drift is really bad. Thirty minutes after setting the clock
  with ntpdate the clock will be about 10 minutes slow.

And suggested workaround:

  This is a common problem with VMs - not just Parallels but the
  Other People too...

  The solution in Linux is to change the way the clock is
  calulated using the "clock=pit" kernel parameter, or to
  re-compile the kernel with the interrupt rate reduced from 1000
  to 100 Hz. I know you are asking about FreeBSD, not linux, but
  this might provide some clues...

But checking my kernel logs, I see lots of the following being
logged at startup:

  TSC appears to be running slowly.
  Time: pit clocksource has been installed.

So I assume that means the system is already automatically
switching to clock=pit, but that's still not fixing the problem.

I resetting the interrupt rate worth trying? And even if it is,
isn't that likely to have some side effects?

  --Mike