Omnet++ 静脉中端到端延迟的计算

我读过很多关于静脉中端到端延迟计算的帖子，但是没有找到一个答案来解释为什么延迟看起来太低

我正在使用：

• 静脉4.7
• 相扑0.32.0
• Omnetpp 5.3

频道切换已关闭

我有以下代码，从发送节点发送消息：

if(sendMessage) {
  WaveShortMessage* wsm = new WaveShortMessage();
  sendDown(wsm);
}

接收节点使用wsm创建时间计算延迟，但我也尝试在发送端设置时间戳。结果是一样的

simtime_t delay = simTime() - wsm -> getCreationTime();
delayVector.record(delay);

延迟向量的样本输出如下所示：

项目#事件#时间值
0 165 14.40023940239402394E-4
118614.500240403299 2.40403299E-4
220714.6002414040069 2.41404069E-4
3228 14.700242404729 2.42404729E-4

这意味着端到端延迟（从创建到接收）大约相当于四分之一毫秒，这似乎相当低，并且比文献中通常报道的要低一点。这似乎与其他人报告的问题一致（例如）

---

我在计算中遗漏了什么吗？我曾尝试通过添加大量车辆节点（直线公路上1000x50沙箱中的21个节点，平均速度为50 km/h）来增加网络负载，但结果似乎是一样的。差别可以忽略不计。我读过几篇研究论文，这些论文表明，在高车辆密度情况下，端到端延迟应该会显著增加。

这种端到端延迟是可以预料的。如果您的应用程序的模拟模型没有明确地建模处理延迟（例如，由运行在速度较慢的通用计算机上的应用程序），那么您所期望的帧延迟就是传播延迟（lightspeed，在这里可以忽略不计）和MAC上的排队延迟（从将帧插入TX队列到传输完成的时间）

举个例子，对于以6 Mbit/s发送的2400位帧，此延迟约为0.45 ms。您可能使用稍短的帧，因此您的值似乎是合理的

---

有关背景信息，请参阅（DOI），其中还包括理论与静脉与实际测量值的比较。

这种端到端延迟是可以预期的。如果您的应用程序的模拟模型没有明确地建模处理延迟（例如，由运行在速度较慢的通用计算机上的应用程序），那么您所期望的帧延迟就是传播延迟（lightspeed，在这里可以忽略不计）和MAC上的排队延迟（从将帧插入TX队列到传输完成的时间）

举个例子，对于以6 Mbit/s发送的2400位帧，此延迟约为0.45 ms。您可能使用稍短的帧，因此您的值似乎是合理的

---

有关背景信息，请参阅（DOI），其中还包括理论与静脉与实际测量值的比较。

这很有意义。谢谢你的回复。因此，在试图解读一些关于端到端延迟的现有文献时，其中报告的数据通常较高（例如），我认为这可能是在高负载和相应的高排队延迟情况下。请注意，您引用的论文的作者没有调查排队延迟。相反，它们报告两个成功接收的数据包之间经过的毫秒数。当然，这种延迟与数据包丢失率成正比——图3和图5中报告的延迟图和PDR图的1:1对应关系也证明了这一点。进一步注意，本研究中的数据包丢失率受到不匹配参数选择的负面影响（尤其是11p部分）：没有重试，以及在完全无线透明的建筑物中具有非常高且不自适应的发射功率和速率。我明白了-这对我来说不是很明显。非常感谢您的澄清！这是有道理的。谢谢你的回复。因此，在试图解读一些关于端到端延迟的现有文献时，其中报告的数据通常较高（例如），我认为这可能是在高负载和相应的高排队延迟情况下。请注意，您引用的论文的作者没有调查排队延迟。相反，它们报告两个成功接收的数据包之间经过的毫秒数。当然，这种延迟与数据包丢失率成正比——图3和图5中报告的延迟图和PDR图的1:1对应关系也证明了这一点。进一步注意，本研究中的数据包丢失率受到不匹配参数选择的负面影响（尤其是11p部分）：没有重试，以及在完全无线透明的建筑物中具有非常高且不自适应的发射功率和速率。我明白了-这对我来说不是很明显。非常感谢您的澄清！