Deterministic simulation using qemu-based simulator
 

I am using Marss cycle-accurate simulator, which uses QEMU. It is a full system simulator and gives both user and kernel stats. However, even if I take only user-stats, the statistics vary a lot between different runs. I have asked this question on marss site, but could not get good answer.

I was wondering if it has something to do with qemu. Or any qemu option, that can make simulation deterministic. I tried using -icount auto and still some variation is there. Is qemu affected by load at the host system? With simplescalar eio files, I have never observed any variation. I would be grateful for some help.

A shot in the dark: does the virtual OS track the real wall clock? If so, more host load would equal fewer virtual instructions completed per virtual timer tick, and the increased virtual L1 cache interference would affect virtual user mode.

Seeking Clarification
 

Thanks for answering. Could you explain it a bit further? I could not grasp the answer.
Sparsh

You mentioned kernel mode and that excluding it made some difference to your stats, so I inferred your simulated machine makes steady use of kernel mode i.e. has some sort of real OS in the simulation. Most OS's offer wall-clock timing service and have at least some wall-clock interrupts even at idle, one-per-second or some such, so if yours does offer that it's using at least some of its simulated cycles taking those interrupts. I see your simulator manages 200K instructions per second on a not-too-shabby host, so whatever simulated timer overhead there is is coming out of a very small budget -- and as your host gets busy, that budget drops proportionately. You mentioned that even just counting instruction completions in user mode you were still getting "some" variation, so I thought you might be comparing that variation against what you get when counting clock cycles instead. Completing fewer ips on the same workload means cache interference, again pointing to higher interference from interrupts.

All of that is pretty much guaranteed wrong if your simulated system isn't tracking the real wall clock, and even for the rest I know real systems not simulated ones. Thus my shot-in-the-dark caution.

Thanks. Actually what I meant is that if I run same simulation (same configuration and same number of instructions) two times and take kernel+ user stats they differ b/w two simulations.

Moreover, if I run same simulation (same configuration and same number of instructions) two times and take just user stats they differ b/w two simulations. This is not expected, since with such phenomenon, one cannot derive any conclusion from the simulations.

I think, if one does not use -icount option, qemu does not track the real-clock.
Sparsh