No change when set_processor affinity() is used

Discuss-gnuradio mailing list
[email protected]

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
[email protected]
My guess is that your ~/.gnuradio/config.conf specifies to use the
single-threaded scheduler.

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.


Discuss-gnuradio mailing list
[email protected]

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?

Discuss-gnuradio mailing list
[email protected]

Discuss-gnuradio mailing list
[email protected]

If that file does not exist, GNU Radio 3.6.5 would definitely use the
thread-per-block scheduler; you can try
prior to executing your flow graph from the same shell.

In fact, looking at in, 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”

The default scheduler will be printed.

Best regards,

Hi Nemanja,
I took the liberty of changing the subject to reflect the new topic :slight_smile:

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,

[1] (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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs