Logo Search packages:      
Sourcecode: virtualbox-ose version File versions  Download package

The Time Sync Service

The time sync service plays along with the Time Manager (TM) in the VMM to keep the guest time accurate using the host machine as reference. TM will try its best to make sure all timer ticks gets delivered so that there isn't normally any need to adjust the guest time.

There are three normal (= acceptable) cases:

  1. When the service starts up. This is because ticks and such might be lost during VM and OS startup. (Need to figure out exactly why!)
  2. When the TM is unable to deliver all the ticks and swallows a backlog of ticks. The threshold for this is configurable with a default of 60 seconds.
  3. The time is adjusted on the host. This can be caused manually by the user or by some time sync daemon (NTP, LAN server, etc.).

There are a number of very odd case where adjusting is needed. Here are some of them:

  1. Timer device emulation inaccurancies (like rounding).
  2. Inaccurancies in time source VirtualBox uses.
  3. The Guest and/or Host OS doesn't perform proper time keeping. This come about as a result of OS and/or hardware issues.

The TM is our source for the host time and will make adjustments for current timer delivery lag. The simplistic approach taken by TM is to adjust the host time by the current guest timer delivery lag, meaning that if the guest is behind 1 second with PIT/RTC/++ ticks this should be reflected in the guest wall time as well.

Now, there is any amount of trouble we can cause by changing the time. Most applications probably uses the wall time when they need to measure things. A walltime that is being juggled about every so often, even if just a little bit, could occationally upset these measurements by for instance yielding negative results.

This bottom line here is that the time sync service isn't really supposed to do anything and will try avoid having to do anything when possible.

The implementation uses the latency it takes to query host time as the absolute maximum precision to avoid messing up under timer tick catchup and/or heavy host/guest load. (Rational is that a *lot* of stuff may happen on our way back from ring-3 and TM/VMMDev since we're taking the route thru the inner EM loop with it's force action processing.)

But this latency has to be measured from our perspective, which means it could just as easily come out as 0. (OS/2 and Windows guest only updates the current time when the timer ticks for instance.) The good thing is that this isn't really a problem since we won't ever do anything unless the drift is noticable.

It now boils down to these three (configuration) factors:

  1. g_TimesyncMinAdjust - The minimum drift we will ever bother with.
  2. g_TimesyncLatencyFactor - The factor we multiply the latency by to calculate the dynamic minimum adjust factor.
  3. g_TimesyncMaxLatency - When to start discarding the data as utterly useless and take a rest (someone is too busy to give us good data).
  4. g_TimeSyncSetThreshold - The threshold at which we will just set the time instead of trying to adjust it (milliseconds).

Generated by  Doxygen 1.6.0   Back to index