[Qemu-devel] define desired speed?

[Qemu-devel] define desired speed?

[Jeremy C. Reed]

Any way to startup qemu with my own desired speed?

It does not have to be precise. And I don't want to slow down the host 
system itself.

For example, I am using a 1900MHz system and need to test some 
applications usability and performance as if it were running on a 233 MHz 
CPU (or close).

Bochs provides a CPU "IPS" (emulated Instructions Per Second) 
configuration that can be adjusted to get at least close to the desired 
speed.

I am using qemu-0.9.0 (on NetBSD), but I also looked at the online docs 
and didn't see anything related.

Also what do you use for benchmarking the estimated speed of qemu?

I know that BogoMips is not a real benchmark, but the Linux system I am 
running in qemu says it is at 7497.31 BogoMIPS which is the probably same 
as if I booted the Linux system outside of qemu on same 1900Mhz hardware. 
(I was hoping to see the BogoMips in the 200 to 700 range.)

  Jeremy C. Reed

p.s. I emailed your devel list because I didn't see a users list.

Re: [Qemu-devel] define desired speed?

[Laurent Desnogues]

On Jan 15, 2008 10:34 PM, Jeremy C. Reed <reed@reedmedia.net> wrote:
> Any way to startup qemu with my own desired speed?

You can't as qemu emulated target speed is not constant.
qemu generates code on-the-fly and uses optimizations
that result in big variations.

Add to that there's no cycle accuracy at all.

> Bochs provides a CPU "IPS" (emulated Instructions Per Second)
> configuration that can be adjusted to get at least close to the desired
> speed.

IIRC Bochs is an interpreted simulator so it can count
instructions.  Counting instructions is only a crude
approximation as most processors have pipeline and
caches.

> I know that BogoMips is not a real benchmark, but the Linux system I am
> running in qemu says it is at 7497.31 BogoMIPS which is the probably same
> as if I booted the Linux system outside of qemu on same 1900Mhz hardware.
> (I was hoping to see the BogoMips in the 200 to 700 range.)

7.4 BGIPS is an indicator that the bogo loop was very
well optimized by qemu and/or the timer is wrong :-)


Laurent

Re: [Qemu-devel] define desired speed?

[Mulyadi Santosa]

Hi...

On Jan 16, 2008 4:34 AM, Jeremy C. Reed <reed@reedmedia.net> wrote:
> Any way to startup qemu with my own desired speed?
 Check http://www.miroslavnovak.com/qemu-brake_en.php

regards,

Mulyadi.

Re: [Qemu-devel] define desired speed?

[Laurent Desnogues]

On Jan 16, 2008 4:05 AM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote:
> Hi...
>
> On Jan 16, 2008 4:34 AM, Jeremy C. Reed <reed@reedmedia.net> wrote:
> > Any way to startup qemu with my own desired speed?
>  Check http://www.miroslavnovak.com/qemu-brake_en.php

This can't be used to set the emulated processor at a given frequency,
it's just a way to slow down emulation.


Laurent

Re: [Qemu-devel] define desired speed?

[Jeremy C. Reed]

On Wed, 16 Jan 2008, Mulyadi Santosa wrote:

> > Any way to startup qemu with my own desired speed?

>  Check http://www.miroslavnovak.com/qemu-brake_en.php

Thank you. I am using it now with "-brake 75"

Before using the -brake, the system said it was 7497.31 BogoMIPS.
(The real host hardware as a 1900Mhz CPU.)

-brake 75  resulted in 3761.76 BogoMips

Also reported by the Linux kernel that booted in qemu:

	CPU clock speed is 4739.2721 MHz.
	host bus clock speed is 2500.1500 MHz
(I didn't notice the CPU clock speed or the host bus clock speed without 
-brake.)

Again my goal is to pretend the system is running on around 233 MHz CPU.

I am doing this to research "lightweight" open source operating systems 
and software for a book I am writing. (The book defines "lightweight" and 
explains how to evaluate software, improve or prepare software for small 
systems, and introduces a wide range of open source software usable on 
systems with very limited resources. If you are interested in giving 
feedback on my book outline or book in progress, please let me know.) It 
is more convenient for me to boot and use them in qemu versus installing 
many on various real hardware.

  Jeremy C. Reed