Virtual PC and real time clock lag

Hi all.

I noticed something that is rather peculiar about Virtual PC, Windows
XP Pro, and how applications running under Windows affect the real
time clock within the virtual machine. I don't know why this happens,
but it's something interesting I thought I'd like to share.

On my installation, I am running Virtual PC 7.0.1 on Mac OS X 10.3.9,
and have a 160-320 MB virtual machine running on it quite comfortably
(I vary the size of the virtual machine depending on what I want to
do with it).

Now, I don't normally do this, but I started Windows Messenger by
accident once, and noticed that it causes the virtual machine to lose
its notion of how long one second is! How did I notice this? I run
SFU (Microsoft Services for UNIX) 3.5 on my Windows XP Pro
installation, and I was running top(1) as a diagnostic tool for
monitoring process memory usage for a project I am working on, and
noticed that the refresh rate of the command:

% top -d 1

dropped from 1.0 second to 2.5-3.0 seconds!

When I quit Messenger outright, top(1)'s output rate restored! So
something in Windows Messenger (network activity?!) caused Virtual
PC to lose its real time clock accuracy.

To see how this could affect applications and Windows XP itself
running under Virtual PC, I tried starting Firefox and Internet
Explorer to see if this did anything.

Nope! Nothing. The real-time clock still ticks once per second.

OK, how about QuickTime? I tried this because a while ago whilst
playing around with iTunes for Windows, I found that QuickTime
Player could not play back video in sync with the audio. When I
fast-forwarded the video, however, Virtual PC was able to keep up
with the video fast-forward, showing a very impressive 25-30 frames
per second (you may notice that Virtual PC provides a 50-60 frames
per second refresh rate on its display: this info is available in
the Statistics tab of the Get Info window). So, if the
fast-forward proved that Virtual PC had ample power to play back
QuickTime media under QuickTime for Windows, then why
the lag between its video output and audio playback?!

I discovered the answer: QuickTime is sensitive to the real-time
clock in your virtual machine. If the real-time clock slows down,
as is the case with having Messenger running, then QuickTime
would lose the only time reference it has in keeping video in
sync with audio playback, causing QuickTime to fail in playing
back the movie properly.

But the QuickTime failure does not need Messenger's help --
apparently, the QuickTime Player application itself also causes
the virtual machine's notion of real time to be skewed,
contributing to the malfunction. But, having both the QuickTime
Player open and Messenger open at the same time does not double
the effect... I find this observation interesting!

So, QuickTime is an intriguing case... the software that relies
on the accurate measurement of time is itself a contributor to
its own failure! However, QuickTime is not the best of examples
here, because of its particularly high use of CPU resources.
All the while, the fast-forward test told me that the virtual
machine was more than capable of decoding and playing back
(including displaying) the video data within the time constraints
of the player, so CPU demand was not the contributing factor to
poor playback of QuickTime content under Windows.

So I started to think about the performance problems that could
actually be happening in Virtual PC that we users are not aware
of... particularly applications that rely on the use of the
real-time clock. It's not just QuickTime I'm thinking
of, too... many processes in Windows are governed by the
real-time clock. For example, if Messenger is open,
Minesweeper slows down, and gives a visual indication as to
the effects of process scheduling: it counts up one second
about every 3 seconds!

To verify that Minesweeper wasn't the problem, I tried this
in Windows under the tcsh command prompt under SFU:

% while 1
> printf "%s %s %s %s %s %s\r" `date`
> end

This produces the date and time on the command line; the command
repeats endlessly in a tight loop (^C terminates the loop) and
shows how often the real-time clock gets updated. With
Messenger running, the virtual machine's notion of the time of
day updates once per 3 seconds, and after about 30 seconds,
Windows gets an update from the Mac's real-time clock and shows
that accordingly. Without Messenger running, the virtual
machine's real-time clock does update once per second!

The slow-down in this case is nowhere near the result of CPU
congestion in either the Macintosh itself or the virtual
machine--both environments are reporting low CPU usage;
definitely < 40% CPU usage on both Macintosh and Windows...
but Windows CPU usage reporting may also have been affected
by the lack of accuracy of the virtual machine's real-time
clock. However, it is evident here that the drop in performance
is contributed by the skew in the real-time clock, not by
sheer demands in executing code by the emulator.

This artifact in emulation is something to be aware of when
running Windows software under Virtual PC, and as you can start
to see already, is a very complicated, but very relevant matter.

But I would like to ask... if people could keep Mindsweeper
open and have its seconds counter running, or even some other more
reputable means of measuring time withing the virtual machine,
and then document the list of applications that we find that
cause the virtual machine to lose its notion of real time... we
can then see if we can find the cause of this failure in the
virtual machine and then let Microsoft know about what I think
is a genuine bug in the Virtual PC emulation engine.

If anyone has any ideas as to what is going on here, and how to
resolve it, would be appreciated as well!

And lastly, can anyone try this in Virtual PC 2004 to see if
this peculiar behaviour occurs on a real PC, too?

Comments are welcome at my address (with "@t"->'@', and "d.t"->'.')
if you would like to discuss this further with me!

Thanks all!


--
-- tonza


.

Relevant Pages

  • Re: Clock drift problems
    ... I know almost nothing about Linux, ... the real-time clock has gotten 7 hours slow. ... and setting up ntpd to autostart - probably ... >claim it's nothing to do with Linux, that it would happen with Windows ...
    (comp.os.linux.misc)
  • Re: after ids
    ... Absolute time, as far as Tcl is concerned, is UTC with smoothing ... to recover by advancing or retarding clock frequency), ... Its reference on Unix-like systems is gettimeofday; on Windows ...
    (comp.lang.tcl)
  • Re: DST, will Fedora change the time on the fly?
    ... any combination of settings in Windows to make it not "fix" the system ... clock (even when I tried to run Windows in timezone GMT, ... That is set on the timezone configuration page of the clock settings. ... months for a new DST change, and it has screwed up every time :-). ...
    (Fedora)
  • RE: Sync Clocks on VOIP
    ... clock of your VOIP. ... 816042 How to configure the Windows Time service on a Windows Server ... you may still need to contact the VOIP ...
    (microsoft.public.windows.server.sbs)
  • Re: Trying to install QuickTime v716 gives error: "The older version of QuickTime cannot be removed.
    ... I am trying to install QuickTime v716 under Windows XP SP2. ... I still get the following pop up error message every time that I attempt to install QuickTime v716: "The older version of QuickTime cannot be removed. ... The following more detailed error message is copied and pasted from the Windows XP Application Event Viewer: ...
    (microsoft.public.windowsxp.general)