David Olofson schrieb:
>
> Mon, 15 Jan 2001 Bernhard Kuhn wrote:
> [...]
> > "rt" just places itself into SCHED_FIFO - like
> > David Olofson already explained - and then calls
>
> Please not that you also need the lowlatency patch to geuarantee scheduling
> latencies below 1 ms for SCHED_FIFO. SCHED_FIFO alone *does not* protect you
> from occasional latency peaks of 100 ms or worse under heavy system load; it's
> just a way of bypassing all other _user space_ tasks - not the lengthy kernel
> operations that the lowlatency patch addresses.
You are right, of course, but:
* even a 100 ms delay is not a too big deal for VR/gaming systems
* if all important processes (X, WindowManager and 3D-Application
are running in SCHED_RR (SCHED_FIFO needs option -f, BTW.), then
all other processes (sshd, ftpd, ...) don't even get a chance
of interfering - they are just blocked completly!
Trust me: as long as the application itself doesn't do disk
accesses (including swapping due to high memory usage),
it's the only application running on the system at all and
therefore running absolutly smoothly.
At least with NVdriver, since its glSwapBuffers() function
seems to do a busy wait ...
> I haven't tried running games as SCHED_FIFO yet - nice to know that it works
> most of the time!
Quake3, Tuxracer and some other "applications" like this are
doing it quite well (at least for me).
> (The average X application will eventually freeze, or even
> worse, freeze X eventually in my experience.)
You are right: you can easily get into the situation where the
X-Server hangs, i.e. running an application with a higher
priority as the xterm from where it was started and this
application could only be stopped by CTRL+C within the
xterm - which is blocked :-)
That's the reason for the high priority
bash on the serial terminal :-)
But at least, i always succeded in getting all games^H^H^H^H^H
applications running in SCHED_RR-space using "rt".
BTW: Today i tried xine (dvd movie player) with the decss
extension :-) works like a charm ...
Unless the X-Server and the WindowManager have a higher
priority as the one and only graphical application on the system,
you are usualy on the right side, but pitfalls are everywhere :-)
> > But beware: ensure that the X-Server and the
> > Window-Manager are running with a higher
> > priority as the 3D-program, because otherwise,
> > the computer might easyly seem to be freezed:
> > the machine is rather busy with
> > redrawing the 3D-application, but doesn't get
> > any new input from the X-Server/Window-Manager,
> > because these processes are never scheduled any
> > more)
>
> Yep, that's one of the problems, and as X and normal X applications aren't even
> designed for 100% CPU utilization - let alone being guaranteed to really get
> that - there will be problems with some of them.
Not necessarily since the X-Server usualy doen't use 100% of the CPU
on it's own for a long time: basicaly it waits for commands,
performs some action and waits again. If the X-Server runs in
highest priority, then a freeze usualy is the consequence of a
pilot error ... there is one exception: some bloatware programs like
Netscape and Staroffice can make the X-Server looping sometimes ...
Don't know why ...
> I was going to write a more automated solution (a real watchdog for SCHED_FIFO
> threads), but haven't had the time yet. It's really meant as a service for
> applications that explicitly use SCHED_FIFO for RT processing, but could of
> course be used as a complement to the RT command.
Good idea!
In a similar context: i played around with doing 10ms none-busy waits
from time to time in the main event loop of a 3D-application
(ok, i admit: it's a game) to give the rest of the system some
"time to breath". but this can easily result in this nasty
latencies caused by the kernel as you already described ...
i realy will have to have a look at this low-latency thingy ;-)
Bernhard
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
