The Rational Resampler uses a lot of CPU cycles. Upgrading to GNU Radio 3.8 won't help.

Ron

On 10/14/20 08:01, Anish Mangal wrote:
Thanks. I'll look at both those points before reverting. :)

On Wed, Oct 14, 2020 at 7:18 PM Marcus Müller <[email protected] <mailto:[email protected]>> wrote:

    again,

    1. outdated GNU Radio. More modern GNU Radio might perform better.
    Updating isn't really optional when you're musing about performance.
    2. actually benchmark where your CPU is going. `htop` is a good
    tool if
    you turn on "thread names" in its settings.

    Best regards,
    Marcus

    On 14/10/2020 15.26, Anish Mangal wrote:
    > Hi Marcus,
    >
    > Thanks for the quick reply. Here's a more complete flow diagram
    that
    > doesn't use the block I mentioned above.
    >
    > https://pasteboard.co/JvBTisO.png
    >
    > This uses up most of my CPU, so I was wondering whether it was
    possible
    > to spread this across multiple distinct computers. I'm sorry,
    that I
    > can't share my most up to date block diagram which uses actual
    audio
    > sources instead of coldplay songs, as it is on another machine
    which I
    > dont have access to at the moment, but this gives a fairly good
    idea
    > about the number of blocks and processing units.
    >
    > Thoughts?
    >
    >
    >
    > On Wed, Oct 14, 2020 at 6:48 PM Marcus Müller <[email protected]
    <mailto:[email protected]>
    > <mailto:[email protected] <mailto:[email protected]>>> wrote:
    >
    >     Hi Anish,
    >
    >     what your subject line says, distributing across CPUs, GNU
    Radio does
    >     automatically.
    >
    >     Across multiple distinct computers, you'll need to add some
    signal
    >     communications between these computers. The ZeroMQ network
    sinks and
    >     sources do that for you.
    >
    >     But honestly, the flow graph you show should use nearly no
    CPU at all.
    >     You should investigate what, in your overall flow graph, not
    just in
    >     the
    >     excerpt you showed, uses up your CPU. This should really not
    be a big
    >     task for your computer.
    >
    >     Also, you're using an outdated version of GNU Radio. Time to
    update!
    >
    >     Best regards,
    >     Marcus
    >
    >     On 14/10/2020 15.07, Anish Mangal wrote:
    >      > Hi, This is my very first post to this mailing list, so
    hello to
    >     all. I
    >      > am a beginner in experimenting with gnuradio and sdr
    >     (hackrf-one). I am
    >      > working on an application where I want to take multiple
    audio input
    >      > sources and transmit multiple FM signals over one RF
    channel via the
    >      > SDR. To this end, I created a basic grc block that looks
    like this:
    >      >
    >      > https://pasteboard.co/JvBGgj5.png
    >      >
    >      > My plan is to have a top level flow diagram using
    multiple such
    >     blocks
    >      > and sum them to produce a composite FM signal through the
    >     hackrf-one.
    >      > With my 4th generation intel i7 CPU, with the hackrf's
    bandwidth
    >     set to
    >      > 6MSPS, I am able to transmit 6 simultaneous fm modulated
    signals. My
    >      > question is this:
    >      >
    >      > Is it possible to spread this task across multiple
    computers. If one
    >      > computer could produce the FM modulated signals, and the
    other
    >     computer
    >      > sum them and transmit via the SDR, the number of simultaneous
    >     streams
    >      > may be increased.
    >      >
    >      > Another approach might be to offload parts of this block
    diagram
    >     to an
    >      > FPGA processing unit.
    >      >
    >      > My challenge is this. I have no experience of working with an
    >     FPGA, and
    >      > limited experience with gnu-radio in general, but I am
    prepared
    >     to put
    >      > in the effort required, however, if someone more
    experienced than
    >     me can
    >      > guide me on the proper approach to go about this, it
    would be very
    >      > helpful. It may be that I just keep all the processing on ONE
    >     powerful
    >      > CPU, and whatever is the max number of simultaneous
    streams I can
    >     get,
    >      > that's it. But if there are cost effective ways of making
    this
    >     design
    >      > more efficient, I'm happy to research and experiment.
    >      >
    >      > 73,
    >      > VU2TVE // Anish
    >      >
    >

Reply via email to