Ubuntu's A Fading Memory, PCLinuxOS and 64 Studio Are Fab. So Far.

A realtime kernel has little to do with software performance, such as how fast Audacity opens, or how fast you can scroll the waveform display of a large multi-track audio file, or zoom in and out, or apply effects. The only thing it affects is the priority given to tasks by the kernel scheduler. Tasks related to audio recording are given highest priorities, so rt kernels mainly affects latency when you're recording. You can use any Linux distribution for audio recording, with a few tweaks to get latency down to where it needs to be. This is an old but good article on latency, scheduling, and pre-emption: http://www.linuxjournal.com/article/8041

Audacity on stock PCLinuxOS runs great. Combined with JACK it even gets latency down to acceptable levels. PCLinuxOS on my Thinkpad makes a great little portable recording studio for interviews, podcasts, and two-channel music recordings. Once you have made your recordings you can edit them on any Linux system; you don't need a low-latency kernel for post-production. K/Ubuntu's performance was so bad I couldn't do that.

64 Studio is not based on Ubuntu. http://www.64studio.com/node/959

I am curious to know what 64 Studio and PCLinuxOS are doing to make overall performance so much better, and why Ubuntu is so lethargic on the same machines. I've gotten quite a few emails from readers with similar experiences.

Yeah I know, I should have crammed a book into a single article. Sorry.

TC -

You know so much more than I do about so many things IT and computing, so I am truly loath to correct you about anything, but....

I think you may have the essence of real-time computing wrong. Real-time computing isn't defined by its ability to prioritize processes. Decidedly non-real-time mainframes could prioritize any process to within an inch of its life. I spent years doing that very thing. I even -- good gravy -- designed a real-time system that ran on those non-real-time mainframes.

Here's the skinny about real-time:

Real time systems guarantee that no process will run longer than a given period of time. If they do not complete on their own, they are terminated.

Lots of applications would prefer to kill something that has run too long to be useful (in my real-time on the mainframe system, we were switching telephone calls).

PS -

FWIW -- my real-time system was real-time only by cheating. We let the phone company kill it after x time. yeah -- it hung on for however many milliseconds on our system, but I won't tell if you won't.

Thanks dino, I've read reams of docs and talked to kernel devs, and still had the wrong idea. That's the best and shortest explanation I've seen.

@TC

Did you post the wrong link to say 64 Studio is NOT based on Ubuntu? After all Hardy is an Ubuntu distibution, The Software update screenshot definately says Ubuntu on it. Did I quit reading too soon? Or have I missed something here?

The initial boot screen is Debian.

EDIT: Wait, I tried version 2.0, not the newest one.

> Real time systems guarantee that no process will run longer than a given period of time.

My understanding was that real time systems offered a guaranteed response time to events, The exact time varies with the architecture, but the key is that it's guaranteed. Obviously there are multiple definitions of the term.

@jdixon

In as far as hardware controllers and such are concerned you are correct. A real time kernel guarantees a fixed response time-frame. This is required for hardware, time sensitive inputs. This is the type of kernel employed for 64 Studio to guarantee specific response times for sound recordings.

> In as far as hardware controllers and such are concerned you are correct.

Thanks, cabreh. That matches my recollections from my old OS-9 days.

re: if 64 Studio is Ubuntu-based or not, the fine article states:

http://www.64studio.com/node/959 "This is a bit of a fine line... 64 Studio 3.0 is based on... 64 studio, being put together with the PDK tool, and cutting edge multimedia packages built and/or backported by our own in-house official Debian developer....

"Effectively we are just using the day to day packages from Ubuntu, and the Hot Stuff is 64 Studio.com backports / packages from Debian sources."

There is more, it's worth reading the whole thread to get the complete picture. Whatever they are doing, I love it.

jdixon -

Ummm....

That's another way of saying what I said. The only way to guarantee response time is to kill something that doesn't end within the window. Therefore, the true determinant of a real-time system is that it kills any task that does not complete in time.

> The only way to guarantee response time is to kill something that doesn't end within the window.

Well, OS-9 had some type of guaranteed interrupt response time, which is not quite the same thing. But I agree that if you have a fast enough processor, they're pretty close approximations of each other. Of course, OS-9 was designed to run on the MC6809, which is hardly a fast processor by today's standards.

jdixon -

That is why you have to kill long runners. Not only are events that fail to finish in the window likely to be useless, they will tie up resources needed by tasks that are trying to complete in their alloted time, increasing the likelihood that more tasks will fail to complete as they should.

Okay, dino, is there any valid difference between "hard real time" and "soft real time"?

gus3 -

I could be wrong about this, but, my understanding is that "soft" real-time systems aren't quite real-time in the sense of but perform well enough to meet the need at hand.

For example:

Let's imagine that you have something that must be responded to appropriately within 500ms. Instead of using a real-time OS, you do a little modeling. You discover that, under the conditions you need, that 99.8% of all processes will complete within your window and that you can handle the 0.2% misses in a way that doesn't hurt anything. You will have achieved real-time performance without a real-time system.

Okay, here's my understanding:

"Hard real time" means, if a signal is not handled within its time limit, the results will be catastrophic, anything from program failure to equipment damage to human injury or death. It has nothing to do with the time limit imposed. Example: furnace temperature sensing. Failure to sense temperature can cause structural fire and human death, although its time limit could go as high as ten minutes or more. But once the limit is exceeded, there needs to be a warning of system failure and loss of control.

"Soft real time" means that the results, while erroneous or degraded, are not catastrophic. Example: monitoring average motor speed for maintenance purposes. (This is a real example.) Motor was torn down and re-built after every mission. Company ordered a monitoring system to report motor speed, in order to avoid expensive maintenance procedure when possible. System reported when average speed dropped below so many RPM. Due to averaging process, a few hundred dropped IRQ's introduced only a small error, which was quickly absorbed into the statistics. If result was borderline, management could order tear-down and rebuild anyway, just on general principles.

(Side note: the motor monitoring system had limited multi-tasking with tunable priorities, and ran on an original IBM PC XT. I learned a lot of vocabulary studying that code.)

How well does that mesh with your understanding, dino?

gus3 -

That's a pretty fuzzy way to look at it. You can have a hard real-time system without catastrophic (depending on your definition) results. Telephone switches come to mind. You might miss a connection -- which is certainly catastrophic to your call attempt -- but you can try again.

Look again at what you wrote and realize how it maps to OS requirements:

If it is catastrophic for an event not to complete in time , then you have to guarantee some non-catastrophic handling of the event within your time constraint. The only way to do that is to terminate processes that will not complete in time and provide some alternate "safe" default handling. Otherwise, you are at the mercy of the application and any bugs therein.

Gah... addressed to the wrong person. Will correct.

As I understand it ("program failure"), your telephone switch example does qualify as "hard real time." The attempt has failed catastrophically, and cannot be recovered.

Even though we're using different definitions, I think our understandings probably line up.

EDIT: I say "program," you say "process." Yours is more correct.

gus3 -

Yes. The telephone switch example absolutely is hard real time. In fact, I spent a xome time at Lucent, which is where I finally learned the meaning of real-time.

> Even though we're using different definitions, I think our understandings probably line up.

I'd say so, yes.