Clock drift on FreeBSD 6.2 (Parallels 3150)

C

Caleb

Bit poster
I'm using Parallels 3150 and I'm having trouble keeping my FreeBSD 6.2 guest's clock correct. I'm running ntpd like I would on any of my FreeBSD systems running on hardware, but it doesn't seem to have an affect. I can run ntpdate to set the clock one time, but the drift is really bad. Thirty minutes after setting the clock with ntpdate the clock will be about 10 minutes slow.

My Windows VMs all have the correct time (I assume because I have the parallels tools installed).

Does anybody have a solution/workaround for this problem (even reverting to a previous parallels version)?
 
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...

ntpd is designed to correct the clock gradually, to avoid a sudden jump that might upset running software (or make Neo see the same cat twice) and can not keep up with a clock that is drifting badly.
 
I've seen something like this w/ FBSD under VMWare, as well. The clock just starts with the last value it had when the host machine was suspended.

Windows VMs seem to be right - I suspect it's because there's more effort and focus on the Windows tools than the FBSD versions. Clock updates are easy to let slip.

I have to reset the FBSD clock every startup.

rickb
 
Thanks itsdapead! I've seen the clock=pit Linux fix before, but didn't know how to translate that to FreeBSD. But the bit about changing the interrupt rate seems to help.

To adjust the interrupt rate in freebsd, put this in your /boot/loader.conf:

kern.hz=100

and reboot.

I've been running with this configuration for 10 minutes and the clock is perfect with my OS X system (before it would have been very off).
 
rickbsgu said:
I've seen something like this w/ FBSD under VMWare, as well. The clock just starts with the last value it had when the host machine was suspended.

Windows VMs seem to be right - I suspect it's because there's more effort and focus on the Windows tools than the FBSD versions. Clock updates are easy to let slip.

I have to reset the FBSD clock every startup.

rickb
Click to expand...
That's actually a separate issue. There are two issues here:

1. the clock drifts
2. the clock doesn't update to the current time when you unsuspend

To fix the clock drift problem (on Linux) use the aforementioned kernel option. As for the not updating problem, like you I haven't found a better solution than resetting the clock every time I unsuspend (or wake up my MacBook from sleep).

However, I have added a shortcut to my GNOME top edge panel that I can click on to reset the clock. It runs the following command (in Linux):

gksu ntpdate <an ntp server>
 
You must log in or register to reply here.
Back
Top