9 Jun
2005
9 Jun
'05
9:26 a.m.
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
---------------------------------------------------------------------------