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