Re: [Qemu-devel] objective benchmark?

Re: [Qemu-devel] objective benchmark?

[Ben Taylor]

---- Kazu <kazoo@r3.dion.ne.jp> wrote: 
> Tuesday, May 16, 2006 3:55 PM Christian MICHON wrote:
> 
> >how can we do the same if the host is winXP ?
> 
> >Today, on linux guests, 2.4.x kernel boot faster than 2.6.x kernel
> >inside qemu (unless using "clock=pit" on 2.6.x). 2 days ago,
> >when I tried to setup Solaris x86 10 guest inside winXP host, I
> >gave up since the timing engine inside the guest seems slow.
> 
> >I would really like to know how to solve this on XP hosts.
> 
> RTC is not used on Win host.
> SpeedStep/PowerNow! is disabled by changing miminal power management to
> other items at Control Panel->Power Option->Power Management Setting.
> 
> I don't think it is necessary to set it if your PC is ACPI. Set it if the
> clock of win2k guest is faster than the real time while IE is running.
> 
> It is normal that 2.4 kernel boots faster than 2.6 kernel, isn't it? I don't
> know why Solaris x86 10 doesn't work.

add ",atapi-cd-dma-enabled=0" to the boot line when installing.  The QEMU 
IDE controller doesn't implement DMA (or dma correctly).   If you don't give
a Solaris VM enough memory, the installer (java) will coredump, and it 
appears that it's running out of memory.   

Once you've got Solaris 10 X86 installed, you'll need to get the Disk Update
from http://tools.de/solaris/itu/DU.zip.  Normally you could do an Install Time Update to
add this driver disk, but Qemu doesn't implement a floppy in ACPI (I'm testing
patches now to see if that fixes the problem), and some folks are working on
OpenSolaris to fix the enumeration of the floppy on the emulated ISA bus
(or when -no-acpi is called).

So the trick to getting the NIC driver into Solaris 10x86 is to call QEMU with
the DU.img as hdd.  Then once Solaris is booted, you do the following:

mount -F pcfs /dev/dsk/c1d1p0:c /mnt
cd /mnt/DU/210/i86pc/Product
cp ni.Z /var/tmp
uncompress ni.Z
cpio -idvm < ni
pkgadd  -d . CSWni

At this point, it's probably easier just to do a sys-unconfig so that Solaris 10/x86 with
redo it's networking for DHCP.   (tun/tap support is not in qemu for Solaris yet)

HTH,

Ben

[Qemu-devel] objective benchmark?

[Mikhail Ramendik]

Hello,

As I have reported before, it seems that on my host linux system kqemu does 
not work with guest win98se.

Is there any benchmark that I could run in the guest, with and without kqemu, 
to check if this is so objectively? (Ideally I'd like two benchmarks - 16-bit 
and 32-bit code).

-- 
Yours, Mikhail Ramendik

Re: [Qemu-devel] objective benchmark?

[Natalia Portillo]

Try SiSoftware Sandra

I don't think it will test 16-bit code but whatever.
For 16-bit code you can try the Norton Utilities System Information,  
not so complete benchmarking but, 16-bit.

Natalia

El 15/05/2006, a las 20:03, Mikhail Ramendik escribió:

> Hello,
>
> As I have reported before, it seems that on my host linux system  
> kqemu does
> not work with guest win98se.
>
> Is there any benchmark that I could run in the guest, with and  
> without kqemu,
> to check if this is so objectively? (Ideally I'd like two  
> benchmarks - 16-bit
> and 32-bit code).
>
> -- 
> Yours, Mikhail Ramendik
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] objective benchmark?

[Mikhail Ramendik]

Natalia Portillo wrote:

> Try SiSoftware Sandra
>
> I don't think it will test 16-bit code but whatever.
> For 16-bit code you can try the Norton Utilities System Information,
> not so complete benchmarking but, 16-bit.

Thanks! Are there, by chance, any *free* 16-bit benchmarks? 

