Re: [Discuss-gnuradio] Sheduler: do not consume all "input items" and return 0 "output items"

[Tom Rondeau]

On Thu, Apr 3, 2014 at 9:11 PM, Alex Weihkopf <address@hidden> wrote:

Thanks. So I guess I have to invest more time.

 

Regarding the second question:

 

I constantly consume ALL input items that stream into my block, but I do not let them pass (or very rarely). In my understanding, all blocks behind this "valve" lie idle since they don't have any input items. So the CPU workload should be very small and the few items that pass the valve should not have a great effect.

 

Why am I getting worse performance with those few passed elements?  

 

Alex

Hard to say, but that's one thing that our new Performance Monitor tool is supposed to help you find out.

The big thing in these cases is the scheduler. You might be calling into things far more often than you both want and expect, causing overhead in the scheduler to set up the blocks. If you're looking at performance issues, looking into your interaction with the scheduler is key.

Tom

 

 

Gesendet: Freitag, 04. April 2014 um 00:09 Uhr
Von: "Tom Rondeau" <address@hidden>
An: "Alex W." <address@hidden>
Cc: "GNURadio Discussion List" <address@hidden>
Betreff: Re: [Discuss-gnuradio] Sheduler: do not consume all "input items" and return 0 "output items"

On Thu, Apr 3, 2014 at 12:10 PM, Alex W. <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio