Ramon van Handel wrote:
> Getting back to updating with the timer: currently, you set a timer at 100Hz.
> However, linux programs the PIT at 100Hz, so that would imply that the VGA
> gets updated on every single timer tick. That is of course unheard of (it would
> lock up the system !!) so we're just fooling ourselves. I played around with
> it a bit and it seems that now too, the update freq varies heavily with the
> system load. What I don't like about the timer is that with a fixed frequency,
> you're either over-updating or under-updating: under-updating, if you set the
> frequency too low; over-updating, if the frequency's too high: ideally, you want
> to update once, and only once (except if the FB's not dirty, in which case you
> don't want to update at all), after each quantum the user program got. There's
> no way of guaranteeing this with a timer, you may update twice or three times
> that way, certainly when the frequency's high. There's no way of guaranteeing
> this with a separate thread either; however, assuming that both threads (user
> thread / video update thread) have more or less the same processing load (I
> assume the time spent in the kernel module is billed by the linux scheduler as
> I/O (system) time, not compute (user) time) the two threads would be treated in
> more-or-less round-robin fashion (they're both I/O bound so would probably get
> the same priority), which would be a good way to achive our goal.
>
> What do you think ? Kevin, what are your experiences with a timer-driven
> update system ? Of course, with BOCHS, it probably doesn't matter all that
> much either way because the CPU emulation is limiting factor...
To reiterate some things from the past (for those who have jumped on the
list recently), there are 2 time domains here. One time domain is
based on the amount of CPU cycles which have elapsed. All hardware
timing should be driven from this, which is (will be) obtained by the monitor
by sampling the Time Stamp Counter with the RDTSC instruction.
The second time domain relates to the user's perception. Regardless of
how slow the system is running, and how little the monitor is scheduled
on the processor, the user still sees 1 second wall clock time as 1 second.
Though after drinking a hearty stout, this can vary. This is a good candidate
for basing timing of delivery of information to the host output devices such
as video and sound.
In bochs, I only use one time domain, the first.
To have semi accurate delivery of video/sound/etc, you really need to
know that user process will be notified (roughly) at a particular time,
so using a timer is the only way I can think of to do this properly.
For video, a few times a second is good for now. For sound, a little more
will help. We should make this a fmw.conf option.
100hz is too frequent for now. Though, if we make it a configurable
option, then you could use it. I saw mention of people interested
in changing the Linux timer from 100Hz to 1000Hz, so maybe it's
possible some day you would want 100hz.
And sure, we could optimize our current approach by sampling the page
table dirty bits for the VGA text memory, and if they're clean, then don't
bother doing the memcpy() in timer_handler(). Still need to call bx_pc_system.tickn()
though, since it drives everything else including the video updates.
Just keep in mind, the way thing are currently done is a hack, since we
don't support the IO mapped frame buffer yet. When we do support it, it
will impose a healthy performance hit with a lot of video accesses. This
problem will be alleviated by special guest OS video drivers. So a lot of
this is temporary.
-Kevin
