Really big items, best practices?

GNU Radio
1

Hi everyone,

we’ve recently been working one some GR projects where item sizes can
get really big. One example is cyclostationary spectral estimation code,
which will be released soon.

If you’re not familiar with cyclostationary spectral estimation, here’s
the problem: the result of the estimator is a matrix, which, depending
on your estimator resolution, can be quite big (at least a several
hundred thousand floats per estimate, which would correspond to one
logical item).

With GNU Radio, very large item sizes do not work that well since the
inter-block buffers are shared between threads and therefore, max size
is limited by the OS. I’m sure you know what I mean :slight_smile:

Question is, what’s a good way to handle this? For the cyclo stuff, we
had to fix things manually by introducing separate buffers, splitting
the estimate into many small items and then manually keeping track of
what already had been consumed.

This doesn’t seem to be the ideal solution. The whole point of GNU Radio
is that someone else (i.e. the GR scheduler) takes care of all of this,
and I, the developer, can focus on the signal processing component.

I’m wondering if anyone has some experience with large items they would
like to share. In particular, is there a way to limit the number of
items in the buffers? Or is this possibly a shortcoming of GNU Radio?

Martin

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

2

On Fri, Nov 25, 2011 at 8:55 AM, Martin B. [email protected]
wrote:

logical item).
This doesn’t seem to be the ideal solution. The whole point of GNU Radio
is that someone else (i.e. the GR scheduler) takes care of all of this,
and I, the developer, can focus on the signal processing component.

I’m wondering if anyone has some experience with large items they would
like to share. In particular, is there a way to limit the number of
items in the buffers? Or is this possibly a shortcoming of GNU Radio?

Martin

Hi Martin,

Sorry for the delay in replying to this, as it’s possibly a very
important
question. My reason for the delay is that I’m not sure about the answer
and
was hoping either I would think of something or someone else would :slight_smile:

But here’s a suggestion anyway to hopefully get the ball rolling again.

Thinking of the results as one large matrix item probably isn’t going to
work. As you said, there’s a system limitation at play here. What if,
instead, you passed the data along as though it were a stream of floats
(or
complex floats). Along side that, the block that creates the matrix
sends a
“start of matrix” and “end of matrix” tag, so the blocks down the line
know
what to look for and can reassemble the matrix from there.

I’m assuming that all of your blocks in the chain that deal with the
data
as a matrix are home-brewed and not current blocks, so you would only
need
to add the tag-handling capabilities to your blocks.

Have you come up with another solution in the meantime?

Tom

3

With GNU Radio, very large item sizes do not work that well since the
inter-block buffers are shared between threads and therefore, max size
is limited by the OS. I’m sure you know what I mean :slight_smile:

So your machine has enough memory, but the special “shared-memory/
doubly-mapped” buffers used by gnuradio cannot be allocated large
enough? Another downside of the doubly-mapped buffers is that we waste
half of the physical memory reserved.

I have been giving some thought into supporting “linear” buffers. The
downside is that you have to consider special edge conditions. It may be
that the issue you are having is a motivating reason to implement this.
:slight_smile:

-Josh

4

You can always do what William Plishker (et.al) did for their GPU work
– go to < http://gnuradio.org/redmine/projects/gnuradio/wiki/GRConf2011

and look for GPGPU. They create a separate (but shared among the
various process threads), non-kernel memory buffer, and then place a
pointer (or handle, IDK) to it into the GR-buffer. In this way, they
can do processing on any number of items, using just a pointer per
effective buffer. Sort of takes the wind out of the GR scheduler
(since, for all practical purposes you’ll probably want do to processing
on each “item” as it becomes available), but I’m sure you can make it
work for you.

A historical note for those who care: This style of data propagation and
processing goes back to (at least) the “olde days” (late 60’s / early
70’s) before SDR (which really originated in the late 80’s, and the term
was coined in the early 90’s) – called “Flow Based Programming” & is
still in use today in various forms. You pass tokens (a handle or
pointer to data [possibly structured as a packet, or just an
unstructured frame]) around instead of actual data, do processing using
those tokens, keep passing them on and/or create new ones & discard the
old ones.

While I like double-mapped circular buffers because they make
edge-condition checking simple, they do have their limitations (e.g.,
can only be so large) – and, having the ability to pass tokens would be
quite useful for some types of processing. Seems like there should be a
way to have both at the same time, using the same underlying buffering
concepts. That way, you could pass actual data or just tokens to data,
and so long as the receiving block knew what to expect it could
accommodate.

My US$0.02 - MLD

5

On Thu, Jan 19, 2012 at 5:22 AM, Martin B. [email protected]
wrote:

for and

thanks for the suggestion. We’ve been doing it similarly, only without
the tags–following blocks simply knew what was coming and pieced it
together accordingly. The tags might actually be a nicer solution, much
more flexible.

Cheers
MB

Precisely. The tags give you the ability to make runtime
changes/decisions
as opposed to having to figure this out initially. Let us know how it
works
for you.

6

On Mon, Jan 16, 2012 at 08:03:52PM -0500, Tom R. wrote:

the tag-handling capabilities to your blocks.
Hi Tom,

thanks for the suggestion. We’ve been doing it similarly, only without
the tags–following blocks simply knew what was coming and pieced it
together accordingly. The tags might actually be a nicer solution, much
more flexible.

Cheers
MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association