Re: [linux-audio-dev] [Slightly OT] How to access "real-time" capabilities

From: Martin Habets <errandir_news@email-addr-hidden>
Date: Thu Jun 09 2005 - 14:26:16 EEST

Hi Asbjørn!

On Wed, Jun 08, 2005 at 12:59:39PM +0200, Asbjørn Sæbø wrote:
> This is, I know, slightly off-topic for this group, as it does not deal
> with audio per se. It does, however, deal with the
> "real-time"/preemptible Linux kernel, for which I think most of the
> expertice is gathered here.
>
>
> The OS is Linux, the computer an ordinary PC. The task we are faced with
> is to run a program, tcpreplay, in such a way that it delivers its
> network packets as precisely as possible. I.e. the packets should be
> delivered to the network with the smallest possible timing error.

This depends on quite a number of factors besides the program itself,
like the accuracy of the RTC chip and the ethernet kernel-driver.

> We think that the way to minimize this timing error is to use a kernel
> with the real-time patches, as this will improve latency and response
> times.

I'd recommend trying a 2.6.11 (or later) kernel. It includes a number of
latency and pre-emption improvements.

> The question is how we can assure that the program really utilizes the
> real-time capabilities of the kernel. My understanding is that having a
> real-time capable kernel is only the first step, the second necessary
> step is to get access to this capabilities? So, how does one accomplish
> this, given that the program itself does nothing to achieve this?
>
>
> * Will an ordinary program, run as root, take advantage of the real time
> capabilities of the kernel?
> * Will an ordinary program, run as a user that is a member of the
> "audio" group on f.i. Agnula, take advantage of the real-time capabilities?
> * If given a real-time kernel, what else is necessary to take advantage
> of its capabilities?
> * How does normal priorities (nice, renice) play together with the
> real-time kernel?

To add to Jack's answers: look at the manpage for sched_setscheduler and
friends.
Real-time programs are coded essentially different from "normal" ones (which
use time-sharing). If there is only one real-time program running it owns
the CPU until it manually yields the CPU to something else. If the program
does not yield, other stuff like the kernel never gets round to do it's
job. i.e this stuff is dangerous if not used correctly.
The RT limits solution implemented by some kernel folks puts a limit on
the percentage of cpu time consumed by these processes, so other stuff
should get some time to run as well.

I'd recommend staying away from using a real-time process for now. First
try 2.6.11. If needed renice your program to run at higher priority.
If that does not work, try to measure where the problem is. Could be the
program is not coded optimally, the network is too busy, or the kernel
network driver introduces a delay.

Greetins,
        Martin
---------------------------------------------------------------------------
30 years from now GNU/Linux will be as redundant a term as UNIX/MERT is
today. - Martin Habets
---------------------------------------------------------------------------
Received on Thu Jun 9 16:15:09 2005

This archive was generated by hypermail 2.1.8 : Thu Jun 09 2005 - 16:15:09 EEST