Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Thu, Apr 3, 2014 at 12:10 PM, Alex W. [email protected] wrote:
- 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.
Alex
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
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
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Thu, Apr 3, 2014 at 9:11 PM, Alex W. [email protected]
wrote:
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