Re: [Discuss-gnuradio] Threaded model for USRP2 source

[Johnathan Corgan]

On Thu, Jul 23, 2009 at 10:51, Douglas
Geiger<address@hidden> wrote:

> Right, ok, this sounds like what I should be aiming for. Currently I just
> have a single main service thread calling libusrp2 twice: once for each
> USRP2 I want to talk to.

This is bad.  If the first USRP2 has no frames available, your thread
will block, even if the second USRP2 does.  Also, while the thread is
servicing one USRP2, the other is being ignored.

> Right - and this is the user space thread that talks to the kernel
> ring_buffer, right?

Yes.  FYI, libusrp2 will change in 3.3 (well, it will become libvrt)
and use UDP sockets.  This will ultimately allow the kernel to do the
demultiplexing of control and data frames (separate UDP ports), and
we'll be able to eliminate the service thread and one copy operation.

> Re: thread placement - are you referring to doing something to 'pin' threads
> to a certain core? E.g. numactl?

Yes.

> Yes, the enormous amount of information I would like to process in real-time
> is daunting: I think eventually I would like to move some of it into the
> FPGA, for the time being I find it much easier to experiment in the world of
> C++ (I haven't yet become fluent in Verilog).

Well, some could happen there, but if you need to manipulate samples
from multiple USRPs, as in MIMO, you're stuck doing it on the host.

> I think the main issue I'd like to remedy is the fact that I know my machine
> can handle two simultaneous streams of 25MS/s: i.e. if I spawn two separate
> processes, each talking to a separate USRP2: but my time-aligned source
> block is currently a bottleneck.

It's the sequential calls into libusrp2 that are the problem.

Johnathan