Re: [Discuss-gnuradio] SCHED_FIFO and NPTL

[Eric Blossom]

On Thu, Mar 09, 2006 at 12:24:30AM +0100, Stephane Fillod wrote:
> On Wed, Mar 08, 2006 at 12:26:07AM -0800, Eric Blossom wrote:
> 
> I assume you meant 'us' (micro-second), and not micro sample or micro
> Siemens :-)

Definitely micro Siemens!

> Talking about getting to the 32us area, this is what the Xenomai/RTAI
> guys are doing, turning Linux+average PCs into convenient DSP. On non-
> flawed hardware, one can get better than 10us latency. However, taking
> only 50% of a 32us period is not going to lead to linear consumption
> (think context switch, and not only register file). Besides, the bigger
> the chuncks of data, the more efficient the optimization of data 
> crunching loops, let alone the depth (history necessary for feedback)
> required by some filtering algorithms. But you know the drill already ;)

Yep.

> > (I'm also reviewing chapter 5 of the USB 2.0 spec to see how often
> > the h/w arbitrates for access to the USB.)

Summary: since we're using BULK transfers, as long as we're not
competing with a web cam or something, things should work out OK.  The
h/w is free to execute multple transactions per micro frame.

> Oh btw, the regular Linux USB stack probably won't be able to guarantee
> 32us latencies. The best bet here, is the usb4rt[3] project for Xenomai,
> a rewrite of USB stack with hard-RT in mind.
> 
> [4] http://developer.berlios.de/projects/usb4rt

No sign of EHCI, bummer.
Since they don't keep a real ChangeLog, it's a bit difficult to see
what they're been working on.

> Lucky you, dual CPU systems(SMP) have an easy solution. One dedicated CPU 
> bind to the time critical tasks, the other CPU for Linux, X-server, etc.

Yes, assuming that there's not some stupidity in the kernel or some
driver that kills the second processor ;)

> Whatever the solution, we're going to need to be able to evaluate its
> "fitness" for our particular GNU Radio load. IMO, we should check
> that by ourselves.

Agreed.  For the usrp latency test, I was thinking about a custom FPGA
build that would generate a series of packets, all zeros except the
first 16-bits of each.  The first 16-bits would contain a sequence
number, and a non-zero high bit.  Then run a detector in the FPGA with
its output wired to some d'board pins, that monitors the data coming
and going across the GPIF bus.  When it sees the non-zero high bit it
would output a flag and the sequence number -- independently for the
incoming and outgoing data.  The host code would just loop back the
packets it received from the usrp.  Using a logic analyzer, we could
see exactly what was going on.

> > Returning to the audio xrun problem: I think that in the typical USRP
> > + audio situation, xruns are aggravated by differences in the clocks
> > between the two domains and the fact that we aren't doing anything to
> > handle that situation.
> 
> I do agree. Then, how to we distinguish an xrun off a missed deadline
> from a xrun off a clock difference ?
> What are solutions in sight? "Get to know your clocks"?

For the clock difference problem, the idea is to have a flag passed to
the audio source/sink at instantiation time that says "OK to block or
not".  This allows the application to specify if the audio sink/source
should pace the pipeline or not.  If you're using a USRP and an audio
sink/source, you'd typically set the flag to "NOT OK to block".  Then
by watching the callback from portaudio / jack / alsa, and using a
ring buffer between the GNU Radio world and the audio world we can
explicity manage the flow of data to/from the audio subsystem.  We can
either fill or drop as required, without leading to a big backup in
the GNU Radio processing pipeline.

If you're looking for something to do, we could *really* use a
gr-audio-portaudio source/sink with these new semantics ;) 

The portaudio V19 stuff in CVS has good support for JACK and ALSA
under Linux, plus Windows and OS/X of course.  Weren't you pointing
this out years ago? ;) There's a skeleton gr-audio-portaudio module
checked in (copied from gr-audio-alsa and renamed).  It doesn't
compile, doesn't implement the new semantics, and doesn't have the
ring buffers.  It's patiently waiting for some highly skilled attention ;)

Interested?

Eric