Kevin Lawton wrote:
>
> Ramon van Handel wrote:
>
> > How about animation ? And games ? Stuff like that ?
> > Anything remotely "realtime" will flop.
>
> They won't flop, they'll execute slower, but scaled down
> very proportionally, and all the interrupts will be delivered
> exactly as expected. If we make a 400Mhz machine look like
> a 300Mhz machine who cares.
No, you missed the point.
First of all, what you're saying is not true: it won't be
scaled down proportionally. The amount of CPU time a
process gets depends on the system load, which may well
vary (considerably) during the uptime of the virtual
machine. And in your model, the amount of CPU time ==
the amount of virtualised time.
Secondly, I couldn't care less about a 500mhz machine
behaving like a 300 one. Nothing wrong with that, you
can't avoid it anyway. What I'm worried about is how
timed I/O sources behave:
- timed interrupts (PIT, RTC, LAPIC)
- timed I/O ports (VGA VBL, RTC)
These are often used by system software for synchronisation
with "real time". The sucess of this is crucial to the
functioning of realtime/multimedia applications.
For example: imagine a video player. The video player plays
the video at the same rate on a 300mhz machine as on a
500mhz machine, because it relies on correct timing in order
to diplay frames at the correct frame rate (in neccessary
skipping frames that it can't keep up with). However,
our VM in your model will *not* behave like a 300mhz machine
on a 500mhz one, as you suggest: all timing sources will
be slowed down, so also the frame rate of the video, which
makes it look ridiculous. Same goes for any other realtime/
multimedia application. Don't forget that external timing
sources are not bound in any way to the processor speed.
> If you have a system which is not running as fast as you
> want, you do nothing to help matters by hammering it
> with even more interrupts/second so it has to do even
> more work. The best way is to let everything slow
> down in a very scaled and linear fashion.
It's not a matter of not going fast enough.
A system running only a video player may be, on a fast
processor, idle 90% of the time and only active at
those times that it needs to display a frame. Your
model makes a mess of that, which is NOT because the
system is not running fast enough but because the
synchronisation is messed up.
> We can probably handle some skewing. Though, there will be
> a threshold, at above which excess skewing will make
> performance drop through the floor due to the excess
> interrupts you drill the guest OS with, and response
> time will actually be worse than without monkeying
> with the timing.
In overload situations, there's no helping performance
anyway. Of course we need an overload check; but such
a situation is not an optimal situation to be running
FreeMWare in anyway (i.e., even without skewing I'd
not expect it to perform very well that way).
> Trial and error will determine if the stuff you run
> handles the timing hacks well. If it does, and you're
> happy with the performance then it's a win. If your
> computer bursts into flames and Bill Gate's head pops
> out of your monitor and he still has that really bad
> $5 hair-cut, then hey, you might want to turn the
> timing stretch aggression factor down. :^)
LOL :)
> > Yes, that sounds like a good plan.
> > I'll see whether I can find more info on this time stretching
> > stuff. How did DISCO handle this, I wonder ? I'll reread
> > that article when I'm at home.
>
> That's a great idea.
There's no work about timing in there.
I'll have to dig into the library and look up all those articles
that are referenced in the DISCO article... (some nice review
articles in there, too.) I'll do that next time I'm at school.
> > We can use channel 1 of the PIC... I don't think linux uses that,
> > but I'm not sure. How about other OSes ?
>
> You probably meant to type PIT.
Yeah. Typo :)
> I'm not sure, is this connected
> to an interrupt on newer machines? Anybody?
Hmmm... I don't know. I use channel 1 of the PIT in my scheduler
but I use it in such a way that it never should produce an
interrupt...
Ramon
