1- GNU Radio 3.2.1
2- I'm not running out of CPU cycles 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. 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. -----Original Message----- From: Eric Blossom <e...@comsec.com> To: alfa...@aol.com Cc: discuss-gnuradio@gnu.org 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, alfa...@aol.com 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 6-My Data IO Signiture is complex and the coefficients are floating, I'messentially redoing the "gr_interpolate_fir_filter_ccf" filter on theDSP. I've tried test cases for inputs between 10->10,000 and FIRcoefficients of upto 140 taps. I'm hard copying the data back andforth between the GPP and DSP because of some MMU limitations. I'mcurrently hardcoding interpolation to 1 until I make sure thateverything works so for now the loop is running noutput_items. There are two warnings or so in my code caused by typecasting buffer size parameters that I am passing to the DSP. But those occur during the work function which is not called when this problem occurs How can I trace and/or log the scheduler I'd like to see if thescheduler is crashing, waiting for data, or what exactly. Thanks foryour help in this Eric al
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
