Hi,
I’m having issues using the hier_block2. When I create a flowgraph
consisting of roughly 12 blocks, I don’t get any overruns. However,
combining blocks (e.g. source -> hier_block2 -> sink) results in a ton
of overruns. The parameters of the individual blocks that have been
combined into the hier_block2 have not changed. Does the hier_block2
wait for the work function of each of the blocks it encompasses to
return before producing outputs/requesting more inputs? Any thoughts or
advice would be greatly appreciated.
Thanks,
Jordan
On 11/22/2011 04:20 PM, Jordan O. wrote:
Your saying that a flow graph of identical topology has different
performance when moving some of the blocks into a hier block?
If thats the case, its hard to believe. The the flow graph is run, its
essentially flattened. There is no difference to the scheduler or
buffers whether or not hierarchical blocks were used.
-josh
On Tue, Nov 22, 2011 at 7:53 PM, Josh B. [email protected] wrote:
hier_block2 wait for the work function of each of the blocks it
-josh
Yep, what Josh said. If this really is the case, though, it’s definitely
a
problem. Instead of using USRPs and looking at the overruns as your
benchmark, could you put in a signal source and a gr_head block of some
number of samples (10 to 100 million or so, enough to get a good
measurement) and switch out your sinks for null_sinks. Run the program
and
time it between the non-hier block and the hier block version and let us
know what you get.
Thanks,
Tom
On Tue, Nov 22, 2011 at 9:11 PM, Jordan O.
[email protected]wrote:
Thanks Josh and Tom for the info. Tom, I was unable to profile my
flowgraphs using your suggested method. For some reason, the head block
does not predictably stop the program. For example, if I specify 15 items
it will return immediately (as expected), but if I use 16 items it will
hang.
That sounds like some work function isn’t behaving correctly. Besides
which, 16 items won’t do you much good for profiling the timing. You’ll
need millions of samples to run long enough to get a good estimate.
Tom
On 11/22/2011 06:16 PM, Tom R. wrote:
On Tue, Nov 22, 2011 at 9:11 PM, Jordan O. [email protected]wrote:
Thanks Josh and Tom for the info. Tom, I was unable to profile my
flowgraphs using your suggested method. For some reason, the head block
does not predictably stop the program. For example, if I specify 15 items
it will return immediately (as expected), but if I use 16 items it will
hang.
That sounds like some work function isn’t behaving correctly. Besides
Perhaps we are missing a coding guide on how to write work functions.
Helpful tips like:
If your work function blocks, it must block in an interruptible call,
have an interruption point, or manually check for thread interrupted.
The start method should be used to cleanup state before work is called.
Things can get hairy of your last work was interrupted and state
variables were left kind of “funky”.
And other useful tidbits… I bet many blocks in gr dont follow the
coding guidelines that I just made up, and hence, may have issues with
lock/unlock working properly. 
-Josh
Thanks Josh and Tom for the info. Tom, I was unable to profile my
flowgraphs using your suggested method. For some reason, the head block
does not predictably stop the program. For example, if I specify 15
items it will return immediately (as expected), but if I use 16 items it
will hang.