> Now, what do games need, nowadays:
> - 50 or 60 Hz screen update
Aka. video refresh speed. vsf != fps.
> - up to 200Hz music update (depending of the way the music is
> generated and of the temporal precision of sound effects generation)
Completely unneeded.
> - <0.1s reactivity to player actions
This sounds more fair to me, but let's make it 0.03s reactivity.
With my new patch (sleeping processes get reloaded load-independantly)
this will be possible even with rc5des in the background.
As to why you would want 200Hz music updates with 0.1s user
reactivity, that is completely beyond me :)
> - adaptativity to CPU busyness (frame dropping, etc...) to avoid a
> general slowdown
> - ability to have long-running processes to precompute things
???
- processes can know the time, so the first point can easily
be done without RT.
- the second point is moot too, since you can both renice
processes and the long-running task is perfectly able
to yield the CPU when needed (that task should be able
to read the clock too. timeouts can be put in shared
memory when you think the OS will be too slow in waking
up the 'main' process)
> For such things, RT is the best existing tool for now.
Nope. RT is the most primitive tool available for such things,
but what about two such games on a multi-user machine?
> I agree that games are very different from standard unixy applications
> because they require a high level of interactivity, something at which
> unix systems are generally bad at (they're slow or fast, but not
> snappy).
My Linux box feels quite snappy. The load-independant recharge
of sleeping processes _does_ help quite a bit...
> Buffering don't help when you need low-latency interactivity.
The kind of latency you're talking about (user interactivity)
is about 100 times as long as the latency this thread is about
(controlling dangerous and expensive scientific machines).
While we need <1 uS latency, I'm pretty sure your games can
get away with 1 mS. There's a factor 1000 in that :)
> To sum up, add user-level, easy to use RT capabitilies to Linux and
> they will be used much more than one RT-thread per system.
> Provided that you have enough CPU, having to dedicate a system to each
> RT application isn't acceptable.
Then what will happen when two RT tasks for controlling your
nuclear plant _need_ to run at the same time?
RT is not about computing things, RT is about interacting
with the environment on a microsecond scale. In mission-critical
applications you can't afford to have one RT task _waiting_
for the other -- BANG, you just missed your deadline, there
goes your nuclear plant.
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/