玩USRP有几个月了，期间参与了翠翠老师的一个实时应用项目，使用软件仿真多路QAM收发，踩了坑，也涨了知识。由于该项目本身涉及商业公司的知识产权，不便开源，本文章尽可能站在总结的角度说清楚。

1 SDR的蓝图与现实

SDR作为已经火了十几年的概念，设想并实现了很棒的蓝图。其通过基于通用硬件平台的敏捷通信解决方案，迅速降低系统开发成本。SDR把传统在FPGA等硬件上完成的工作，放在PC上，并支持使用Matlab/Simulink、LabView、GNURadio等高级工具进行编程。就拿USRP来说，它支持的软件开发环境就包括UHD驱动层面的C语言开发，以及高阶语言开发(Matlab,Python）。
原本调试周期很长的工作，可以在LabView里迅速得到验证。这一点吸引我从2021年前开始，先后尝试了 N210, B210, X310。通过尝试，在认可这个美好蓝图的同时，也发现，SDR看似简单，想稳定的在现实项目里用起来，是很需要技巧的。

想使用软件功能取代FPGA逻辑的想法很棒，但为了做到一定的带宽(30M以上)、一定的稳定性和精度，采用的软件层面复杂技术丝毫不亚于FPGA，甚至更难调试。

2 上位机配置

USRP几款产品，标称的采样率，都是很理想状态下的采样率。下表是网上总结的各类SDR产品的速率对比。
尽管表上B210可以达到61.44M的带宽，不代表我们就能享用上。首先，不是所有计算机都能满足项目的需要。笔者结合几个月的应用，给出下面的对比表。

• 应用场景采用sc16格式样点吞吐，一个采样点实部+虚部，共4字节。速率测试是使用最简单的连续接收逻辑，不做任何处理。
• 这种只看IO带宽的测试，被多位信号处理专业的工程师认为是没有实际意义的。他们的理由是，即使B210有能力 接收56M的带宽，目前一般CPU也不足以支撑这麽高速的数字信号实时处理。不过笔者还是使用最易于理解的测试方法来进行测试。

上位机CPU	上位机操作系统	USRP板卡	接口	稳定接收速率(M样点/秒)	备注
Raspberry PI 3	Linux 32	B210	USB2.0	2.5
Raspberry PI 4	Linux 32	B210	USB3.0	<8
Intel Core 2 Duo T7100 1,8G	win 7 64	B210	USB3.0	8
Intel Core i5 6500 笔记本	win 7 x64	B210	USB3.0	<10
Intel Core i7 6700	win 10 64	B210	USB3.0	<20
Intel Core i7 6700	Linux 64	B210	USB3.0	<56
Intel Core i7 10700 笔记本	win 10 x64	B210	USB3.0	20
Intel Core i7 10700 笔记本	Linux 64	B210	USB3.0	56	BW 56
Intel Core i7 8700	win Server 2008R2 x64	N210	千兆网	10	MTU 1500
Intel Core i7 8700	win Server 2008R2 x64	N210	千兆网	<20	MTU 4K
Intel Core i7 10700 工作站	win Server 2012 x64	X310	万兆光纤	<80	MTU 1500
Intel Core i7 10700 工作站	win Server 2012 x64	X310	万兆光纤	200	MTU 9K

上表中，<表示在此速率下，10分钟内报丢包数高于0个，低于10个，勉强稳定。转了一圈，有几个体会：

1. 持续接收模式下，recv_frame_size越大（网络版取决于MTU），越省CPU。频繁的接收小包，会迅速耗尽CPU单核资源。
2. 内存分配与释放会大幅降低吞吐能力。建议采用环形缓存器。
3. 即使买了Intel Core i7 10700 工作站，达到最大IO速率，后续落盘或者处理也很成问题。以B210为例，对56M的带宽长时间整体存盘，由于1个样点4字节，实际的落盘速率大于200MB/s，不用固态盘或者RAID，是来不及的。
4. 滤波或者变换，在CPU上都很昂贵。一旦进行进一步的运算，最大速率的瓶颈就不是IO，而是算法了。USRP官方的例子，基本也都是处理1M量级的数字波形。
5. X雷下载、网页视频、杀毒软件，都会降低网络接口的速率，有时是显著降低。

综上，我心中的下一台上位机：

• CPU: Intel i9 10代
• 内存：DDR4 4GHz以上
• 硬盘：M2 固态 2TB

2 操作系统因素

尽管Windows下，有Pothos SDR等一揽子方案开箱即用，但经过测试，无奈的发现同样级别的配置，Linux的吞吐能力几乎是Windows的2倍。笔者没有真正扎下去研究为什么有如此大的性能差异。理论上，这是不可能发生的：无论win还是Linux，运用的都是同样的硬件——但这的确发生了。另一个附带的发现，是近2-3年来，我发现Linux下的windows虚拟机要比windows下的Linux虚拟化突然快的多。

目前猜测：

1. windows下的杀毒软件和各种商业软件显著消耗了宝贵的CPU资源。
2. 近期针对CPU预测-缓存安全机质的补丁显著降低了win的效率。Linus 拒绝了类似Snoop （CVE-2020-0550）这样的补丁进入Linux内核，使得Linux操作系统的性能没有因此受到损失。

从实践来看，尽可能使用Linux x64作为操作系统，可以显著降低软件配置手续，确保性能。如果非要使用Windows，则需要谨慎的评估性能。目前已知的问题有：

1. 设计不佳的杀毒软件/防火墙会大幅度降低系统性能。
2. 远程桌面模式会降低 GQRX等软件的稳定性。
3. 电源管理，尤其是处理器节能模式会显著降低吞吐效率。

建议：

• Linux 64 位操作系统

3 网络接口与MTU

网络接口对N210, X310等网口机型很关键。尤其是MTU，这个东西非常讨厌，是个矛盾。
MTU是网卡的最大传输单元，表示了一个IP包的最大长度。超过这个长度，就会分片。RFNoC是USRP的片上网络，它希望UDP不发生分片，因此MTU决定了一个UDP包的最大大小。

1. 在PC读取数据时，MTU越大，同样大小的数据拆分的包就越少，CPU就越空闲。特别对于光纤，9000字节的MTU可以挑战200M的带宽，1500的就不行。
2. 在PC发射数据时，MTU越小，延迟越小。当要保证低延迟时，MTU就不能设置太大。

可以详细参考
https://files.ettus.com/manual/page_transport.html

建议:
不使用千兆网卡版本，如N210。可采用B210+高精度时钟+GPS的方式，最稳定。如果公司有钱，可以直接上X310。

4 开发建议

比起把数据保存到磁盘上，在PC上的信号处理才是大多数工程师真正关心的。不幸的是，经过测试即便有SIMD加速的VOLK库支持，GNURadio的带宽也是捉襟见肘的。品类繁多的软件工具，主要面向的是中低速率的算法验证，而不是高速信号处理。很难想象，用Matlab做一个50M带宽的实时信号解调。
想象一下，当你花了20000大洋，买了i9的超级工作站，可以把B210或者X310的全部带宽榨干时，却发现除显示一下频谱，采集原始信号到固态磁盘之外，啥都干不了，该如何是好？

实时进入PC的数据流，是对软件能力的绝对考验。最简单的，面对一个200K的调频广播时，用2M采样率可以收听，用200M就死机——数字DDC根本无法实时完成从200MHz到200KHz的降采样与滤波。

为了达到原本设定的指标，需要发挥各种想象力。

4.1 直接从底层开发

无论是Matlab还是GNURadio，嵌套的层级都过多。要尽量挑战极限，只能走向底层。
最简单的道理，如果能够在FPGA内调制解调，网络带宽开销可以降低32倍以上。在FPGA滤波，CPU就被大大解放了。

4.2 并行、异构计算

把滤波、相关、解调等工作放到集群或者GPU里。

• OpenMP/SIMD单机CPU并行+流水
• GPU异构并行
• MPI等集群并行化
  并行计算的思路就是把数据攒够了，切成一块块的Map到节点上计算，而后Reduce到一起输出。为了降低吞吐开销，一般颗粒度都较大。颗粒度大，意味着很大的延迟——不缓存几秒的数据，都不好意思发起一次交换。

延迟几秒对于看电视来说，无所谓，但对于高速双向通信，需要额外的考虑。

5 正确的评估

1. 用于双向高速通信算法验证
   如果是为了设计20-30MBd以上速率的高速双向通信，SDR还是作为一种算法验证工具比较合适。如果没有决心动FPGA内部的逻辑，只是准备在PC上做信号处理，就要当心并行计算造成的延迟。

2.可以作为高速信号源
如果只是发射，事先把信号产生好了，存在固态磁盘，则可以挑战IO极限。一般好的机器，用B210到50MBd是没有问题的。

3.用于中低速率的原型开发
很棒。这个东西非常适合中低速率的原型系统开发。

cs