# No change when set\_processor affinity() is used **URL:** \ **Category:** GNU Radio\ **Created:** [May 12, 2015, 6:26pm UTC](https://www.ruby-forum.com/t/no-change-when-set-processor-affinity-is-used/241925 "2015-05-12T18:26:27Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\ **Post date:** [May 12, 2015, 6:26pm UTC](https://www.ruby-forum.com/t/no-change-when-set-processor-affinity-is-used/241925/1 "2015-05-12T18:26:27Z")
* * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ---
**Author:** ![Nemanja\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/7bcc69/32.png) [@Nemanja\_S](https://www.ruby-forum.com/u/Nemanja_S)\ **Post date:** [May 12, 2015, 6:34pm UTC](https://www.ruby-forum.com/t/no-change-when-set-processor-affinity-is-used/241925/2 "2015-05-12T18:34:38Z")
On 05/12/2015 12:25 PM, Nemanja S. wrote: > set\_processr\_affinity[some number between 0 and]. When I run the > Discuss-gnuradio mailing list > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) > My guess is that your ~/.gnuradio/config.conf specifies to use the > single-threaded scheduler. ---
**Author:** ![Nemanja\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/7bcc69/32.png) [@Nemanja\_S](https://www.ruby-forum.com/u/Nemanja_S)\ **Post date:** [May 12, 2015, 6:49pm UTC](https://www.ruby-forum.com/t/no-change-when-set-processor-affinity-is-used/241925/3 "2015-05-12T18:49:15Z")
What Marcus said; GNU Radio 3.6 with its default scheduler, which is aptly named thread-per-block scheduler, automatically runs every block in its own thread, and by default (ie. unless you explicitely specify affinity) lets the OS handle distribution to CPUs; that’s the reason GNU Radio applications tend to scale very well on multiple CPUs, even if the algorithms in the individual blocks are not heavily multithreaded. Greetings, Marcus ---
**Author:** ![Nemanja\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/7bcc69/32.png) [@Nemanja\_S](https://www.ruby-forum.com/u/Nemanja_S)\ **Post date:** [May 12, 2015, 6:53pm UTC](https://www.ruby-forum.com/t/no-change-when-set-processor-affinity-is-used/241925/4 "2015-05-12T18:53:55Z")
* * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ---
**Author:** ![Nemanja\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/7bcc69/32.png) [@Nemanja\_S](https://www.ruby-forum.com/u/Nemanja_S)\ **Post date:** [May 12, 2015, 7:02pm UTC](https://www.ruby-forum.com/t/no-change-when-set-processor-affinity-is-used/241925/5 "2015-05-12T19:02:41Z")
On 05/12/2015 12:52 PM, Nemanja S. wrote: > You are probably right, cause that file doesn’t even exist. I looked > at default gnuradio-core.conf in conf.d. > I suppose that something like that should be written in > gnuradi-core.conf, but really nothing. > Where can I find which option should be added? > How are you determining that this is only occupying a single core? Are you running on a VM? If so, how many cores does your VM simulate? ---
**Author:** ![Nemanja\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/7bcc69/32.png) [@Nemanja\_S](https://www.ruby-forum.com/u/Nemanja_S)\ **Post date:** [May 12, 2015, 6:55pm UTC](https://www.ruby-forum.com/t/no-change-when-set-processor-affinity-is-used/241925/6 "2015-05-12T18:55:05Z")
* * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ---
**Author:** ![Nemanja\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/7bcc69/32.png) [@Nemanja\_S](https://www.ruby-forum.com/u/Nemanja_S)\ **Post date:** [May 12, 2015, 7:08pm UTC](https://www.ruby-forum.com/t/no-change-when-set-processor-affinity-is-used/241925/7 "2015-05-12T19:08:32Z")
* * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) ---
**Author:** ![Nemanja\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/7bcc69/32.png) [@Nemanja\_S](https://www.ruby-forum.com/u/Nemanja_S)\ **Post date:** [May 12, 2015, 7:08pm UTC](https://www.ruby-forum.com/t/no-change-when-set-processor-affinity-is-used/241925/8 "2015-05-12T19:08:32Z")
If that file does not exist, GNU Radio 3.6.5 would definitely use the thread-per-block scheduler; you can try export GR\_SCHEDULER=TPB prior to executing your flow graph from the same shell. In fact, looking at top\_block\_impl.cc:59 in 3.6.5.1, it seems the scheduler selection isn’t read from a config file at all (which is a bug, which I think someone might timely fix, it’s still there in 3.7…); if you want to know what _your_ GNU Radio selects as a default scheduler, do export GR\_SCHEDULER=“a room full of monkeys trying to act like managers” python yourflowgraph.py The default scheduler will be printed. Best regards, Marcus ---
**Author:** ![Nemanja\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/7bcc69/32.png) [@Nemanja\_S](https://www.ruby-forum.com/u/Nemanja_S)\ **Post date:** [May 12, 2015, 10:15pm UTC](https://www.ruby-forum.com/t/no-change-when-set-processor-affinity-is-used/241925/9 "2015-05-12T22:15:29Z")
Hi Nemanja, I took the liberty of changing the subject to reflect the new topic 🙂 You’re right, the low pass filters that the firdes tool produces should have linear phase, meaning that their impulse response is symmetrical and they have a constant phase delay of half the filter length. I don’t really think your synchronization as it is broken, but your signals might be: - you’re doing a 27k-tap filter. That means you’re summing up 27k floating point numbers when doing the convolution of signal and filter. This _might_ be a bit harsh for the numerical accuracy that a single precision floating point number offers. IIRC, the general (un-hand-optimized) volk kernel doing this just takes a single accumulator variable and sums over all tap[k-n]\*sample[n]; not the optimal thing when it comes to numerical stability. However, hopefully no longer streaks in the filter impulse response have the same sign – thus minimizing these effects. I’d strongly recommend using gr\_filter\_design, and plotting your filter’s impulse, and its frequency response. Do you really need a transition width that narrow, or a ripple that small, or a suppression that high? Can you not decimate after the band pass? Does it have to be a complex band pass, or are the requirements in the upper and lower transitions so different, that you gain significantly by doing a LPF and a HPF after another? - You do complex2mag??-\>low pass-\>logarithm. I don’t really think taking the logarithm of a negative number is a good idea, and unless you now your signal very well, I don’t think you can avoid getting negative numbers out of that low pass [1]. Best regards, Marcus [1] [http://imgur.com/70feESf](http://imgur.com/70feESf) (by the way, that example is a bit constructed, but it brings the point across; it especially applies to situations where your signal gets clipped and you’re working close to nyquist)