Sheduler: do not consume all "input items" and return 0 "output items"

Discuss-gnuradio mailing list
[email protected]

On Thu, Apr 3, 2014 at 12:10 PM, Alex W. [email protected] wrote:

  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.
time you return from work, the scheduler has to set everything up again
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
ability to compute it. Instead, we have the Performance Counters and
Performance Monitor system in place to allow you to see how your blocks
behaving. It might not be affecting you too badly in the end, depending
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
to make the most use of the number of items you’ve received. If the
performance is a bottleneck for your system, this is definitely
to look in to.


Again, yes, because you’re causing the scheduler to go through a lot of
extra work. This might help you out:

Also, for something like this, you can use forecast to tell the
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
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)).


Discuss-gnuradio mailing list
[email protected]

On Thu, Apr 3, 2014 at 9:11 PM, Alex W. [email protected]

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


Hard to say, but that’s one thing that our new Performance Monitor tool
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.


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs