[Qemu-devel] Timing problems

[Qemu-devel] Timing problems

[Alexander Toresson]

I'm running windows 2000 in qemu 0.7.0 with kqemu 0.6.2-1 on i386
debian linux. First thing I tried to do was to run a benchmark program
(qemu w/o kqemu vs qemu w/ kqemu). I got strange results, and I also
noted that timing didn't seem to be that good, so I re-tried to run
the benchmark program, but with the date & clock settings window in
the background. This is the result: The more cpu that is used in the
virtual cpu, the faster time flies by. For example, when it's nearly
idle, time is too slow. If it goes from idle to 100% cpu-use, time
flies by at 5x the speed it should. This is true both when I use kqemu
and when I don't. This cpu is capable of speedstep, but I have
disabled it while doing this test. I think I would get even more weird
results if I enabled it.
This makes it impossible to run a benchmark and get any useful results
out of it. Also, trying to run a game on qemu would be a disaster.
However, running normal programs aren't any problem. Except that I
have to be very quick when changing resolution in w2k (it should wait
15s, now time flies away and those 15 becomes 2s :)).

Before compiling qemu 0.7.0 with kqemu 0.6.2-1, I ran qemu
0.6.something, taken from the debian testing repository, and it had
the same problem.

Regards, Alexander Toresson

PS. I'm susprised nobody has seen this problem before. Is it just me
who experience it?

Re: [Qemu-devel] Timing problems

[Oliver Gerlich]

Alexander Toresson wrote:
> I'm running windows 2000 in qemu 0.7.0 with kqemu 0.6.2-1 on i386
> debian linux. First thing I tried to do was to run a benchmark program
> (qemu w/o kqemu vs qemu w/ kqemu). I got strange results, and I also
> noted that timing didn't seem to be that good, so I re-tried to run
> the benchmark program, but with the date & clock settings window in
> the background. This is the result: The more cpu that is used in the
> virtual cpu, the faster time flies by. For example, when it's nearly
> idle, time is too slow. If it goes from idle to 100% cpu-use, time
> flies by at 5x the speed it should. This is true both when I use kqemu
> and when I don't. This cpu is capable of speedstep, but I have
> disabled it while doing this test. I think I would get even more weird
> results if I enabled it.
> This makes it impossible to run a benchmark and get any useful results
> out of it. Also, trying to run a game on qemu would be a disaster.

Not necessarily, Age of Empires 2 runs quite well under Qemu + Win98SE 
(on an Athlon 2600+, host: Debian Linux, kernel 2.6.9).

> However, running normal programs aren't any problem. Except that I
> have to be very quick when changing resolution in w2k (it should wait
> 15s, now time flies away and those 15 becomes 2s :)).
> 
> Before compiling qemu 0.7.0 with kqemu 0.6.2-1, I ran qemu
> 0.6.something, taken from the debian testing repository, and it had
> the same problem.
> 
> Regards, Alexander Toresson
> 
> PS. I'm susprised nobody has seen this problem before. Is it just me
> who experience it?

Although I use Visual Studio 5 and Age of Empires 2 inside Qemu (with 
Win98SE and Win2k), I never noticed such problems, and the Windows clock 
always seemed quite right (and VC++ stresses the CPU quite a lot!). But 
admittedly I never ran benchmarks or had a closer look at the guest 
system time.

Regards,
Oliver Gerlich

> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 

Re: [Qemu-devel] Timing problems

[malc]

On Wed, 29 Jun 2005, Alexander Toresson wrote:

