l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2001 Dec 30 17:10

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] real time in linux
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] real time in linux

begin: Nicole Carlson <nmcarlson@ucdavis.edu> quote
> On Sat, 29 Sep 2001, Peter Jay Salzman wrote:
> > i came across an article 'low latency in the linux kernel' written for
> > o'reilly's website.  here's a quote i find curious:
> >
> >   under certain circumstance, it may be possible to run an application
> >   in a condition known as setuid root.  as the name implies, this
> >   condition sets the user's ID to root status, raising the application's
> >   execution to real-time scheduling.
> >
> > this is NOT my understanding of setuid root executables.  if this were the
> > case, nice-ing a setuid executable would be meaningless since the application
> > would get the attention of the kernel whenever it wants attention.
> > also, there would be no need for 'real time linux' since running an app as
> > setuid root would imply real time scheduling.
> >
> I agree with you; I'm suspicious of O'Reilly's quote there.  "Real-time"
> is not a synonym for "really fast"; it has a very specific meaning, and it's
> rather non-trivial to implement.  In a real-time OS, processes are guaranteed
> to finish by a predefined interval.  The Linux kernel doesn't implement
> that[1]--if memory serves, it uses several levels of priorities (so
> kernel-space stuff gets priority over user-space stuff) and round-robin
> within priority levels.  It's possible (though I find it unlikely) that a
> setuid root program runs in the kernel-space priority queue, but even that
> isn't enough for true real-time scheduling.

thanks, nicole.  that last sentence was the one i was trying to grope for.
that even kernel space processes aren't real-time.  and it certainly doesn't
mean "very fast".

thanks for the confirmation.  btw, aside from this curious statement, the
article was pretty good, and pointed me to the most intriguing web site:


apparently, this guy wrote a couple of things of interest:

1. a kernel audio latency test.  measures the latency of audio within linux.
   he shows that audio latency on linux can be made much smaller than on
   a windows system.  meaning that linux is a better audio platform than
   windows (aside from the fact that there's no powerful easy-to-use audio
   software written for linux yet.  sox is NOT user friendly!)

2. a patch to lower latency within the kernel itself.  the patches got
   rejected by linus as being inelegant.  but he shows benchmarks, and
   they're more than quite good.  unfortunately, he seems to have stopped
   support for the patch; no 2.4 support.

his latency tester doesn't compile on my system; gcc doesn't seem to
recognize a spinlock_t data type.  obviously, a header file was split since
the 2.2 days and the defintion isn't being read in.

i'm trying to track the problem down right now, and sent an email to the
author in the offchance that he's still maintaining this stuff.


"You may not use the Software in connection with any site that disparages
Microsoft, MSN, MSNBC, Expedia, or their products or services ..."
                    -- Clause from license for FrontPage 2002

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!