CPU Affinity vs Hier Blocks

Hi Folks,

A quick question on CPU affinity when using hier blocks. I can set the
affinity in each of the blocks that makes up the heir block, but I can
also set it once I instantiate my hier block in my main flowgraph.

Anyone know the behaviour in this case ? If I leave all the blocks
within the heir block with no CPU affinity defined, will they inherit
what I configure in the heir block itself ?

If I put a CPU affinity on those blocks within the heir block, I guess
that would be honoured over what I configure for the hier block itself ?

Can anyone confirm ? I’m doing some multiple frequency RX, with
identical receive chains, which I’d like to put into a hier block, thus
simplifying my main flowgraph, but keep all processing for that chain on
one CPU

Iain

On Tue, Oct 28, 2014 at 1:51 PM, Iain Young, G7III [email protected]
wrote:

If I put a CPU affinity on those blocks within the heir block, I guess
that would be honoured over what I configure for the hier block itself ?

Can anyone confirm ? I’m doing some multiple frequency RX, with
identical receive chains, which I’d like to put into a hier block, thus
simplifying my main flowgraph, but keep all processing for that chain on
one CPU

Iain

Iain,

No, right now, when the hier_block affinity value is set, it forces all
blocks within it to that value for the processor affinity. The
individual
settings on blocks do not supersede this setting. Part of the reason is
how
this stuff is managed inside of the hier_block and basic_block classes
and
how hier_blocks are represented as structures internally. There’s some
work
we’d like to pursue in future releases that would make this
representation
easier to work with that should allow for better control of these
settings.
I think that what you want to do is the “right” way to handle things. If
a
block inside a hier_block does not have the affinity set, inherit it
from
the hier_block; otherwise, ignore the hier_block’s setting and use the
locally-set value.

Keep in mind, though, that the use of the affinity value is experimental
in
the sense that we don’t have a full understanding of what it’s going to
do
on your system. The default scheduling of threads might be the best
thing
for you and the flowgraph, or setting the affinity might be a really
good
thing if you do it properly. It’s really hard to say. A main motivation
for
creating the ability to set this value was partly so that we had the
option
of exploring this space, especially as we predict an increasing number
of
cores made available to us as well as heterogeneous CPUs where
hand-tuning
becomes more interesting and possibly more useful.

Tom

Hi Tom,

On 10/11/14 19:39, You wrote:

No, right now, when the hier_block affinity value is set, it forces all
blocks within it to that value for the processor affinity. The individual
settings on blocks do not supersede this setting. Part of the reason is how
this stuff is managed inside of the hier_block and basic_block classes and
how hier_blocks are represented as structures internally. There’s some work
we’d like to pursue in future releases that would make this representation
easier to work with that should allow for better control of these settings.

Thanks Tom, that will let me go write my heir block, and restore some
sanity to my flowgraphs, while knowing the processing is being done on
the core I think it is.

I think that what you want to do is the “right” way to handle things. If a
block inside a hier_block does not have the affinity set, inherit it from
the hier_block; otherwise, ignore the hier_block’s setting and use the
locally-set value.

Heh, not so much what I need/want to do, more just wanting to make sure
I know how it behaved, so I could make sure it was doing what I wanted
it to do :slight_smile:

Good to know I’m contributing to the debate, at least in a very small
way!

Keep in mind, though, that the use of the affinity value is experimental in
the sense that we don’t have a full understanding of what it’s going to do
on your system. The default scheduling of threads might be the best thing
for you and the flowgraph, or setting the affinity might be a really good
thing if you do it properly. It’s really hard to say. A main motivation for
creating the ability to set this value was partly so that we had the option
of exploring this space, especially as we predict an increasing number of
cores made available to us as well as heterogeneous CPUs where hand-tuning
becomes more interesting and possibly more useful.

Oh indeed. In this particular case, I am taking 25MHz of HF, then
decimating that down via some 200kHz BPF’s, before sending that on to a
chain of a FIR Filter, LPF, Complex-to-real, multiply, and audio sink
out to a loop-back soundcard, to which some software for decoding
certain ham modes (WSPR, 300 baud packet etc) connects to the other
end of, and knows no different.

Its each FIR filter chain onwards that I put on it’s own core, while
keeping the decimating BPFs on a separate core, so only sets of 250k B/W
samples are being moved between cores, while the 25 MHz stays on the
same core. Seems to work for me ™

If anyone is interested in the flowgraphs, they are at:

http://hal.g7iii.net/GRC/Multi-WSPR/

Sorry for the large white gap in one of them, there are actually 3
more “Linear Receive” chains as I like to call them, tuned to the 3
frequencies of the Russian Tinme Station RWM in there as well!

I’m attempting to write an FFT version, but while I think I have the
basics sorted in my head, once I select a bin, and convert it back, I
seem to be getting a far smaller sample rate than I expect, and even
resampling doesn’t seem to help, but that’s atopic for another email!

Iain