[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

Re: [Qemu-devel] Timing problems

[Sven Zenker]

Hi all,
as a new qemu user, let me first of all say that qemu, especially in
combination with kqemu is a great piece of software. Many thanks to the
developer(s).
Since I am using a Laptop with a Pentium M CPU with SpeedStep and am
forced to use XP SP2 as a guest OS (Suse 9.3 is host OS), it wouldn't
work reliably for me,  for reasons mentioned previously in this thread
(system services timing out at startup, networking problems etc.).
Really needing a working emulator bad, I came up with the following ugly
hack, which leads to a stable and network enabled XP SP 2 running in
qemu on my SpeedStep machine, with the side effect of having an accurate
real time clock in the guest OS again. It simply replaces the virtual
timer mechanism based on CPU tick count (which is totally messed up in a
SpeedStep setting) with calls to the realtime clock. It should work even
when emulation is stopped intermittently, I hope, since the  built in
"virtual clock stop" mechanism ist left unchanged. 
I modified only the I386 code, so to make this work on other machines,
more modifications would be necessary:
++++++++++++++++++++++++++++++++
qemu-0.7.1 # diff vl.c.org vl.c 
503d502
<
505d503
<
508,510c506
<     int64_t val;
<     asm volatile ("rdtsc" : "=A" (val));
<     return val;
---
>     return get_clock();
512d507
<
594,605c589
<     int64_t usec, ticks;
<
<     usec = get_clock();
<     ticks = cpu_get_real_ticks();
< #ifdef _WIN32
<     Sleep(50);
< #else
<     usleep(50 * 1000);
< #endif
<     usec = get_clock() - usec;
<     ticks = cpu_get_real_ticks() - ticks;
<     ticks_per_sec = (ticks * 1000000LL + (usec >> 1)) / usec;
---
>       ticks_per_sec = 1000000LL;  /* our real time clock resolution */

+++++++++++++++++++++++++++++++++

and 

+++++++++++++++++++++++++++++++++

qemu-0.7.1/linux-user # diff main.c.org main.c
113,115c113
<     int64_t val;
<     asm volatile ("rdtsc" : "=A" (val));
<     return val;
---
>     return get_clock();
 return get_clock();
---
>     return val;

++++++++++++++++++++++++++++++
This is of course an ugly hack and sure to affect performance, but at
least, it makes XP work for me.
Please let me know your thoughts.
Best regards,
Sven Zenker

-- 
Dr. med. Sven Zenker
Research Associate
Center for Inflammation and Regenerative Modeling
Dpt. of Critical Care Medicine
University of Pittsburgh Medical Center

Re: Re: [Qemu-devel] Timing problems

[Mulyadi Santosa]

Hello...

> It simply
> replaces the virtual timer mechanism based on CPU tick count (which
> is totally messed up in a SpeedStep setting) with calls to the
> realtime clock. It should work even when emulation is stopped
> intermittently, I hope, since the  built in "virtual clock stop"
> mechanism ist left unchanged.

Hm..... hard choice.....correctness traded for perfomance.... But 
anyway....IMHO this hack  is needed for every speed-step enabled 
machine. Perhaps...the other workaround is via cpufreqd? I don't have 
any Pentium M based PC/laptop around, so this is just a pure guess

BTW, your patch seems reversed....if you really mean you want to fetch 
realtime clock, you should use "rdtsc", right? But the patch seems 
replaced "rdtsc" with get_clock().... 

Another thing, IMHO it is better to use unified format (diff -u). More 
readable and i think it is a standart

regards

Mulyadi

Re: Re: [Qemu-devel] Timing problems

[Jim C. Brown]

On Mon, Aug 29, 2005 at 10:01:39AM +0700, Mulyadi Santosa wrote:
> Hello...
> 
> > It simply
> > replaces the virtual timer mechanism based on CPU tick count (which
> > is totally messed up in a SpeedStep setting) with calls to the
> > realtime clock. It should work even when emulation is stopped
> > intermittently, I hope, since the  built in "virtual clock stop"
> > mechanism ist left unchanged.
> 
> Hm..... hard choice.....correctness traded for perfomance.... But 
> anyway....IMHO this hack  is needed for every speed-step enabled 
> machine. Perhaps...the other workaround is via cpufreqd? I don't have 
> any Pentium M based PC/laptop around, so this is just a pure guess
> 

The other patch for this just used a constant to increment the time iirc
(based on some value in /proc).

> BTW, your patch seems reversed....if you really mean you want to fetch 
> realtime clock, you should use "rdtsc", right? But the patch seems 
> replaced "rdtsc" with get_clock().... 
> 

The values returned by rdtsc seem to vary depending on cpu frequency when
speedstep is enabled. get_clock() is actually more accurate (tho i think less
precise), at least from the user land POV.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: Re: [Qemu-devel] Timing problems

[Sven Zenker]

Hi,
> Hm..... hard choice.....correctness traded for perfomance.... But 
> anyway....IMHO this hack  is needed for every speed-step enabled 
> machine. Perhaps...the other workaround is via cpufreqd? I don't have 
> any Pentium M based PC/laptop around, so this is just a pure guess
Yeah, you can also expect problems with the original versions on
multi-processor machines, I would think. Would be nice to compare
performance of the patched and original version. Unfortunately can't do
that right now because timing of the non-patched version is of course
messed up on my machine.
> 
> BTW, your patch seems reversed....if you really mean you want to fetch 
> realtime clock, you should use "rdtsc", right? But the patch seems 
> replaced "rdtsc" with get_clock().... 
rdtsc gives you the cpu's clock count, which, if CPU frequency changes,
or your code is run on different processors (multiprocessor machine),
cannot be assumed to be related to real time anymore. Resolutionwise,
the real time clock may be inferior, of course, as Jim mentioned.
Jim: could you point me to this other patch? Thanks!
> 
> Another thing, IMHO it is better to use unified format (diff -u). More 
> readable and i think it is a standart
Here you go:
+++++++++++++++++++++++++++++++++++
qemu-0.7.1 # diff -u vl.c.org vl.c
--- vl.c.org    2005-08-26 19:03:52.000000000 -0400
+++ vl.c        2005-08-28 14:43:00.000000000 -0400
@@ -500,16 +500,11 @@
     } while (h != h1);
     return ((int64_t)h << 32) | l;
 }
