Planning for the future

I’m currently doing some preliminary planning/budgeting for a
significant project involving Gnu Radio:

 http://tech.groups.yahoo.com/group/sbrac-astronomy/

My current thinking is to run dual polarization at the feedpoint, using
USRP2. The idea is that two USRP2s
can live in a weatherproof enclosure at the feed, providing signals
over GiGE to a pair of happy CPUs in the
control room. Still lots of unknowns, but I want to know what I
should aim for when I go seeking funding.

I’m thinking that with quad-core systems becoming cheaper, perhaps a
pair of quad-core signal processing
engines (Q6600 or better), along with perhaps 2-4GB of memory on each
system.

Right now, I’m getting by with a Pentium D 925 doing just fine with 8Mhz
input bandwidth driving
a sampled spectral display, and a total power display. I wonder at
what point the Gnu Radio stack
will grow serious multi-threading capability (particularly in blocks
like filters and FFTs), making multi-CPU
systems a real bonus.

I think I recall that the re-write of the signal chain “plumbing” was
partially to make multi-threading easier,
yes?

On Tue, Feb 12, 2008 at 08:29:05PM -0500, Marcus L. wrote:

I’m currently doing some preliminary planning/budgeting for a
significant project involving Gnu Radio:

 http://tech.groups.yahoo.com/group/sbrac-astronomy/

Right now, I’m getting by with a Pentium D 925 doing just fine with
8Mhz input bandwidth driving a sampled spectral display, and a total
power display. I wonder at what point the Gnu Radio stack will grow
serious multi-threading capability (particularly in blocks like
filters and FFTs), making multi-CPU systems a real bonus.

I expect to start on the “thread-per-block” scheduler either next week
or the week after. This should enable us to make good use of SMP
machines.

I think I recall that the re-write of the signal chain “plumbing” was
partially to make multi-threading easier,
yes?

yes.

Eric

On Feb 13, 2008 11:15 AM, Eric B. [email protected] wrote:

I expect to start on the “thread-per-block” scheduler either next week
or the week after. This should enable us to make good use of SMP
machines.

Hopefully, this question makes some sense, my background is in the SCA
which is already a “thread per block” architecture.

One of the things I find attractive about gnu radio is the flowgraphs
ARE single threaded. Will it be possible to use single threaded flow
graphs with a “block”. I’m concerned about increased end to end
latency if you have a flowgraph with many blocks that need scheduling
because they are running in separate threads.

Philip

Or have them all be LWP administered by something design with
concurrency in mind. ;-).

Bob

On Wed, Feb 13, 2008 at 01:37:16PM -0500, Philip B. wrote:

graphs with a “block”. I’m concerned about increased end to end
latency if you have a flowgraph with many blocks that need scheduling
because they are running in separate threads.

Philip

Don’t get too hung up on a literal interpretation of
“thread-per-block”. That will probably be the first implementation,
but the goal is to best utilize SMP/SMT machines. We could end up
with some kind of non-preemtive N user threads on M kernel threads
model.

For the cell stuff we do need to be able to block in the work methods
while waiting for offloaded stuff to complete, so that puts an
additional constraint on the N on M model.

Eric