> I'm running windows 2000 in qemu 0.7.0 with kqemu 0.6.2-1 on i386
> debian linux. First thing I tried to do was to run a benchmark program
> (qemu w/o kqemu vs qemu w/ kqemu). I got strange results, and I also
> noted that timing didn't seem to be that good, so I re-tried to run
> the benchmark program, but with the date & clock settings window in
> the background. This is the result: The more cpu that is used in the
> virtual cpu, the faster time flies by. For example, when it's nearly
> idle, time is too slow. If it goes from idle to 100% cpu-use, time
> flies by at 5x the speed it should. This is true both when I use kqemu
> and when I don't. This cpu is capable of speedstep, but I have
> disabled it while doing this test. I think I would get even more weird
> results if I enabled it.
> This makes it impossible to run a benchmark and get any useful results
> out of it. Also, trying to run a game on qemu would be a disaster.
> However, running normal programs aren't any problem. Except that I
> have to be very quick when changing resolution in w2k (it should wait
> 15s, now time flies away and those 15 becomes 2s :)).
>
> Before compiling qemu 0.7.0 with kqemu 0.6.2-1, I ran qemu
> 0.6.something, taken from the debian testing repository, and it had
> the same problem.
>
> Regards, Alexander Toresson
>
> PS. I'm susprised nobody has seen this problem before. Is it just me
> who experience it?
>

CPU frequency scaling might be the cause. If your OS uses speedstep
or similar tech QEMU timers will misbehave.

-- 
mailto:malc@pulsesoft.com

Re: [Qemu-devel] Timing problems

[Alexander Toresson]

Oliver Gerlich wrote:
> Alexander Toresson wrote:
> > I'm running windows 2000 in qemu 0.7.0 with kqemu 0.6.2-1 on i386
> > debian linux. First thing I tried to do was to run a benchmark program
> > (qemu w/o kqemu vs qemu w/ kqemu). I got strange results, and I also
> > noted that timing didn't seem to be that good, so I re-tried to run
> > the benchmark program, but with the date & clock settings window in
> > the background. This is the result: The more cpu that is used in the
> > virtual cpu, the faster time flies by. For example, when it's nearly
> > idle, time is too slow. If it goes from idle to 100% cpu-use, time
> > flies by at 5x the speed it should. This is true both when I use kqemu
> > and when I don't. This cpu is capable of speedstep, but I have
> > disabled it while doing this test. I think I would get even more weird
> > results if I enabled it.
> > This makes it impossible to run a benchmark and get any useful results
> > out of it. Also, trying to run a game on qemu would be a disaster.
> 
> Not necessarily, Age of Empires 2 runs quite well under Qemu + Win98SE
> (on an Athlon 2600+, host: Debian Linux, kernel 2.6.9).
>
> > However, running normal programs aren't any problem. Except that I
> > have to be very quick when changing resolution in w2k (it should wait
> > 15s, now time flies away and those 15 becomes 2s :)).
> >
> > Before compiling qemu 0.7.0 with kqemu 0.6.2-1, I ran qemu
> > 0.6.something, taken from the debian testing repository, and it had
> > the same problem.
> >
> > Regards, Alexander Toresson
> >
> > PS. I'm susprised nobody has seen this problem before. Is it just me
> > who experience it?
> 
> Although I use Visual Studio 5 and Age of Empires 2 inside Qemu (with
> Win98SE and Win2k), I never noticed such problems, and the Windows clock
> always seemed quite right (and VC++ stresses the CPU quite a lot!). But
> admittedly I never ran benchmarks or had a closer look at the guest
> system time.
> 

Well, it happens any time I stress the cpu. Having the clock settings
window open and then double-clicking on My Documents is enough to see
the clock accelerate and then go back to normal speed.

malc wrote:
>CPU frequency scaling might be the cause. If your OS uses speedstep
>or similar tech QEMU timers will misbehave.

This was tested when speedstep was disabled, which I did by shutting
down powernowd. Then cat /proc/cpuinfo shows 1.86ghz constantly, which
is the maximum cpu frequency.

Regards, Alexander Toresson

[Qemu-devel] Re: Timing problems

[Michael Smith]

Alexander Toresson <alexander.toresson <at> gmail.com> writes:

> time flies by at 5x the speed it should.

> PS. I'm susprised nobody has seen this problem before. Is it just me
> who experience it?