(Sandra has a downloadable version so it's all OK).

-- 
Yours, Mikhail Ramendik

Re: [Qemu-devel] objective benchmark?

[NyOS]

On Mon, 15 May 2006 20:03:00 +0200, Mikhail Ramendik <mr@ramendik.ru>  
wrote:

> Hello,
>
> As I have reported before, it seems that on my host linux system kqemu  
> does
> not work with guest win98se.
>
> Is there any benchmark that I could run in the guest, with and without  
> kqemu,
> to check if this is so objectively? (Ideally I'd like two benchmarks -  
> 16-bit
> and 32-bit code).
>

Hi!

An ANSI-C benchmark program:
http://www.hit.bme.hu/anonftp/pongor/benchmar/bm-ansi.c

It should be compiled by full optimization.

and some results:
http://www.hit.bme.hu/anonftp/pongor/benchmar/bm-times.all

I'm not sure whether is it really objective. Tests only the processor's  
speed (not I/O).
It was written, and maintained by one of my teachers, Gyorgy Pongor, until  
he died 2 or 3 years ago. By that time, he collected many result files  
(even PDP-11 and VAX machines!), that is the second link above.

You can try a 16 bit compiler also (e.g. ancient Borland compiler).

Miklos Gyozo
p.s.

my results:
on host:
===== Results of bench marks V.6.4,  Pongor, György =====

Type of machine : Intel(R) Pentium(R) 4 CPU 3.00GHz, 3006.943, 1024 KB

Type of compiler : gcc version 3.3.6 (Debian 1:3.3.6-7), gcc -O3 bm-ansi.c  
-o nyosO3 -lm

Name of this result file : nyosO3.bm

  Length of integer = 32 bits
  Length of double mantissa = 64 bits
  Length of address = 32 bits

  Precision of time estimation = 1%
  Clock resolution = 1000000.000 clocks/sec
  ==> Minimal execution time of one test:     2 sec

  Test 1:  Direct select. sort 1000 real numbers   ----- Time=    0.00193  
sec
  Test 2:  Discrete Fourier Transform of 128 reals ----- Time=    0.00258  
sec
  Test 3:  Find first 1000 primes                  ----- Time=    0.00742  
sec
  Test 4:  Sieve of Eratosthenes with 2000 numbers ----- Time=   2.01e-05  
sec
  Test 5:  FFT of 1024 complex numbers             ----- Time=   7.32e-05  
sec
  Test 6:  Invert a matrix of 50 * 50 reals        ----- Time=   0.000789  
sec
  Test 7:  Calculate Binom(18,7)                   ----- Time=   0.000518  
sec

  Average performance :  3207.6  "MicroVAX II MIPS"



----- Summary of results -----
  Machine : Intel(R) Pentium(R) 4 CPU 3.00GHz, 3006.943, 1024 KB
  Compiler : gcc version 3.3.6 (Debian 1:3.3.6-7), gcc -O3 bm-ansi.c -o  
nyosO3 -lm
|fpp? |   32     64    32 ? |    1.929e-03    2.578e-03    7.422e-03     
2.012e-05    7.324e-05    7.886e-04    5.176e-04  |   3207.615  |

the same binary on qemu (0.7.2):

===== Results of bench marks V.6.4,  Pongor, György =====

Type of machine :  Pentium II (Klamath) QEMU, 3009.347, 128 KB

Type of compiler : gcc the same

Name of this result file : nyosO3qemu.bm

  Length of integer = 32 bits
  Length of double mantissa = 64 bits
  Length of address = 32 bits

  Precision of time estimation = 1%
  Clock resolution = 1000000.000 clocks/sec
  ==> Minimal execution time of one test:     2 sec

  Test 1:  Direct select. sort 1000 real numbers   ----- Time=    0.00219  
sec
  Test 2:  Discrete Fourier Transform of 128 reals ----- Time=    0.00289  
sec
  Test 3:  Find first 1000 primes                  ----- Time=     0.0084  
sec
  Test 4:  Sieve of Eratosthenes with 2000 numbers ----- Time=   4.14e-05  
sec
  Test 5:  FFT of 1024 complex numbers             ----- Time=   0.000103  
sec
  Test 6:  Invert a matrix of 50 * 50 reals        ----- Time=   0.000947  
sec
  Test 7:  Calculate Binom(18,7)                   ----- Time=   0.000594  
sec

  Average performance :  2541.7  "MicroVAX II MIPS"



----- Summary of results -----
  Machine :  Pentium II (Klamath) QEMU, 3009.347, 128 KB
  Compiler : gcc ugyanugy
|fpp? |   32     64    32 ? |    2.188e-03    2.891e-03    8.398e-03     
4.141e-05    1.031e-04    9.473e-04    5.938e-04  |   2541.747  |

Re: [Qemu-devel] objective benchmark?

[Anthony Liguori]

Mikhail Ramendik wrote:
> Hello,
>
> As I have reported before, it seems that on my host linux system kqemu does 
> not work with guest win98se.
>
> Is there any benchmark that I could run in the guest, with and without kqemu, 
> to check if this is so objectively? (Ideally I'd like two benchmarks - 16-bit 
> and 32-bit code).
>   

The vast majority of guest benchmarking programs are going to give you 
invalid results.  The clock within QEMU (rdtsc and wall clock) are not 
very reliable and this is going to skew the results.

I suggest a benchmark that treats the guest as a server (something like 
specweb where the timing or thoroughput measurement is done on the host 
where time is reliable).

Regards,

Anthony Liguori

Re: [Qemu-devel] objective benchmark?

[Kazu]

Anthony Liguori wrote:

> Mikhail Ramendik wrote:
>> Hello,
>>
>> As I have reported before, it seems that on my host linux system kqemu
does
>> not work with guest win98se.
>>
>> Is there any benchmark that I could run in the guest, with and without
kqemu,
>> to check if this is so objectively? (Ideally I'd like two benchmarks -
16-bit
>> and 32-bit code).
>>
>
> The vast majority of guest benchmarking programs are going to give you
> invalid results.  The clock within QEMU (rdtsc and wall clock) are not
> very reliable and this is going to skew the results.
>

If you set /proc/sys/dev/rtc/max-user-freq to 1024 and disable cpuspeed
service that is related to SpeedStep/PowerNow! on a host OS, the clock in
guest OS works fine.

I checked it on i686/x86_64 Linux host.

Regards,
Kazu

Re: [Qemu-devel] objective benchmark?

[Christian MICHON]

how can we do the same if the host is winXP ?

Today, on linux guests, 2.4.x kernel boot faster than 2.6.x kernel
inside qemu (unless using "clock=pit" on 2.6.x). 2 days ago,
when I tried to setup Solaris x86 10 guest inside winXP host, I
gave up since the timing engine inside the guest seems slow.

I would really like to know how to solve this on XP hosts.
Thanks,


On 5/16/06, Kazu <kazoo@r3.dion.ne.jp> wrote:
> Anthony Liguori wrote:
>
> > Mikhail Ramendik wrote:
> >> Hello,
> >>
> >> As I have reported before, it seems that on my host linux system kqemu
> does
> >> not work with guest win98se.
> >>
> >> Is there any benchmark that I could run in the guest, with and without
> kqemu,
> >> to check if this is so objectively? (Ideally I'd like two benchmarks -
> 16-bit
> >> and 32-bit code).
> >>
> >
> > The vast majority of guest benchmarking programs are going to give you
> > invalid results.  The clock within QEMU (rdtsc and wall clock) are not
> > very reliable and this is going to skew the results.
> >
>
> If you set /proc/sys/dev/rtc/max-user-freq to 1024 and disable cpuspeed
> service that is related to SpeedStep/PowerNow! on a host OS, the clock in
> guest OS works fine.
>
> I checked it on i686/x86_64 Linux host.
>
> Regards,
> Kazu
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>


-- 
Christian

Re: [Qemu-devel] objective benchmark?

[Kazu]

Tuesday, May 16, 2006 3:55 PM Christian MICHON wrote:

>how can we do the same if the host is winXP ?

>Today, on linux guests, 2.4.x kernel boot faster than 2.6.x kernel
>inside qemu (unless using "clock=pit" on 2.6.x). 2 days ago,
>when I tried to setup Solaris x86 10 guest inside winXP host, I
>gave up since the timing engine inside the guest seems slow.

>I would really like to know how to solve this on XP hosts.

RTC is not used on Win host.
SpeedStep/PowerNow! is disabled by changing miminal power management to
other items at Control Panel->Power Option->Power Management Setting.

I don't think it is necessary to set it if your PC is ACPI. Set it if the
clock of win2k guest is faster than the real time while IE is running.

It is normal that 2.4 kernel boots faster than 2.6 kernel, isn't it? I don't
know why Solaris x86 10 doesn't work.

Regards,
Kazu

Re: [Qemu-devel] objective benchmark?

[Christian MICHON]

On 5/16/06, Kazu <kazoo@r3.dion.ne.jp> wrote:
> It is normal that 2.4 kernel boots faster than 2.6 kernel, isn't it? I don't
> know why Solaris x86 10 doesn't work.

solaris works, it's just painfully slow.
lots of time is wasted in ide-probing inside 2.6.x, because of the
way time is measured in the qemu guest.

Maybe recompiling 2.6.x guest kernel, telling it which internal timer to
use would be better. Does anyone know how to do this or tried it already?

-- 
Christian

Re: [Qemu-devel] objective benchmark?

[Kazu]

Tuesday, May 16, 2006 7:23 PM Christian MICHON wrote:

>On 5/16/06, Kazu <kazoo@r3.dion.ne.jp> wrote:
>> It is normal that 2.4 kernel boots faster than 2.6 kernel, isn't it? I
don't
>> know why Solaris x86 10 doesn't work.

>solaris works, it's just painfully slow.
>lots of time is wasted in ide-probing inside 2.6.x, because of the
>way time is measured in the qemu guest.

>Maybe recompiling 2.6.x guest kernel, telling it which internal timer to
>use would be better. Does anyone know how to do this or tried it already?

Fedora Core 3 doesn't boot in 0.8.0 binary. But it boots almost the same
speed in 0.8.1 binary as on Linux host.

I measured FC3 booting time without kqemu.
On WinXP host:
0.8.0 binary     can't boot.
0.8.1 binary    4min 15sec

On Linux host:
0.8.0           4min 15sec
0.8.1           4min  5sec


I measured Knoppix v3.8 booting time.
On WinXP host: fb800x600 desktop=icewm
0.8.0          5min 54sec
0.8.1          3min 4sec

>From Knoppix booting, I think time for scanning hardware is improved as on
Linux host.
I think the problem is not related to measuring time.

Regards,
Kazu

Re: [Qemu-devel] objective benchmark?

[Lonnie Mendez]

[-- Attachment #1: Type: text/plain, Size: 2465 bytes --]

Kazu wrote:

>If you set /proc/sys/dev/rtc/max-user-freq to 1024 and disable cpuspeed
>service that is related to SpeedStep/PowerNow! on a host OS, the clock in
>guest OS works fine.
>
>I checked it on i686/x86_64 Linux host.
>
   Mind saying how you checked this?  I'm on a pentium-III mobile 
processor and the only way I've seen so far to make qemu + rdtsc behave 
100% is by disabling ACPI (boot with -noacpi).  If I add a simple printf 
to cpu_calibrate_ticks it doesn't seem fixed to me:

dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi 
-kernel-kqemu -soundhw es1370
ticks_per_sec set as 1126809000
dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi 
-kernel-kqemu -soundhw es1370
ticks_per_sec set as 17308857
dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi 
-kernel-kqemu -soundhw es1370
ticks_per_sec set as 103710852
dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi 
-kernel-kqemu -soundhw es1370
ticks_per_sec set as 15292604
dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi 
-kernel-kqemu -soundhw es1370
ticks_per_sec set as 96695295
dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi 
-kernel-kqemu -soundhw es1370
ticks_per_sec set as 1126761234
dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi 
-kernel-kqemu -soundhw es1370
ticks_per_sec set as 1126762522
dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi 
-kernel-kqemu -soundhw es1370
ticks_per_sec set as 49791263

   The first entry is with the patch attached called 
'ticks_from_proc.patch' applied (I've been using this for almost a 
year).  It sets the value ticks_per_sec, which happens to be used by a 
lot of qemu's hardware emulation, using information in /proc/cpuinfo.  
This doesn't fix the time issue as rdtsc is still used every time a 
SIGALRM signal occurs for timing, but at least the guest's emulated 
hardware runs to speed.

dignome@vaio /prog/qemu-cvs/qemu-acpi/qemu $ find . -type f -exec fgrep 
-l 'ticks_per_sec' {} \;
./audio/audio.c
./audio/noaudio.c
./audio/wavaudio.c
./monitor.c
./vl.c
./vl.h
./hw/acpi.c
./hw/adlib.c
./hw/arm_timer.c
./hw/cuda.c
./hw/fdc.c
./hw/i8254.c
./hw/i8259.c
./hw/ide.c
./hw/mc146818rtc.c
./hw/mips_r4k.c
./hw/ppc.c
./hw/sb16.c
./hw/sh7750.c
./hw/slavio_timer.c
./hw/usb-uhci.c

   The second patch adds the printf statement so you can see this for 
yourself.

[-- Attachment #2: tps-printf.patch --]
[-- Type: text/plain, Size: 338 bytes --]

--- a/vl.c	2006-05-16 06:42:11.000000000 -0500
+++ b/vl.c	2006-05-16 06:35:25.000000000 -0500
@@ -637,6 +637,7 @@
     usec = get_clock() - usec;
     ticks = cpu_get_real_ticks() - ticks;
     ticks_per_sec = (ticks * 1000000LL + (usec >> 1)) / usec;
+    printf("ticks_per_sec set as %lli\n", ticks_per_sec);
 }
 #endif /* !_WIN32 */
 

[-- Attachment #3: ticks_from_proc.patch --]
[-- Type: text/plain, Size: 999 bytes --]

Index: qemu/vl.c
@@ -596,8 +596,43 @@
 #endif
 }
 
+uint64_t get_tps_from_proc()
+{
+    FILE *fp;
+    char buf[30];
+    double cpu_mhz;
+
+    if (!(fp = fopen("/proc/cpuinfo", "r")))
+        return 0;
+
+    /* find wanted line */
+    while (fgets(buf, 30, fp) != NULL)
+        if (!strncmp(buf, "cpu MHz", 7))
+            break;
+
+    /* line not found? */
+    if (feof(fp)) {
+        fclose(fp);
+        return 0;
+    }
+    fclose(fp);
+
+    /* put 'cpu MHz' value into cpu_mhz */
+    if (!sscanf(&buf[9], ": %lf", &cpu_mhz))
+        return 0;
+
+    /* return estimated ticks/sec value */
+    return (uint64_t)(cpu_mhz * 1000000.0);
+}
+
 void cpu_calibrate_ticks(void)
 {
+    if (!(ticks_per_sec = get_tps_from_proc()))
+        fprintf(stderr, "Could not obtain ticks/sec. from /proc/cpuinfo\n \
+                        resorting to regular method (tsc)\n");
+    else /* value obtained, skip below */
+        return;
+
     int64_t usec, ticks;
 
     usec = get_clock();

Re: [Qemu-devel] objective benchmark?

[Kazu]

[-- Attachment #1: Type: text/plain, Size: 3799 bytes --]

Tuesday, May 16, 2006 8:48 PM Lonnie Mendez wrote:

> Kazu wrote:
>
>>If you set /proc/sys/dev/rtc/max-user-freq to 1024 and disable cpuspeed
>>service that is related to SpeedStep/PowerNow! on a host OS, the clock in
>>guest OS works fine.
>>
>>I checked it on i686/x86_64 Linux host.
>>
>   Mind saying how you checked this?  I'm on a pentium-III mobile
> processor and the only way I've seen so far to make qemu + rdtsc behave
> 100% is by disabling ACPI (boot with -noacpi).  If I add a simple printf
> to cpu_calibrate_ticks it doesn't seem fixed to me:
>
> dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
> -kernel-kqemu -soundhw es1370
> ticks_per_sec set as 1126809000
> dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
> -kernel-kqemu -soundhw es1370
> ticks_per_sec set as 17308857
> dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
> -kernel-kqemu -soundhw es1370
> ticks_per_sec set as 103710852
> dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
> -kernel-kqemu -soundhw es1370
> ticks_per_sec set as 15292604
> dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
> -kernel-kqemu -soundhw es1370
> ticks_per_sec set as 96695295
> dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
> -kernel-kqemu -soundhw es1370
> ticks_per_sec set as 1126761234
> dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
> -kernel-kqemu -soundhw es1370
> ticks_per_sec set as 1126762522
> dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
> -kernel-kqemu -soundhw es1370
> ticks_per_sec set as 49791263
>
>   The first entry is with the patch attached called
> 'ticks_from_proc.patch' applied (I've been using this for almost a
> year).  It sets the value ticks_per_sec, which happens to be used by a
> lot of qemu's hardware emulation, using information in /proc/cpuinfo.
> This doesn't fix the time issue as rdtsc is still used every time a
> SIGALRM signal occurs for timing, but at least the guest's emulated
> hardware runs to speed.
>
> dignome@vaio /prog/qemu-cvs/qemu-acpi/qemu $ find . -type f -exec fgrep
> -l 'ticks_per_sec' {} \;
> ./audio/audio.c
> ./audio/noaudio.c
> ./audio/wavaudio.c
> ./monitor.c
> ./vl.c
> ./vl.h
> ./hw/acpi.c
> ./hw/adlib.c
> ./hw/arm_timer.c
> ./hw/cuda.c
> ./hw/fdc.c
> ./hw/i8254.c
> ./hw/i8259.c
> ./hw/ide.c
> ./hw/mc146818rtc.c
> ./hw/mips_r4k.c
> ./hw/ppc.c
> ./hw/sb16.c
> ./hw/sh7750.c
> ./hw/slavio_timer.c
> ./hw/usb-uhci.c
>
>   The second patch adds the printf statement so you can see this for
> yourself.
>

Here is values of ticks_per_sec on Athlon 64 3000+ .
i686 host:
1790803394
1790784284
1790774719
1790798849
1790814225

x86_64 host:
1790764763
1790815837
1790816089
1790803590
1790771017

If I changed usleep(50 * 1000) to ulseep(500 * 1000) in vl.c, it improves.

When cpuspeed service is working in x86_64 host, it becomes:
994896127
994896984
994895713
994897215
994896447

It is because CPU is changed from 1.8GHz to 1GHz. TSC is changed dynamically
while QEMU is working.
I think your results are from mobile Pentium III.
I don't know much but a power management of mobile Pentium III works without
software?

I attached a patch that I modifed from your patch. It can be applied by
patch -p0. I checked it works for Athlon 64 with cpuspeed service (Power
Now!). ticks_per_sec changed dynamically but a clock of win2k guest on
x86_64 Linux host works fine.

If your guest OS is Linux, it is necessary to set clock=pit at guest OS'es
startup. TSC may change.

I hope it works for SpeedStep.

I can't test i686 Linux host because ACPI and cpuspeed doesn't work on my
PC.

I think it is better to detect CPU change signal and calibrate
ticks_per_sec.

Regards,
Kazu



[-- Attachment #2: qemu-20060517-tps_from_proc.patch --]
[-- Type: application/octet-stream, Size: 1537 bytes --]

Index: vl.c
===================================================================
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.185
diff -u -r1.185 vl.c
--- vl.c	3 May 2006 22:02:44 -0000	1.185
+++ vl.c	17 May 2006 04:19:00 -0000
@@ -627,8 +627,43 @@
     return tv.tv_sec * 1000000LL + tv.tv_usec;
 }
 
+uint64_t get_tps_from_proc()
+{
+    FILE *fp;
+    char buf[30];
+    double cpu_mhz;
+
+    if (!(fp = fopen("/proc/cpuinfo", "r")))
+        return 0;
+
+    /* find wanted line */
+    while (fgets(buf, 30, fp) != NULL)
+        if (!strncmp(buf, "cpu MHz", 7))
+            break;
+
+    /* line not found? */
+    if (feof(fp)) {
+        fclose(fp);
+        return 0;
+    }
+    fclose(fp);
+
+    /* put 'cpu MHz' value into cpu_mhz */
+    if (!sscanf(&buf[9], ": %lf", &cpu_mhz))
+        return 0;
+
+    /* return estimated ticks/sec value */
+    return (uint64_t)(cpu_mhz * 1000000.0);
+}
+
 void cpu_calibrate_ticks(void)
 {
+    if (!(ticks_per_sec = get_tps_from_proc()))
+        fprintf(stderr, "Could not obtain ticks/sec. from /proc/cpuinfo\n \
+                        resorting to regular method (tsc)\n");
+    else /* value obtained, skip below */
+	return;
+
     int64_t usec, ticks;
 
     usec = get_clock();
@@ -4499,6 +4534,8 @@
     tap_win32_poll();
 #endif
 
+    cpu_calibrate_ticks();
+
     if (vm_running) {
         qemu_run_timers(&active_timers[QEMU_TIMER_VIRTUAL], 
                         qemu_get_clock(vm_clock));

Re: [Qemu-devel] objective benchmark?

[Lonnie Mendez]

Kazu wrote:

>Here is values of ticks_per_sec on Athlon 64 3000+ .
>i686 host:
>1790803394
>1790784284
>1790774719
>1790798849
>1790814225
>
>x86_64 host:
>1790764763
>1790815837
>1790816089
>1790803590
>1790771017
>  
>
   Those are some very sane values.

>I attached a patch that I modifed from your patch. It can be applied by
>patch -p0. I checked it works for Athlon 64 with cpuspeed service (Power
>Now!). ticks_per_sec changed dynamically but a clock of win2k guest on
>x86_64 Linux host works fine.
>
>If your guest OS is Linux, it is necessary to set clock=pit at guest OS'es
>startup. TSC may change.
>
>I hope it works for SpeedStep.
>
>I can't test i686 Linux host because ACPI and cpuspeed doesn't work on my
>PC.
>
>I think it is better to detect CPU change signal and calibrate
>ticks_per_sec.
>
   That sounds like a good idea.  The kernel probably has some interface 
to monitor for this.  Here is some output from said attached patch:

ticks_per_sec set as 210734086
ticks_per_sec set as 204415638
ticks_per_sec set as 255738952
ticks_per_sec set as 105989831
ticks_per_sec set as 1113215464
ticks_per_sec set as 1126700925
ticks_per_sec set as 1126291452
ticks_per_sec set as 1127055498
ticks_per_sec set as 1127255910
ticks_per_sec set as 1127059553
ticks_per_sec set as 1126568251
ticks_per_sec set as 43726804
ticks_per_sec set as 254415811
ticks_per_sec set as 210672485
ticks_per_sec set as 203385010
ticks_per_sec set as 97492292
ticks_per_sec set as 404263903
ticks_per_sec set as 306991778

   iirc, this is an intel bug.  It is supposedly corrected for in newer 
processors but there are soo many affected ones out there already.  I 
can't imagine the amd processors also suffer such a poor design flaw 
like this and apparently report sane values for rdtsc with their 
frequency scaling technology.  Disabling ACPI support on the host seems 
to make everything work, but you lose power management and other 
features which is no good for a laptop.

"Pentium M, and particular models of P4 and Xeon, processors with 
SpeedStep enabled also exhibit this problem - the TSC register 
increments once per core clock cycle. If the clock rate is reduced the 
rate at which TSC increments will also be reduced.  Newer models of 
Pentium 4 and Xeon tick at a constant rate regardless of the current 
core clock rate."

Re: [Qemu-devel] objective benchmark?

[Fabrice Bellard]

Kazu wrote:
> Tuesday, May 16, 2006 8:48 PM Lonnie Mendez wrote:
> 
> 
>>Kazu wrote:
>>
>>
>>>If you set /proc/sys/dev/rtc/max-user-freq to 1024 and disable cpuspeed
>>>service that is related to SpeedStep/PowerNow! on a host OS, the clock in
>>>guest OS works fine.
>>>
>>>I checked it on i686/x86_64 Linux host.
>>>
>>
>>  Mind saying how you checked this?  I'm on a pentium-III mobile
>>processor and the only way I've seen so far to make qemu + rdtsc behave
>>100% is by disabling ACPI (boot with -noacpi).  If I add a simple printf
>>to cpu_calibrate_ticks it doesn't seem fixed to me:
>>
>>dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
>>-kernel-kqemu -soundhw es1370
>>ticks_per_sec set as 1126809000
>>dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
>>-kernel-kqemu -soundhw es1370
>>ticks_per_sec set as 17308857
>>dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
>>-kernel-kqemu -soundhw es1370
>>ticks_per_sec set as 103710852
>>dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
>>-kernel-kqemu -soundhw es1370
>>ticks_per_sec set as 15292604
>>dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
>>-kernel-kqemu -soundhw es1370
>>ticks_per_sec set as 96695295
>>dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
>>-kernel-kqemu -soundhw es1370
>>ticks_per_sec set as 1126761234
>>dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
>>-kernel-kqemu -soundhw es1370
>>ticks_per_sec set as 1126762522
>>dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi
>>-kernel-kqemu -soundhw es1370
>>ticks_per_sec set as 49791263
>>
>>  The first entry is with the patch attached called
>>'ticks_from_proc.patch' applied (I've been using this for almost a
>>year).  It sets the value ticks_per_sec, which happens to be used by a
>>lot of qemu's hardware emulation, using information in /proc/cpuinfo.
>>This doesn't fix the time issue as rdtsc is still used every time a
>>SIGALRM signal occurs for timing, but at least the guest's emulated
>>hardware runs to speed.
>>
>>dignome@vaio /prog/qemu-cvs/qemu-acpi/qemu $ find . -type f -exec fgrep
>>-l 'ticks_per_sec' {} \;
>>./audio/audio.c
>>./audio/noaudio.c
>>./audio/wavaudio.c
>>./monitor.c
>>./vl.c
>>./vl.h
>>./hw/acpi.c
>>./hw/adlib.c
>>./hw/arm_timer.c
>>./hw/cuda.c
>>./hw/fdc.c
>>./hw/i8254.c
>>./hw/i8259.c
>>./hw/ide.c
>>./hw/mc146818rtc.c
>>./hw/mips_r4k.c
>>./hw/ppc.c
>>./hw/sb16.c
>>./hw/sh7750.c
>>./hw/slavio_timer.c
>>./hw/usb-uhci.c
>>
>>  The second patch adds the printf statement so you can see this for
>>yourself.
>>
> 
> 
> Here is values of ticks_per_sec on Athlon 64 3000+ .
> i686 host:
> 1790803394
> 1790784284
> 1790774719
> 1790798849
> 1790814225
> 
> x86_64 host:
> 1790764763
> 1790815837
> 1790816089
> 1790803590
> 1790771017
> 
> If I changed usleep(50 * 1000) to ulseep(500 * 1000) in vl.c, it improves.
> 
> When cpuspeed service is working in x86_64 host, it becomes:
> 994896127
> 994896984
> 994895713
> 994897215
> 994896447
> 
> It is because CPU is changed from 1.8GHz to 1GHz. TSC is changed dynamically
> while QEMU is working.
> I think your results are from mobile Pentium III.
> I don't know much but a power management of mobile Pentium III works without
> software?
> 
> I attached a patch that I modifed from your patch. It can be applied by
> patch -p0. I checked it works for Athlon 64 with cpuspeed service (Power
> Now!). ticks_per_sec changed dynamically but a clock of win2k guest on
> x86_64 Linux host works fine.
> 
> If your guest OS is Linux, it is necessary to set clock=pit at guest OS'es
> startup. TSC may change.
> 
> I hope it works for SpeedStep.
> 
> I can't test i686 Linux host because ACPI and cpuspeed doesn't work on my
> PC.
> 
> I think it is better to detect CPU change signal and calibrate
> ticks_per_sec.

I think the proper solution is to calibrate the TSC regularily and to 
update the qemu clock accordingly. Of course the patch to read 
/proc/cpuinfo is still interesting to have a consistant ticks_per_sec.

Fabrice.