discuss-gnuradio
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]