-
 #elif defined(__i386__)
-
 int64_t cpu_get_real_ticks(void)
 {
-    int64_t val;
-    asm volatile ("rdtsc" : "=A" (val));
-    return val;
+    return get_clock();
 }
-
 #elif defined(__x86_64__)

 int64_t cpu_get_real_ticks(void)
@@ -591,18 +586,7 @@

 void cpu_calibrate_ticks(void)
 {
-    int64_t usec, ticks;
-
-    usec = get_clock();
-    ticks = cpu_get_real_ticks();
-#ifdef _WIN32
-    Sleep(50);
-#else
-    usleep(50 * 1000);
-#endif
-    usec = get_clock() - usec;
-    ticks = cpu_get_real_ticks() - ticks;
-    ticks_per_sec = (ticks * 1000000LL + (usec >> 1)) / usec;
+       ticks_per_sec = 1000000LL;  /* our real time clock resolution */
 }

 /* compute with 96 bit intermediate result: (a*b)/c */

+++++++++++++++++++++++++++++++++++

qemu-0.7.1/linux-user # diff -u main.c.org main.c
--- main.c.org  2005-08-28 14:40:16.000000000 -0400
+++ main.c      2005-08-28 15:06:31.000000000 -0400
@@ -110,9 +110,7 @@

 int64_t cpu_get_real_ticks(void)
 {
-    int64_t val;
-    asm volatile ("rdtsc" : "=A" (val));
-    return val;
+    return get_clock();
 }

 #elif defined(__x86_64__)

+++++++++++++++++++++++++++++++++++

Best regards,
Sven

Re: Re: [Qemu-devel] Timing problems

[Mulyadi Santosa]

Hello Sven...

> rdtsc gives you the cpu's clock count, which, if CPU frequency
> changes, or your code is run on different processors (multiprocessor
> machine), cannot be assumed to be related to real time anymore.
> Resolutionwise, the real time clock may be inferior, of course, as
> Jim mentioned. Jim: could you point me to this other patch? Thanks!

Oh, so sorry, I was mistakenly made conclusion about your patch. yes, 
you are correct, get_clock() will do the trick....while rdtsc won't 
work because the clock will run vary during speed-stepping....

The unified format of diff looks great! :)

regards

Mulyadi