Re: [Discuss-gnuradio] GNU Radio scheduler behavior

[Eric Blossom]

On Thu, Jul 22, 2010 at 10:18:41PM -0400, address@hidden wrote:

> I think I'm running into some scheduler issues in GNU Radio that I
> don't really understand.  I've been working on running GNU Radio
> blocks on the Beagleboard's DSP by writing new DSP specific custom
> signal processing blocks When I run simple QA python test scripts
> everything works fine.

What version of GNU Radio?

> If I start incorporating the block into more
> complex GNU Radio flowgraphs, the work method is occassionally not
> called.

Are you running out of CPU cycles?

> When I run my code in debug mode I can see the DSP being
> initialized and parameters being passed to it but once the flowgraph
> starts everthing hangs when I comment the DSP block out of the graph
> everything works fine.

Sounds like something's wrong with your block :-)

> Just because I'm not sure what else to do, I added
> gr_enable_realtime_scheduling().  With this the "Work" method would
> occassionally get called.  I'm using an interpolator class template
> and from what I see, the "work" method calls "general_work" and the
> consume_each() method so I guess I don't have to dabble with that.

> The other thing, my code blocks during each function call to the
> DSP, would this somehow affect the scheduler?

If you're using the single-threaded-scheduler, you MAY NOT block in
your work function.  It should work OK when using the thread-per-block
scheduler, assuming that your code isn't stepping on memory that it
doesn't own, or other types of problems.

Is the DSP code that you're calling thread-safe? Or does it have some
assumptions built in such as it's only ever called by the same thread,
it's not reentrant, etc?

> I'm guessing not since not even the debug printf statements appear
> at the beginning are printed to the screen.

> I'm not quite sure how to debug the schdeuler calls and such related
> topics, any help would be greatly appreciated.

Try writing more comprehensive test cases for your block.
What is its io_signature?  How many samples do your test cases run
through it?  Try running at least 32K samples through your block.

My first guess would be that your block is trashing memory that
doesn't belong to it.  Perhaps it's writing beyond the end of some
buffer?  If you've derived from gr_sync_interpolator, be sure that
the main loop in work is executed noutput_items/N times, where N is your
interpolation factor.  Each iteration of the loop should produce N
output items.  What value are you returning from work?  Is it less
than or equal to noutput_items?  If not, fix this.

Does the compiler produce ANY WARNINGS when compiling your block?
If so, MAKE THEM ALL GO AWAY.

If you are passing pointers to the block's input or output buffers to
your DSP code, know that they are ONLY VALID for the duration of the
call to work.  If the DSP thinks it can read or write from them
outside of that temporal window, that would definitely cause a problem.

Eric