计算静脉的端到端延迟 [英] Computing End-To-End Delay in Veins
问题描述
我在SO上阅读了很多有关计算静脉中端到端延迟的文章，但是在解释为什么延迟似乎太低的问题上没有找到答案.
我正在使用:
- 静脉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.400239402394 2.39402394E-4
1 186 14.500240403299 2.40403299E-4
2 207 14.600241404069 2.41404069E-4
3 228 14.700242404729 2.42404729E-4
这意味着端到端延迟(从创建到接收)大约等于四分之一毫秒，这似乎非常低-远低于文献中通常报道的水平.这似乎与其他人所报告的问题一致(例如，端到端静脉延迟)
我在计算中缺少什么吗?我曾尝试通过添加大量的车辆节点(在平直高速公路上的1000x50沙箱中，平均速度为50 km/h的21个节点)来增加网络负载，但是结果似乎是相同的.差异可忽略不计.我已经阅读了几篇研究论文，这些研究表明，在高密度的车辆中，端到端的延迟应该大大增加.
这种端到端的延迟是可以预期的.如果您的应用程序的仿真模型没有显式建模处理延迟(例如，通过运行在通用计算机上的应用程序)，则您希望延迟一帧的只是传播延迟(光速，此处可忽略不计)和MAC上的排队延迟. (从将帧插入TX队列到传输完成的时间.)
例如，对于以6 Mbit/s发送的2400位帧，此延迟大约为0.45 ms.您可能会使用较短的帧，因此您的值似乎合理.有关背景信息，请参见F. Klingler，F.Dressler和C.Sommer:高度动态WLAN中线路阻塞的影响" (DOI 10.1109/TVT.2018.2837157 )，其中还包括理论值与静脉值与实际测量值的比较.
I have read a bunch of posts on SO regarding the computation of end-to-end delay in Veins, but have not found an answer to be fulfilling in explaining why the delay is seemingly too low.
I am using:
- Veins 4.7
- Sumo 0.32.0
- Omnetpp 5.3
Channel switching is turned off.
I have the following code, sending a message from the transmitting node:
if(sendMessage) {
WaveShortMessage* wsm = new WaveShortMessage();
sendDown(wsm);
}
The receiving node computes the delay using the wsm creation time, but I have also tried setting the timestamp on the transmitting side. The result is the same.
simtime_t delay = simTime() - wsm -> getCreationTime();
delayVector.record(delay);
The sample output for the delay vector is as follows:
Item# Event# Time Value
0 165 14.400239402394 2.39402394E-4
1 186 14.500240403299 2.40403299E-4
2 207 14.600241404069 2.41404069E-4
3 228 14.700242404729 2.42404729E-4
Which means that the end-to-end delay (from creation to reception) is equivalent to roughly a quarter of a millisecond, which seems to be quite low - and a fair bit below what is typically reported in the literature. This seems to be consistent with what other people have reported as being an issue (e.g. end to end delay in Veins)
Am I missing something in this computation? I have tried adding load on the network by adding a high number of vehicular nodes (21 nodes within a 1000x50 sandbox on a straight highway, with an average speed of 50 km/h), but the result seems to be the same. The difference is negligible. I have read several research papers that suggest that end-to-end delay should increase dramatically in high vehicular densities.
This end-to-end delay is to be expected. If your application's simulation model does not explicitly model processing delay (e.g., by an application running on a slow general purpose computer), all you would expect to delay a frame is propagation delay (lightspeed, so negligible here) and queueing delay on the MAC (time from inserting frame into TX queue until transmission finishes).
To give an example, for a 2400 bit frame sent at 6 Mbit/s this delay is roughly 0.45 ms. You are likely using slightly shorter frames, so your values appear to be reasonable.
For background information, see F. Klingler, F. Dressler, C. Sommer: "The Impact of Head of Line Blocking in Highly Dynamic WLANs" (DOI 10.1109/TVT.2018.2837157), which also includes a comparison of theory vs. Veins vs. real measurements.
这篇关于计算静脉的端到端延迟的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
