为什么 NDM‑TCP 测试是单次运行快照（而非统计平均）

Source: Dev.to

关于测试哲学和实际约束的3分钟阅读

现实检查

让我对社区保持透明：这是我在备考期间进行的个人兴趣项目。作为一名时间和硬件有限的独立开发者，我刻意选择进行延长的 40 秒“压力测试快照”，而不是遵循传统的科学方法进行 50–100 次试验并取平均值。

这并不理想——但它诚实，这就是我这样做的原因。

我所面临的约束

时间限制

对每一个测试场景进行多次试验需要数十小时的时间，而我目前根本没有这么多时间。随着考试临近且这只是一个副项目，我必须在广度和统计深度之间做出取舍——即对许多不同的场景各进行一次测试，而不是对单一场景进行多次重复。

硬件现实

我只在一台笔记本电脑上使用 VMware 进行测试，而不是在多节点硬件实验室里。这是我唯一能使用的资源，我只能在此范围内工作。

软件挑战

我当前的 iperf3 构建（通过 apt 安装）在连接外部服务器时会出现核心转储崩溃。这迫使我暂时只能使用本地 tc（流量控制）模拟。若要从源码编译以修复此问题，会增加我目前没有精力处理的复杂度。

要想真正测试现实条件（WiFi、以太网），理想情况下我需要：

• 一台设备作为服务器，连接到 WiFi/以太网
• 另一台设备作为接收端

而目前我没有多台设备可用于此类设置。

哲学：拥抱混沌而非可重复性

为什么真正的随机性很重要

一些研究者偏好“固定种子”的可重复性，即每次测试运行时随机噪声完全相同。这可以让结果完美可复现，但它并不反映现实。

在真实世界中，网络状况从未出现两次完全相同的情况。 你永远不会遇到完全相同的抖动和丢包序列。NDM‑TCP 的设计目标是处理意外情况——适应生产环境中出现的独特且不可预测的网络压力“雪花”。

伪随机生成的局限性

大多数计算机无法产生真正的随机数——它们使用伪随机数生成器。若要实现准确的可重复性，你需要：

• 使用带种子的伪随机生成器（这样相同的序列会被重现）

tc 工具并未轻易暴露这些控制，因此每次测试运行都会遇到真正不同的随机条件。这意味着：

• ✅ 更真实（模拟现实世界的不可预测性）
• ❌ 可复现性更低（无法保证条件完全相同）

我把这视为一种特性，而非缺陷。NDM‑TCP 需要证明它能够应对网络抛出的任何情况，而不仅仅是一条精心控制的序列。

为什么我需要社区支持

现实是：**由于这些限制，我无法对每个场景进行 50–200 次测试。**这正是我请求社区支持的原因。

这始于一次疯狂的实验

NDM‑TCP 实际上来源于我之前的另一项疯狂实验，叫做 NDM（神经微分流形）。我从那个实验中汲取概念，并想：“如果这样会怎样？”

我进行了测试，结果可行。结果显示出希望。

但最重要的是：

如果 NDM‑TCP 真正有效——如果它能够比基于 tc 的本地主机模拟更好地处理真实网络和真实硬件——那么它可能解决网络今天仍面临的许多老问题：

• 处理不可预测的丢包模式
• 适应快速的 RTT 变化
• 在压力下保持公平性
• 在混乱条件下减少重传

从本地主机到真实世界

这些使用 tc 的本地主机测试仅仅是个开始。如果这种方法在以下情况下被证明有效：

• 真正的网络硬件（实际的 WiFi/Ethernet 连接）
• 具有真实拥塞的生产环境
• 多样的网络拓扑

…那么我们可能拥有对所有 TCP 连接都真正有价值的东西。

这就是愿景——也是我需要你帮助进行恰当测试的原因。

社区合作呼吁

这正是你发挥作用的地方。 如果你拥有：

• 一个稳定的 Linux 实验环境
• 比我目前拥有的更多时间
• 多台用于真实环境 WiFi/Ethernet 测试的设备
• 有兴趣进行 50–100 次试验的统计分析

NDM‑TCP 项目是开源的。我很希望在未来的更新中加入社区贡献的数据。你的多次运行统计分析将完美补充我的单次压力测试，为我们双方提供：

• 来自快照的细节和混沌处理证据
• 来自多次运行平均的统计置信度

结束思考

这种测试方法并不完美——它是务实的。我在真实约束下工作，同时努力提供关于 NDM‑TCP 在压力下行为的有价值洞察。

把这些测试视为“现场报告”而非“实验室结果”。它们展示了在一次激烈的网络混乱中实际发生的情况，而不是平均情况。两种视角都有其价值。

想要贡献吗？查看项目仓库并加入讨论。一起，我们可以绘制出 NDM‑TCP 性能的更完整图景。