The point is that vsync is done in the device driver, not in
the game. Device drivers don't need to be scheduled...
> 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?
You've got a point there, but my point is that with 0.1s
user reactivity, you can buffer a lot of events on the
device driver level.
> > > - <0.1s reactivity to player actions
> >
> > 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.
See above. These changes can be buffered both on the
device driver level and (often) in the hardware level.
> 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.
Processes that don't use much CPU will get higher priority
than CPU-bound tasks. This will take care of fast response
times without you having to tell the kernel that this task
is higher priority.
At the moment I'm compiling the kernel with 'make -j40 -l40'
and my mail reader remains completely responsive, almost to
the point that I would call snappy (remember that this is
under X, so xterm and the X server also need to get scheduled
in order to service my keypress). The load has gone far over
20 now and the system is constantly paging and swapping. My
80 MB system is averaging 100 disk I/O operations a second
and the system remains fairly snappy.
All games I know off also remain snappy without having to
resort to realtime. For the record, I'm using a P100 with
80 MB of RAM, 1 fast SCSI disk, 1 medium IDE disk and 2
slow disks.
> > > 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.
- making sure your interactive task doesn't use much CPU
- a good timesharing scheduler; one that gives a high
priority to tasks that don't use much CPU and that go
to sleep often
At the moment, it certainly seems like Linux has a scheduler
that fulfills these criteria -- it's still feeling snappy at
a load of 20 ;)
> > 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.
Why not? Because NO single-CPU system can run two RT tasks
at the same time. And if it isn't real RT, you might just
as well use properly designed 'normal' apps.
> > > Buffering don't help when you need low-latency interactivity.
> >
> > 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.
That doesn't matter. For waking up (when sleeping) you can
get by with HZ resolution. When being awoken by another task,
we don't wait until the next jiffie, but wake you up immediately.
> RT is about best effort and sub-jiffie latency.
If you have enough CPU, you can do this without RT. If you
don't have enough CPU, RT isn't going to help you anyway.
> What I say is that RT _semantics_ are useful for today
> user interactivity problems,
Sure they are, but timeslicing tasks have exactly the same
semantics. I don't see how RT is going to be different from
timeslicing tasks when it comes to user interactivity...
> "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.
If you really care about RT, there usually isn't going to be
more than one RT task on the queue. If you only need soft RT,
it doesn't really matter anyway.
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/