That is what it seems like... https://pasteboard.co/JvGuqC7.png
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 <[email protected]> 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 <[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]>> 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 >> > > >> > >> >
