begin: Nicole Carlson <[EMAIL PROTECTED]> 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: 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. 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. pete -- "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
