Search code examples
omnet++veins

Does an OMNET++ / Veins simulation get very slow if both Vehicles and RSUs broadcast messages periodically?


Let me give a brief context first:

I have a scenario where the RSUs will broadcast a fixed message 'RSUmessage' about every TRSU seconds. I have implemented the following code for RSU broadcast (also, these fixed messages have Psid = -100 to differentiate them from others):

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);
    }
}

A car can receive these messages from other cars as well as RSUs. RSUs discard the messages received from cars. The cars will receive multiple such messages, do some comparison stuff and periodically broadcast a similar type of message : 'aggregatedMessage' per interval Tcar. aggregatedMessage also have Psid=-100 ,so that the message can be differentiated from other messages easily.

I am scheduling the car events using self messages. (Though it could have been done inside handlePositionUpdate I believe). The handleSelfMsg of a car is following:

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);
    }
}

PROBLEM: With this setting, the simulation is very very slow. I get about 50 simulation seconds in 5-6 hours or more in Express mode in OMNET GUI. (No. of RSU: 64, Number of Vehicle: 40, around 1kmx1km map)

Also, I am referring to this post. The OP says that he got faster speed by removing the sending of message after each RSU received a message. In my case I cannot remove that, because I need to send out the broadcast messages after each interval.

Question: I think that this slowness is because every node is trying to sendDown messages at the beginning of each simulated second. Is it the case that when all vehicles and nodes schedules and sends message at the same time OMNET slows down? (Makes sense to slow down , but by what degree) But, there are only around 100 nodes overall in the simulation. Surely it cannot be this slow.

What I tried : I tried using sendDelayedDown(wsm->dup(), simTime()+uniform(0.1,0.5)); to spread the sending of the messages through out 1st half of each simulated second. This seems to stop messages piling up at the beginning of each simulation seconds and sped things up a bit, but not so much overall.

Can anybody please let me know if this is normal behavior or whether I am doing something wrong.

Also I apologize for the long post. I could not explain my problem without giving the context.


Solution

  • It seems you are flooding your network with messages: Every message from an RSU gets duplicated and transmitted again by every Car which has received this message. Hence, the computational time increases quadratically with the number of nodes (sender of messages) in your network (every sent message has to be handled by every node which is in range to receive it). The limit of 3 transmissions per message does not seem to help much and, as the comment in the code indicates, is not used at all, if there is no channel switching.

    Therefore, if you can not improve/change your code to simply send less messages, you have to live with that. Your little tweak to send the messages in a delayed manner only distributes the messages over one second but does not solve the problem of flooding.

    However, there are still some hints you can follow to improve the performance of your simulation:

    1. Compile in release mode: make MODE=Release
    2. Run your simulation in the terminal environment Cmdenv: ./run -u Cmdenv ...
    3. If you need to use the graphical environment by all means, you should at least speed up the animations by using the slider in the upper part of the interface.