On Thu, Apr 3, 2014 at 12:10 PM, Alex W. <elektronens...@gmx.de> wrote:
> Hello everyone, > > when writing blocks for my projects I find it to be convenient to design > them as FSMs: > > A switch-instruction with states A, B und C. In all states fixed numbers > of input_items are processed, then I call "consume(i, fixed_number_X)" and > "return fixed_number_X". I do not process all input_items but let the > sheduler do the work. > > 1) Does it deteroarate the performance of my flowgraph when I do not > consume and return as much items as possible? (The fixed numbers are 500 to > 1000). If yes, how much? > Hi Alex, Yes, this will negatively affect the performance of your application. Every time you return from work, the scheduler has to set everything up again for the next entry to work, which means more overhead. How much this affects you is determined by a number of factors and we (right now) don't have the ability to compute it. Instead, we have the Performance Counters and Performance Monitor system in place to allow you to see how your blocks are behaving. It might not be affecting you too badly in the end, depending on what you're doing and what you need to be doing. For something like this, you might have to think to yourself what's the tradeoff in efficiency between the block and your time in writing the block to make the most use of the number of items you've received. If the block's performance is a bottleneck for your system, this is definitely something to look in to. > Also, I wrote a block which crosscorrelates the input stream with a > stored sequence. It always returns 0 output_items, only when the > crosscorrelation exceeds a threshold, a fixed number of samples is passed > to the next blocks. > > 2) Is this a proper way to implement a block for packatized data? Or does > it deteroarate the performance of my flowgraph if I return 0 output_items > most of the time? > > Thanks, > Alex > Again, yes, because you're causing the scheduler to go through a lot of extra work. This might help you out: http://www.trondeau.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html Also, for something like this, you can use forecast to tell the scheduler how many input items you require given a set of output items. Or, maybe more helpfully for something like this, you can receive a vector of items that's the size of the correlation you are performing, so one item is actually N samples for the correlation. Your IO signature would be something like gr::io_signature(1, 1, corr_size*sizeof(gr_complex)). Tom
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
