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 
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