0

I am using the USRP N210 through a Debian (4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1) VM and run very quickly into processing overflow. GnuRadio-Companion is printing the letter "D" the moment one of the CPUs load is reaching 100 %. This was tested by increasing the number of taps for a low-pass filter, as shown in the picture with a sampling rate of 6.25 MHz.

I have done all instructions on How to tune an USRP, except the CPU governor. This is because I am not able to do this due to a missing driver reported by cpufreq-info. The exact output is

No or unknown cpufreq driver is active on this CPU.

The output of the lscpu command is also shown in a picture.

Has anyone an idea how I can resolve the problem? Or is GnuRadio just not fully supported for VMs?

enter image description here

enter image description here

enter image description here

ben
  • 207
  • 1
  • 10

1 Answers1

1

Dropping packets when your CPU can't keep up is expected. It's the direct effect of that.

The problem is most likely to be not within your VM, but with the virtualizer.

Virtualization adds some overhead, and whilst modern virtualizers have gotten pretty good at it, you're requesting that

  • an application with hard real-time requirements runs
  • under high network load.

This might take away CPU cycles on your host side that your VM doesn't even know of – your 100% is less than it looks!

So, first of all, make sure your virtualizer does as little things with the network traffic as possible. Especially, no NAT, but best-case hardware bridging.

Then, the freq-xlating FIR definitely isn't the highest-performing block. Try using a rotator instead, followed by an FFT FIR. In your case, let that FIR decimate by a factor of 2 – you've done enough low-pass filtering to reduce the sampling rate without getting aliases.

Lastly, might be a good idea to use a newer version of GNU Radio. In Debian testing, apt will get you a 3.8 release series GNU Radio.

Marcus Müller
  • 34,677
  • 4
  • 53
  • 94
  • Thank you for support. I have only used freq-xlating FIR as an example to demonstrate how quickly I run into packet drops. The main processing, i.e. QPSK demodulator + encoder has not happened yet. I therefore consider moving the filtering and demodulator onto the FPGA. Assume I move into a native Linux OS, do you think filtering + QPSK demodulation with sampling rates > 10 MHz are feasible, or do I still run into similar issues? – ben Jan 17 '20 at 11:37
  • moving to an FPGA would be total overkill and take weeks to months, don't. These rates are completely unproblematic on modern PCs. – Marcus Müller Jan 17 '20 at 11:44
  • Well, Mathworks support tools such as HDL Coder and a package for AD3971, which is used in SDRs such as E310/E320. Aren't they supposed to be good for rapid development? What is your definition of a "modern PC", e.g. in terms of CPU and memory, and where do you see the limits? – ben Jan 17 '20 at 15:26
  • I've done this on business laptops in 2019. So, a somewhat modern PC. Honestly, your PC should work. – Marcus Müller Jan 17 '20 at 15:27