THANK YOU Ramon!!!! This is the kind of problem I was talking about in my
earlier post (which you very artfully shot down......). Maybe I didn't
state it in an efficient manner or something.... anyway..... My "solution:
is this (not that I have the faintest idea about how to pull it off): Pass
some sort of ACPI or APM compliant clock data to the guest OS from the
monitor derived from the reality that the host OS so whishes to hide for the
most part. This allows the guest to, for the most part, "not care" what
happens while it is not in control of the clock cycles on the CPU. This
would allow mail, schedule, and calendar applications to function properly
in most cases. This, however would be of little to no help for sound cards,
video capture, I/O emulation and the like. This is just my idea for a
solution, mind you, and comes from an idealistic non-program oriented point
of view.... so feel free to perforate it with as many holes as necessary
;^).
Drew Northup, N1XIM
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Ramon van Handel
> Sent: Monday, July 03, 2000 11:24 AM
> To: [EMAIL PROTECTED]
> Subject: Re: plex86: progress...
>
>
> >For what I said about timing, forget about host timing altogether.
> >It means nothing to the guest. I don't intend to derive timing
> >from the host in any way except to deliver timing events to
> >user code such as the screen refresh. Those kinds of things
> >have to do with wall-clock time, and have nothing to do with
> >the VM. (the VM doesn't care how often you see updates).
>
> We've talked about this before, and I'll spew my point of view again:
> this is not a good idea. The guest OS will not "feel" right. On
> the little
> details side, for instance, we'll find that the little clock in the corner
> of the windows taskbar runs completely asynchronously (and wrong) wrt the
> linux clock --- which also means that if you have date-relates
> programs (like
> you basic mailer application), all times will be wrong !! On the more
> important side, we'll have
> - Any even remotely real-time application will go wrong.
> For instance, movies would be played at too low speeds, sound would come
> in chunks, etc.
> - Driving of time-related hardware (CD burners) will go wrong, as you
> mention below.
> We do not want these effects !! To me, the idea that a multimedia
> application will not run inside the VM is completely unacceptable in our
> modern multimedia-driven computing world.
>
> The problem is that clock skewing, our proposed solution, will make timing
> unstable again -- the clock skew only works *per quantum* (we can speed up
> or slow down the virtual time per quantum, depending on the previous
> execution times, but not inside the quantum!) That means that delay loop
> calibration will probably go all wrong again (though it'll probably work
> better than it does now, and it would be pretty reliable on a constant
> load). I don't really have any idea how to get around this at the
> moment...
>
> -- Ramon
>
>
>
