|
From: | Ron Economos |
Subject: | Re: Distributing a gnuradio-flow diagram across multiple cpu's |
Date: | Wed, 14 Oct 2020 18:35:25 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
Your add_blk27 usage seems high. This leads me to believe you may not have run volk_profile.
Run volk_profile in terminal. Since it's measuring timing, preferably without other processes interfering (for example, you should shut down stuff like web browsers and e-mail clients).
You could also use a lower final sample rate. You could pack your FM carriers every 400 kHz, and get away with a sampling rate around 2.4 Msps for five carriers. You could also try 200 kHz spacing, but your FM receiver may not like that.
Ron
That is what it seems like...
This is on i7-4900MQ. I also updated the gnuradio-companion to 3.8.2.0 (Python 3.6.9).
On Thu, Oct 15, 2020 at 1:33 AM Ron Economos <w6rz@comcast.net> wrote:
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 <mueller@kit.edu> 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 <mueller@kit.edu
> <mailto:mueller@kit.edu>> 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
> >
>
[Prev in Thread] | Current Thread | [Next in Thread] |