[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Queries regarding FPGA
From: |
Stephane Fillod |
Subject: |
Re: [Discuss-gnuradio] Queries regarding FPGA |
Date: |
Wed, 1 Mar 2006 09:25:13 +0100 |
User-agent: |
Mutt/1.5.11 |
On Mon, Feb 27, 2006 at 08:28:56AM -0800, Thomas Schmid wrote:
> Isn't one of the problems that Linux is not a real time os, i.e.,
> exact time scheduling is impossible? As far as I know, linux timers
> have an accuracy of 1ms (i.e. 1 jiffie in the kernel). If you want to
> have shorter delays, you use the udelay function and do a busy wait.
> Or is there something that I am missing?
nanosleep(2) used to have that wanted passive/active sleep, but it isn't
the case anymore with Linux 2.6 kernels.
Most of the time, with an appropriate design, you just don't need a real
time OS. However, if you are in tight feedback business or alike,
and haven't found out a another way, Xenomai[1] under a patched Linux is
the solution, with hard accuracy in the order of <10us, task run
from user-space, with a POSIX skin API.
[1] http://xenomai.org
> 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
- Re: [Discuss-gnuradio] Queries regarding FPGA, Eric Blossom, 2006/03/01
- Re: [Discuss-gnuradio] Queries regarding FPGA,
Stephane Fillod <=
- 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, 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