我一直在使用 Ubuntu 记录来自 SDR 的数据并处理收集到的数据以进行射电天文观测。我可以收集的最大采样率是 56 M 个样本/秒（sdr 的限制），但在 Ubuntu 端使用自制软件（Ubuntu 16）没有问题。为了跟上其他更新，几年前我转移到了 Ubuntu 18，情况仍然可以接受，但不时出现一些故障并出现溢出指示。数据通过 USB 3.0 接收，溢出表示软件速度不够快。上述情况直到 Ubuntu 18 的最新更新才得到证实，其中（如果我没记错的话）内核与 Ubuntu 20 的版本一致，之后我不得不将输入速率降低到与之前相比的中间水平，但仍然不确定要持续多长时间。我试图转移到真正的 Ubuntu 20，但情况是一样的，数据立即丢失，有时几分钟后就会丢失。最后的努力是安装低延迟内核，但很难注意到差异或决定哪一个最糟糕。当然，软件完全相同，关键线程具有高优先级。环境是一台塔式 PC，具有 16 GB 内存和 I7 4770 CPU。最后（希望出现奇迹）我将整个环境移到了一台笔记本电脑上，该笔记本电脑也具有 16 GB 内存，运行速度为 2.6GHz，配备第 10 代 CPU（I 10875h），在基准测试方面，其性能比塔式 PC 好得多，但不符合我的需求。任何建议都将不胜感激。
编辑 补充问题：该应用程序是在 QT 环境中制作的，其中 GUI 仅用于插入一些参数，目标是进行针对天文观测（脉冲星检测）的数据记录，每个记录变量为 1 到 4-5 小时。数据带宽尽可能大非常重要。作为接收器，我使用 Ettus sdr 接收器，其最大带宽为 56Mhz，频率约为 1300Mhz。实时过程包括：
从 sdr 接收数据块（浮点 I/Q 样本）
应用 RFI 缓解过程（时间域）
将 FFT 传递到频域
在频域中应用 RFI 缓解措施
减少数据
将数据写入磁盘以进行后期处理
该软件由以下层组成：
库 USB
Ettus 研究接口到接口硬件
用户实时线程作为 Ettus 和其余应用程序之间的接口
其余功能的线程
一个大的缓冲池来传递数据并吸收不同层之间的延迟
编辑据新闻报道，我已经应用了Doug 建议的修改，第一印象是塔式 PC 有了明显的改进（有待确认），笔记本电脑上几乎没有变化，在我看来，系统无法利用潜在的 CPU 能力。在塔式机上，我可以进行 1 小时的无问题录制（然后由于时间不够而停止），监控（htop）活动 CPU 使用率为 200%（不管它是什么意思）并且 CPU 风扇以最大速度运行。在笔记本电脑上，CPU 在低于 100% 的几秒钟内参与工作，风扇非常安静。我非常想将整个环境转移到笔记本电脑上，因为塔式机产生了很多射频干扰，而笔记本电脑则安静得多。
测试结果更新：
首先我必须自我反驳，我昨天说的是一个幸运事件的结果，事实是没有发生任何改变。似乎存在某种偶然的同步、共振……随便你怎么称呼它，看起来似乎更好，但却是牺牲品。笔记本电脑在任何情况下似乎都是最糟糕的，实际上我不得不降低传输速率才能看到正常行为。为了减少变量，以下测试是在终端（无 GUI）上以高优先级运行的单线程应用程序上进行的，该应用程序仅包含一个从较低层接收缓冲区的循环。循环在第一次出现错误时中断。我想说，我并不是唯一一个遭受这个问题困扰的人，我的一个朋友在只有一台塔式 PC 上使用我的软件，但比我的更新、更强大，也观察到了同样的性能下降。以下是结果，就我所见，它看起来像是服务中断的延迟，两台机器的不同行为非常奇怪。塔式机的 CPU 负载更大，而 CPU 频率更低，而笔记本电脑的 CPU 负载很小，但时钟频率很高???。
塔式机和笔记本，所有 CPU 均相同：
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:intel_pstate
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:powersave
Turbostat 结果以图片形式包含以保存格式：
----------------------------------------------------------------------------------------------
以下是强制 CPU 亲和性的结果，我们放置的不只是一个线程（我的），还有底层添加的线程（不受我的控制），不确定测试是否说明了有用的东西。遗憾的是，我们只能在进程级别应用任务集，也可以在多个进程中组织我的应用程序，但有一个很大的相反迹象。虽然现在通过传递缓冲区地址来解决了底层线程通信，在进程强制中分割路径以对整个数据流进行物理复制（几次）。我不相信这可能是一个解决方案。无论如何，让我们忘掉笔记本电脑吧，这是一个新条目，但塔式机以 56Mhz 的速度运行，无法想象问题可能出在哪里。
笔记本电脑截断 turbostat 跟踪 12 秒周期，在 1436263 个块后以 50 Msamples/sec 溢出
Busy% Bzy_MHz IRQ PkgTmp PkgWatt GFXWatt
0.64 950 2296 36 1.23 0.00
0.60 2109 16518 47 2.11 0.01
1.68 1973 38821 38 2.65 0.00
0.80 3059 47123 36 2.79 0.00
1.32 3511 87392 37 4.35 0.01
1.61 3643 112790 52 5.27 0.01
1.17 4049 98914 38 4.73 0.00
0.45 1644 10524 37 1.47 0.01
1.49 4118 116907 38 5.56 0.00
0.14 1210 2034 38 1.18 0.00
0.18 1253 3324 38 1.19 0.00
0.13 948 2039 37 1.16 0.00
4.47 2304 41744 39 5.44 0.12
3.94 2501 34164 39 5.42 0.09
1.41 1046 12146 39 1.45 0.02
7.49 4243 35073 43 21.15 0.12
0.59 1499 11795 40 1.50 0.01
3.16 4407 307462 52 12.31 0.00
3.08 4448 322628 52 12.70 0.00
3.08 4452 322723 53 12.74 0.00
3.09 4448 322486 55 12.79 0.00
3.10 4445 323027 54 12.84 0.00
3.11 4433 323140 55 12.86 0.00
3.09 4449 322441 55 12.90 0.00
塔式机无法以 56MSamples/sec 的速度启动（与笔记本电脑相同），但在 50 时显然更稳定，我截断了轨迹
Busy% Bzy_MHz IRQ PkgTmp PkgWatt GFXWatt
2.70 1697 13945 47 5.96 0.14
1.30 905 10912 47 4.97 0.01
1.16 1955 17087 47 5.37 0.00
1.51 1811 16188 47 5.45 0.01
0.66 1747 7617 49 5.04 0.01
0.51 1499 5610 47 4.93 0.01
0.64 1776 9768 47 5.05 0.01
0.75 1787 10124 46 5.11 0.01
0.51 1374 4429 46 4.91 0.01
6.84 2817 35616 56 10.97 0.09
1.28 2292 5767 47 5.67 0.04
9.17 3676 17492 58 16.31 0.03
8.94 3844 13878 49 17.17 0.01
1.01 2418 5657 48 5.42 0.03
4.00 2635 112623 50 7.58 0.01
9.67 2478 324416 50 10.99 0.00
9.61 2405 324033 49 10.62 0.00
9.61 2402 323596 49 10.61 0.00
9.61 2401 323673 50 10.61 0.00
9.61 2427 324656 52 10.79 0.00
9.62 2402 323771 52 10.62 0.00
9.60 2406 323753 51 10.62 0.00
9.59 2409 324019 51 10.63 0.00
9.60 2406 324158 51 10.63 0.00
9.67 2414 325071 52 10.75 0.00
9.60 2404 323809 51 10.62 0.00
9.60 2406 324026 52 10.62 0.00
9.59 2411 324270 51 10.63 0.00
9.61 2412 324178 50 10.64 0.00
9.47 2470 324716 51 11.08 0.00
9.60 2407 324097 52 10.63 0.00
9.59 2410 324167 51 10.63 0.00
9.59 2406 323637 52 10.62 0.00
10.34 2431 329152 53 11.19 0.13
10.17 2419 329791 51 11.00 0.03
南多