如果 Vehicles 和 RSU 都定期广播消息,OMNET++/Veins 模拟会变得很慢吗?
Does an OMNET++ / Veins simulation get very slow if both Vehicles and RSUs broadcast messages periodically?
先简单介绍一下背景:
我有一个场景,其中 RSU 将每隔 TRSU 秒广播一条固定消息“RSUmessage”。我已经为 RSU 广播实施了以下 代码 (此外,这些固定消息的 Psid = -100 以区别于其他消息):
void TraCIDemoRSU11p::handleSelfMsg(cMessage* msg) {
if (WaveShortMessage* wsm = dynamic_cast<WaveShortMessage*>(msg)) {
if(wsm->getPsid()==-100){
sendDown(RSUmessage->dup());
scheduleAt(simTime() + trsu +uniform(0.02, 0.05), RSUmessage);
}
}
else {
BaseWaveApplLayer::handleSelfMsg(wsm);
}
}
汽车可以从其他汽车和 RSU 接收这些消息。 RSU 丢弃从汽车收到的消息。汽车将收到多个此类消息,进行一些比较并定期广播类似类型的消息:'aggregatedMessage' 每间隔 Tcar。 aggregatedMessage 也有 Psid=-100 ,这样消息可以很容易地与其他消息区分开来。
我正在使用自我消息安排汽车活动。 (虽然我相信它可以在 handlePositionUpdate 内部完成)。汽车的handleSelfMsg如下:
void TraCIDemo11p::handleSelfMsg(cMessage* msg) {
if (WaveShortMessage* wsm = dynamic_cast<WaveShortMessage*>(msg)) {
wsm->setSerial(wsm->getSerial() +1);
if (wsm->getPsid() == -100) {
sendDown(aggregatedMessage->dup());
//sendDelayedDown(aggregatedMessage->dup(), simTime()+uniform(0.1,0.5));
scheduleAt(simTime()+tcar+uniform(0.01, 0.05), aggregatedMessage);
}
//send this message on the service channel until the counter is 3 or higher.
//this code only runs when channel switching is enabled
else if (wsm->getSerial() >= 3) {
//stop service advertisements
stopService();
delete(wsm);
}
else {
scheduleAt(simTime()+1, wsm);
}
}
else {
BaseWaveApplLayer::handleSelfMsg(msg);
}
}
问题:使用此设置,模拟非常非常慢。在 OMNET GUI 的快速模式下,我在 5-6 小时或更长时间内获得了大约 50 秒的模拟时间。 (RSU数量:64,车辆数量:40,约1kmx1km地图)
另外,我指的是post。 OP 说他通过在每个 RSU 收到消息后删除消息发送来获得更快的速度。就我而言,我无法删除它,因为我需要在每个间隔后发送广播消息。
问题:我认为这种缓慢是因为每个节点都试图在每个模拟秒的开始发送消息。是不是当所有车辆和节点同时调度和发送消息时OMNET变慢了? (放慢速度是有意义的,但减慢到什么程度)但是,模拟中总共只有大约 100 个节点。当然不可能这么慢。
我试过的方法:我尝试使用 sendDelayedDown(wsm->dup(), simTime()+uniform(0.1,0.5));
将消息的发送分散到 1st 的一半每个模拟秒。这似乎停止了在每个模拟秒开始时堆积的消息并加快了速度,但总体上并没有那么快。
任何人都可以告诉我这是正常行为还是我做错了什么。
另外,我很抱歉post。如果不给出上下文,我无法解释我的问题。
您似乎正在用消息淹没您的网络:来自 RSU 的每条消息都会被收到此消息的每辆汽车复制并再次传输。因此,计算时间随着网络中节点(消息发送者)的数量呈二次方增长(每条发送的消息都必须由接收范围内的每个节点处理)。每条消息 3 次传输的限制似乎没有太大帮助,并且如代码中的注释所示,如果没有频道切换,则根本不会使用。
因此,如果您不能 improve/change 您的代码只发送较少的消息,您就必须忍受这一点。您以延迟方式发送消息的小调整只会在一秒钟内分发消息,但不能解决泛洪问题。
但是,您仍然可以遵循一些提示来提高模拟性能:
- 在发布模式下编译:
make MODE=Release
- 运行你在终端环境下的模拟
Cmdenv
:./run -u Cmdenv ...
- 如果一定要使用图形环境,至少应该使用界面上部的滑块来加快动画速度。
从 omnetpp.ini 文件中删除 simtime-resolution
参数可以解决问题。
当通道延迟与模拟时间分辨率不匹配时,模拟内核似乎有问题。
您可以通过克隆以下存储库来验证解决方案。请注意,您需要 OMNeT++ 框架的功能安装。具体来说,我在 OMNeT++ 5.6.2 中测试了这个修复。
先简单介绍一下背景:
我有一个场景,其中 RSU 将每隔 TRSU 秒广播一条固定消息“RSUmessage”。我已经为 RSU 广播实施了以下 代码 (此外,这些固定消息的 Psid = -100 以区别于其他消息):
void TraCIDemoRSU11p::handleSelfMsg(cMessage* msg) {
if (WaveShortMessage* wsm = dynamic_cast<WaveShortMessage*>(msg)) {
if(wsm->getPsid()==-100){
sendDown(RSUmessage->dup());
scheduleAt(simTime() + trsu +uniform(0.02, 0.05), RSUmessage);
}
}
else {
BaseWaveApplLayer::handleSelfMsg(wsm);
}
}
汽车可以从其他汽车和 RSU 接收这些消息。 RSU 丢弃从汽车收到的消息。汽车将收到多个此类消息,进行一些比较并定期广播类似类型的消息:'aggregatedMessage' 每间隔 Tcar。 aggregatedMessage 也有 Psid=-100 ,这样消息可以很容易地与其他消息区分开来。
我正在使用自我消息安排汽车活动。 (虽然我相信它可以在 handlePositionUpdate 内部完成)。汽车的handleSelfMsg如下:
void TraCIDemo11p::handleSelfMsg(cMessage* msg) {
if (WaveShortMessage* wsm = dynamic_cast<WaveShortMessage*>(msg)) {
wsm->setSerial(wsm->getSerial() +1);
if (wsm->getPsid() == -100) {
sendDown(aggregatedMessage->dup());
//sendDelayedDown(aggregatedMessage->dup(), simTime()+uniform(0.1,0.5));
scheduleAt(simTime()+tcar+uniform(0.01, 0.05), aggregatedMessage);
}
//send this message on the service channel until the counter is 3 or higher.
//this code only runs when channel switching is enabled
else if (wsm->getSerial() >= 3) {
//stop service advertisements
stopService();
delete(wsm);
}
else {
scheduleAt(simTime()+1, wsm);
}
}
else {
BaseWaveApplLayer::handleSelfMsg(msg);
}
}
问题:使用此设置,模拟非常非常慢。在 OMNET GUI 的快速模式下,我在 5-6 小时或更长时间内获得了大约 50 秒的模拟时间。 (RSU数量:64,车辆数量:40,约1kmx1km地图)
另外,我指的是
问题:我认为这种缓慢是因为每个节点都试图在每个模拟秒的开始发送消息。是不是当所有车辆和节点同时调度和发送消息时OMNET变慢了? (放慢速度是有意义的,但减慢到什么程度)但是,模拟中总共只有大约 100 个节点。当然不可能这么慢。
我试过的方法:我尝试使用 sendDelayedDown(wsm->dup(), simTime()+uniform(0.1,0.5));
将消息的发送分散到 1st 的一半每个模拟秒。这似乎停止了在每个模拟秒开始时堆积的消息并加快了速度,但总体上并没有那么快。
任何人都可以告诉我这是正常行为还是我做错了什么。
另外,我很抱歉post。如果不给出上下文,我无法解释我的问题。
您似乎正在用消息淹没您的网络:来自 RSU 的每条消息都会被收到此消息的每辆汽车复制并再次传输。因此,计算时间随着网络中节点(消息发送者)的数量呈二次方增长(每条发送的消息都必须由接收范围内的每个节点处理)。每条消息 3 次传输的限制似乎没有太大帮助,并且如代码中的注释所示,如果没有频道切换,则根本不会使用。
因此,如果您不能 improve/change 您的代码只发送较少的消息,您就必须忍受这一点。您以延迟方式发送消息的小调整只会在一秒钟内分发消息,但不能解决泛洪问题。
但是,您仍然可以遵循一些提示来提高模拟性能:
- 在发布模式下编译:
make MODE=Release
- 运行你在终端环境下的模拟
Cmdenv
:./run -u Cmdenv ...
- 如果一定要使用图形环境,至少应该使用界面上部的滑块来加快动画速度。
从 omnetpp.ini 文件中删除 simtime-resolution
参数可以解决问题。
当通道延迟与模拟时间分辨率不匹配时,模拟内核似乎有问题。
您可以通过克隆以下存储库来验证解决方案。请注意,您需要 OMNeT++ 框架的功能安装。具体来说,我在 OMNeT++ 5.6.2 中测试了这个修复。