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

On Sat, 29 Sep 2001, Peter Jay Salzman wrote:

> 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.

Kind of hard to find anything correct after the last comma.  Setuid root
is only related to permissions and has nothing directly to do with

> > >
> > > 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.

"Suspicious" is too lenient. It is dead wrong (surprising, given the
credits below).  And no, setuid doesn't move your process from userspace
to kernel space.

Look at http://www.linuxdevices.com/articles/AT8073314981.html

> 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:
> http://www.gardena.net/benno/linux/audio/
> 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.

spinlock_t is defined in $LINUXSRC/include/linux/spinlock.h.  In 2.2.19,
this includes $LINUXSRC/include/asm/spinlock.h.  In 2.4.9 it is right in
spinlock.h, but there are conditionals based on SMP support.

> 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.

Be careful playing with scheduling.  You run the risk of making your
system less (possibly much less) controllable when you make mistakes.
This stuff can get out of hand even in embedded systems, where you have
only a handfull of tasks to accomplish, and in a general purpose computer
you could find it doesn't work very generally anymore.

Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k

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:
O'Reilly and Associates
For numerous book donations.