[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] SCHED_FIFO and NPTL
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] SCHED_FIFO and NPTL |
Date: |
Tue, 7 Mar 2006 22:49:49 -0800 |
User-agent: |
Mutt/1.5.9i |
On Wed, Mar 01, 2006 at 09:25:13AM +0100, Stephane Fillod wrote:
>
> > On 2/26/06, Eric Blossom <address@hidden> wrote:
> > > There is some fairly straight-forward work that can be done to reduce
> > > the latency of the user mode code, and that's probably a good first
> > > step. This would also including enabling real-time scheduling for the
> > > signal processing threads (SCHED_FIFO), reducing the amount of user
> > > space buffering for the USRP (no need to mess with the generic
> > > buffering in GNU Radio, it's not the problem), and transfering smaller
> > > chunks of data across the user/kernel boundary (that that won't help
> > > throughput!).
>
> This step would be very good!
>
> If we go the SCHED_FIFO way, it would be neat to be able to enable it on
> a thread by thread basis. Actually, the Omnithread library has already
> support for SCHED_FIFO policy for POSIX systems. Since running
> applications as root is no good, what we're missing here is a wrapping
> of POSIX libcap in Omnithread/POSIX to gain secheduling priviledges,
> pretty much the same way JACK is doing it, as explained here[2]. Then,
> thanks to the realtime-lsm kernel module, regular users of a group
> can gain access to the SCHED_FIFO policy. The audio guys went before
> us, the libcap and realtime-lsm package can be found on most moderns
> distros.
>
> The day we leave the SCHED_OTHER safe world, GNU Radio will need to have
> implemented in its flowgraph scheduler a watchdog to spare at least 1%
> when choking 100% of the CPU time...
>
> [2] http://jackit.sourceforge.net/docs/faq.php#a5
Stephane, do you know the current status of this[2] situation:
Currently (as of 2.6.7) JACK has a serious problem creating
SCHED_FIFO threads for real-time processing. It is unclear whether
this is a bug in JACK, in the new Native PThreads Library (NPTL), or
in the 2.6 kernel. At the moment no one has a solution, but there is
a workaround: define LD_ASSUME_KERNEL=2.4.19 in the environment of
the jackd process and of every JACK client. The easiest way to do
this is setting it in ~/.profile , or wherever you customarily
define global environment variables. Glibc developer Ulrich Drepper
explains the operation of LD_ASSUME_KERNEL in more detail.
Using LD_ASSUME_KERNEL=2.4.19 effectively forces the old (pre-NPTL)
behavior, which means that acquiring an uncontested mutex requires a
trip to the kernel. I believe it also means that mutexes won't work
in shared memory across process boundaries. Those seem like total
losers to me...
Eric
- Re: [Discuss-gnuradio] Queries regarding FPGA, Eric Blossom, 2006/03/01
- Re: [Discuss-gnuradio] Queries regarding FPGA, Stephane Fillod, 2006/03/01
- Re: [Discuss-gnuradio] SCHED_FIFO and NPTL,
Eric Blossom <=
- Re: [Discuss-gnuradio] SCHED_FIFO and NPTL, Frank Brickle, 2006/03/08
- Re: [Discuss-gnuradio] SCHED_FIFO and NPTL, Eric Blossom, 2006/03/08
- Re: [Discuss-gnuradio] SCHED_FIFO and NPTL, Frank Brickle, 2006/03/08
- Re: [Discuss-gnuradio] SCHED_FIFO and NPTL, Eric Blossom, 2006/03/08
- Re: [Discuss-gnuradio] SCHED_FIFO and NPTL, Robert McGwier, 2006/03/08
- Re: [Discuss-gnuradio] SCHED_FIFO and NPTL, Eric Blossom, 2006/03/08
- Re: [Discuss-gnuradio] SCHED_FIFO and NPTL, Frank Brickle, 2006/03/08
- Re: [Discuss-gnuradio] SCHED_FIFO and NPTL, Eric Blossom, 2006/03/08
- Re: [Discuss-gnuradio] SCHED_FIFO and NPTL, Lamar Owen, 2006/03/09
- Re: [Discuss-gnuradio] SCHED_FIFO and NPTL, Eric Blossom, 2006/03/09