From: Eric Blossom <address@hidden>
To: address@hidden
Cc: address@hidden
Sent: Thu, Jul 22, 2010 10:40 pm
Subject: Re: [Discuss-gnuradio] GNU Radio scheduler behavior
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?
1- GNU Radio 3.2.1
> 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?
2- I'm not running out of CPU cycles ... at least it doesn't seem like it
> 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 :-)
3- I've been
dissecting the filtering blocks in GNU Radio in hopes of doing the same
on the DSP. It's my understanding that the filter can process
(noutput_items + ntaps) for each iteration. For DSP filtering, I've
tried just copying "noutput_items" to the DSP, zero pad in the end by
"ntaps" and write back "noutput" items to GNU Radio and I also tried
passing (noutput_items + ntaps) to the DSP and filter noutput_items
long. My results match with the GNU Radio GPP implementation when I
pass (nouput_items + ntaps) inputs so I'm assuming that this is correct.
> 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?
4- I'm not
specifying the scheduler type so I'm assuming that the thread-per-block
scheduler is used. Even when I specify the scheduler "GR_SCHEDULER =
STS ./mygraph.ph" and "GR_SCHEDULER = TPB ./mygraph.ph" the behavior
seems unaffected so I decided to leave the standard scheduler. It's
possible that environmental variable was not being passed porperly I
just couldn't figure out how to change the scheduler directly from my
flowgraph even if that is possible.
5- Regarding
if the code is thread safe, with my code there can only be one call to
the DSP at a time so two threads cannot call the DSP at the same time
but all the DSP handlers are static variables so they don't have to be
called by the same exact thread everytime. Though I have all my DSP
code in a static library outside of GNU Radio
> 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
How can I trace and/or log the scheduler I'd like to see if the scheduler is crashing, waiting for data, or what exactly. Thanks for your help in this Eric
al