Wed, 17 Jan 2001 Bernhard Kuhn wrote:
> 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
I'm not so sure about that... I find Quake III Arena hard to play if it drops
below some 50 Hz. A total stall for 100ms (some 6-10 frames) is very
frustrating in a fast game, even if it happens less than one per minute.
Besides, it gives a very flaky feeling, and an impression of poor quality,
which is not aceptable for a dedicated gaming system.
Might be different for "serious" VR, but if that's the case, it's probably
going to change very soon. Demands tend to increase with the capabilities of
the hardware, and looking at the modern 3D games, people will soon realize that
they shouldn't put up with VR that feels like early experimental 3D.
> * 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!
Yep, but that doesn't keep the *kernel* from doing things that take well beyond
200 ms on some systems! Granted, this is under heavy load, but are you going to
stay away from disks, use static memory allocations for everything and so
on...? It may not be a problem for you now, but audio hackers have to face the
fact that we need to push at least one hard drive to it's limits at the same
time as doing 3 ms input->output latency DSP to get our work done. This is
what many of us frequently use the machines for already (using dedicated DSP
hardware for the processing, or simply putting up with 50-500 ms... aaargh!!!),
so we might as well design for it from the ground up.
> 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.
Well, see above; that's no good for hard disk recorders and direct-from-disk
samplers! :-)
> At least with NVdriver, since its glSwapBuffers() function
> seems to do a busy wait ...
Hmm... So do my hacked Utah-GLX drivers for Mach64 and G200/G400 as of about
yesterday, as there was no other way I could avoid tearing. (No hardware
pageflipping, so it's essential to sync with the retrace before starting the
back->front blit - which is not done in the original version.)
However, I'm working on a solution that will make the retrace sync code more
tolerant to being preempted by higher priority SCHED_FIFO threads without
missing the retrace entirely, as is the case with the normal code. It runs
already, but needs some more tweaking.
One could move the low level part of the driver into an RTL thread or signal
handler, though... Very non-portable, but what the heck - it doesn't seem like
anyone cares much about getting high quality animation into the mainstream
drivers anyway. (Well, at least not for the XFree 3.3.x based drivers - 4.0.1
is different, as it supports true pageflipping, which eliminates the problem on
all serious video cards.)
> > 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).
Meanwhile, I've tried running Q3A with the hacked G400 driver, and it does look
a bit smoother, and most importantly; all traces of tearing are gone!
Everything looks even more solid and rigid than it used to. :-)
> > > 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 ...
Noticed that. Also, Nutscrape happily keeps the mouse pointer grabbed for
extended amounts of time if it gets a chance. Scary program...
> Don't know why ...
Windoze feel? ;-)
I prefer implementing that using unstable but uttery cool beta software - that
way, I can at least have some fun before my system internals start playing
their (usually) invisible, abstract version of Q3A. :-)
> > 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!
Will get back to it some time. It will very likely gain priority as I get
increasingly tired of looking at the fsck progress bar! ;-)
BTW, I've thought of adding a key to the kernel Magic SysRq set; "kill all RT
threads". However, the watchdog is simpler (probably), nicer, more useful etc,
so I'll probably start with that, and trust myself not to be nasty and letting
root programs promoting themselves to the highest prio - as that would lock the
watchdog out! (The idea is to run normal RT applications as non-root, and have
them ask the watchdog to set their scheduling mode and prio. That way, the
watchdog can ensure that it'll always be alone on the lowest and highest
SCHED_FIFO priorities. (One thread for the watchog itself, and one for the CPU
overload monitor thread.)
> 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 ...
Yeah, you give the kernel and all kinds of other things extra chanses to steal
the CPU from you and keep it for quite a bit longer than the desired 10 ms...
> i realy will have to have a look at this low-latency thingy ;-)
Could potentially fix most of the problems, but we may still be facing problems
caused by the fact that X is not a real time application. Many pre-lowlatency
"real time" audio applications have been found to have severe design errors,
and had to be fixed to show significant improvement with the lowlatency patch.
This is even more likely for X and even the GLX drivers, as they're not even
thought of as real time in the first place.
//David
..- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
..- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> [EMAIL PROTECTED] -'
-- [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/