No, I experience this as well.

I'm running Qemu 0.7.2 with Linux 2.6.14 (vanilla kernel) as host OS and Windows
XP Professional as guest OS.  If the VM is running and actively using CPU, time
runs much faster in the guest than in the host.  On the other hand, if the VM is
mostly idle, time is slower in the guest than in the host OS.

This odd clock behavior seems to cause other problems in the guest OS,
particularly during boot/service initialization.

I can recreate this behavior with or without KQemu.

I can recreate this behavior with or without CPU frequency scaling enabled.

It is frustrating, and I would be very happy if someone could suggest a fix or
workaround.

Thanks,
Mike Smith
mas3f@alumni.virginia.edu

Re: [Qemu-devel] Re: Timing problems

[Sven Zenker]

Hi,
people have had this problem with SpeedStep machines, where it is
related to qemu timing being based on CPU cycle count, which is thereby
messed up. 
Since it seems to occur with frequency scaling disabled as well, could
this be related to running on a HyperThreading CPU? Not sure what
happens there with the cycle counts, but to verify, you could try to
apply my previously posted patch that substituted the built-in mechanism
with realtime clock calls (was for 0.7.1, though, I think).
Best,
Sven

Am Montag, den 07.11.2005, 22:46 +0000 schrieb Michael Smith:
> Alexander Toresson <alexander.toresson <at> gmail.com> writes:
> 
> > time flies by at 5x the speed it should.
> 
> > PS. I'm susprised nobody has seen this problem before. Is it just me
> > who experience it?
> 
> No, I experience this as well.
> 
> I'm running Qemu 0.7.2 with Linux 2.6.14 (vanilla kernel) as host OS and Windows
> XP Professional as guest OS.  If the VM is running and actively using CPU, time
> runs much faster in the guest than in the host.  On the other hand, if the VM is
> mostly idle, time is slower in the guest than in the host OS.
> 
> This odd clock behavior seems to cause other problems in the guest OS,
> particularly during boot/service initialization.
> 
> I can recreate this behavior with or without KQemu.
> 
> I can recreate this behavior with or without CPU frequency scaling enabled.
> 
> It is frustrating, and I would be very happy if someone could suggest a fix or
> workaround.
> 
> Thanks,
> Mike Smith
> mas3f@alumni.virginia.edu
> 
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

[Qemu-devel] Re: timing problems

[space-wizard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 532 bytes --]

Hi!

I checked my QEMU and I found the same Problems. I'm running SLES9 (x86) on
an SLES9 (ppc) host. The target clock runs faster(? I've got positive
offsets running ntpdate ?) than the host clock. I've tried severel kernel
parameters (eg. clock=pit or clock=pmtmr) without any success. 

The timing problems seem to be not only a problem with Windows XP as guest
os.

Best regards

christoph

-- 
Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat,
DSL-Flatrate für nur 4,99 Euro/Monat*  http://www.gmx.net/de/go/dsl

Re: [Qemu-devel] Re: timing problems

[Mike Swanson]

>From what I know, you'll just have to put up with it for now. Also, I
believe that ntpdate showing positive offsets means that the clock is
running slower. Run the date command before the ntpdate one to check
what the guest clock is at before the NTP update.

On 11/9/05, space-wizard@gmx.de <space-wizard@gmx.de> wrote:
> Hi!
>
> I checked my QEMU and I found the same Problems. I'm running SLES9 (x86) on
> an SLES9 (ppc) host. The target clock runs faster(? I've got positive
> offsets running ntpdate ?) than the host clock. I've tried severel kernel
> parameters (eg. clock=pit or clock=pmtmr) without any success.
>
> The timing problems seem to be not only a problem with Windows XP as guest
> os.
>
> Best regards
>
> christoph
>
> --
> Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat,
> DSL-Flatrate für nur 4,99 Euro/Monat*  http://www.gmx.net/de/go/dsl
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>


--
Mike