Sure. But the vsync _is_ a kind of RT event.
> > - up to 200Hz music update (depending of the way the music is
> > generated and of the temporal precision of sound effects generation)
>
> Completely unneeded.
Did you ever try simulating an YM2151 or an YM2203 with an OPL (aka
soundblaster effect chip) _without_ generating samples? _Who_ are you
to tell _me_ what _I_ need?
> > - <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 :)
Because the music soundroutine does not generate samples but changes
register values every .005s.
> > - 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)
I don't want to think that the OS isn't able to do that. I actually
_trust_ the OS to do its best given the ressources it has. I just
mean that you can have multiple CPU-eating processes and at the same
time realtime tasks.
> > For such things, RT is the best existing tool for now.
>
> Nope. RT is the most primitive tool available for such things,
Cite another? Reimplementing the wheel don't count.
> but what about two such games on a multi-user machine?
Why not ? Provided that the CPU and peripherals are powerful enough,
linux should make that possible.
> > 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 :)
It's HZ/10. This is the important factor. Sub-jiffie latency.
> > 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.
RT is about best effort and sub-jiffie latency. If you want a DSW, go
find a nuclear test engineer, the lifetime of his computer is three
nanoseconds. What I say is that RT _semantics_ are useful for today
user interactivity problems, and any working hypothesis starting by
"there usually is only one RT thread on the system because RT is used
only for sub-microsecond latency for one application on a dedicated
computer" is broken.
OG.
-
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/