Time Drift on OS X Server Guest

[Wylertay]

I am running OS X Server 10.6.8 Guest on Mac OS 10.6.8 and 10.7.3 for testing purposes.

The Guest OS clock is frequently off—especially if you frequently save the machine state. Now I know if I was running a Linux variant I could install the Guest Additions and adjust the time sync parameters. Are there any workarounds for this on OS X server as a Guest? NTP is enabled. You can manually have it check with a NTP server and update the time, but this is impractical to do on a regular basis.

Thanks!

[Wylertay]

I resolved the issue by writing a script that issues the command 'sudo ntpdate-u time.apple.com' about every 20 or so seconds. That takes care of it for us.

[james.watkins]

Hi,

I also noticed the time drift on my Snow Leopard Server guest (running on a Lion host). After investigation, I have identified two distinct issues, and both should affect EVERY "Mac guest on Mac host" setup:

1. There is a constant ~5% slow down of the guest real time clock relative to the host clock (which can't be fixed by NTP daemon, because it exceed the 500 per million maximum slew rate).
2. If the guest machine execution is paused, then guest time will be completely off on restore.

From a technical perspective, the first issue relates to the fact that the XNU kernel (the kernel of Mac OS) evaluates real time by dividing the TSC register by a determined TSC frequency. That frequency is computed from the FSB Frequency, which is obtained from an EFI property node. Now, VirtualBox estimate the FSB Frequency by taking the CPU speed (in MHz), converting it to Hz (by multiplying it twice by 1024) and then diving by 4 (now, don't ask about this constant, its just fine). But here's the problem: hertz are not power of two, so going from giga-hertz to hertz is done by multiplying twice by 1000, not 1024. So we get (1024*1024) / (1000*1000) = 104,8576 %, which should explains the ~5% time drift. I should also note that this error also affect the CPU speed reported in "About this Mac" (in my setup, I get 2.52 GHz instead 2.4GHz).

Now, for some unexplained reason, on my host, the TSC frequency (which can be read in terminal by the command 'sysctl machdep.tsc.frequency') is 2394138834, instead of the 2400000000 that I would expect using the reported FSB frequency, so I'm afraid there could be a remaining 0,2448 % drift, which would still exceed NTP's maximum slew rate. I will know better once I can successfully test the proposed fix (I currently have issues with my home built VirtualBox executable).

The second issue is also due to the TSC counter: if the host machine is put asleep or shut down, then the TSC register will similarly, be paused or reset; now the host kernel is informed of this event through the power management subsystem, and will therefore adjust its internal counters to account the for the number of milliseconds that lapsed while the machine was asleep. Unfortunately, the guest system has no way of knowing about being put asleep, and will therefore continue to read the TSC register, whose value is now completely off, just as if nothing had happen. I believe the best strategy to fix that issue would be a kernel module on the guest side that wait for "VM awaked from frozen state" events, and invoke the XNU's specific real time adjustment method. I have drafted some code for this purpose, but until I succeed in building a functional VirtualBox executable, I won't be able to complete nor test this code.

Now, for my build problem, well I have VirtualBox VM.app that crash immediately after the box has been started (I don't even have time to see the VirtualBox logo in the console window). I only get a generic error code, so that won't help. Now, its getting late so I'll bring back more details tomorrow. Till then, though, I'd be interested on some pointers on known compilation issues (building on Lion, gcc 4.2.1, port 2.1.1...).


James

[rpmurray]

I've been experimenting with the TSCTicksPerSecond property to see if I can get the ticks per second to a place where NTP sees the offset as low enough that it will start adjusting the time on it's own.

In my case I have a 3.2 GHz Mac Pro. Multiplying 3200000000 by 1.05 gives me 3360000000 which I then use to change the ticks per second using Terminal like so:

VBoxManage setextradata "<VMName>" "VBoxInternal/TM/TSCTicksPerSecond" 3360000000

where <VMName> is the name of your OS X guest. This gets me in the ballpark. Then I start up the guest and in the guest I use Terminal to issue several "ntpq -p" over time and watch the offset. Shut down the guest and adjust the TSCTicksPerSecond up or down a bit (starting with increments of +/- 1000000) and repeat until the offset is as low as I can get it. This takes a few hours. NTP takes over and starts to adjust the clock so there's no more drift. Once you have it set right you never need to fiddle with it again.

This does not fix the second issue but as long as you don't pause the guest the clock should no longer drift.