# CPU Affinity vs Hier Blocks **URL:** \ **Category:** GNU Radio\ **Created:** [October 28, 2014, 6:53pm UTC](https://www.ruby-forum.com/t/cpu-affinity-vs-hier-blocks/232795 "2014-10-28T18:53:33Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [October 28, 2014, 6:53pm UTC](https://www.ruby-forum.com/t/cpu-affinity-vs-hier-blocks/232795/1 "2014-10-28T18:53:33Z")
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 ---
**Author:** ![Iain\_YoungS\_G7III](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/3da27b/32.png) [@Iain\_YoungS\_G7III](https://www.ruby-forum.com/u/Iain_YoungS_G7III)\ **Post date:** [November 10, 2014, 8:41pm UTC](https://www.ruby-forum.com/t/cpu-affinity-vs-hier-blocks/232795/2 "2014-11-10T20:41:09Z")
On Tue, Oct 28, 2014 at 1:51 PM, Iain Young, G7III [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![Iain\_YoungS\_G7III](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/i/3da27b/32.png) [@Iain\_YoungS\_G7III](https://www.ruby-forum.com/u/Iain_YoungS_G7III)\ **Post date:** [November 11, 2014, 9:58pm UTC](https://www.ruby-forum.com/t/cpu-affinity-vs-hier-blocks/232795/3 "2014-11-11T21:58:55Z")
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: > **[Album: Multi-WSPR](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