I'm doing a scenario where there is 1 route at the beginning and then it splits into 3, then merges into 1 again. I'm stopping the car in the first lane, the second car stops also, the third one reroutes in the middle lane, the fourth goes to the queue, the fifth reroutes, the sixth goes to the queue, the seventh reroutes.....why is it behaving like that? I can't understand where to change this "balancing" or "threshold". Any suggestion?
The Veins 4.6 sample application behaves as follows:
if a vehicle is stopped (and has been driving) and has not yet sent a warning message, it sends a message containing its current road (TraCIDemo11p.cc, line 82)
if a vehicle receives a warning message, it tries to find a new route through the road network that avoids this road (TraCIDemo11p.cc, line 48); in addition, if it has not yet sent a warning message, it re-sends the received message (TraCIDemo11p.cc, line 54)
So, if you use this sample application and observe that some vehicles do not change their route, this can be attributed (among others) to either of the following effects:
they never received a message that told them about the congestion
they received a message, but couldn't find a route through the road network that would avoid the congestion
Why a vehicle did not receive a message can again be attributed (among others) to any of the following:
a warning message was transmitted to them, but they could not receive it (e.g., due to interference)
a warning message was transmitted through the network before they started their trip (remember, warning messages are not repeated by the example application)
Related
I am doing some simulations using the Veins framework (with the RSU scenario). I defined two accidents for node[*0] as shown in the code below. However, node[*0] sends WSM message to neighboring nodes (i.e., vehicles and RSU) only for the first accident. When it arrives to the second accident, it stops for a while but does not send any message. I further tested this by scheduling more accidents, but the message is still sent/broadcasted only for the first accident. My question is, why node[*0] is not sending WSM message when it arrives to each of the other scheduled accidents? I would greatly appreciate it if someone could help me clarifying this issue. Thank you.
*.node[*0].veinsmobility.accidentCount = 2
*.node[*0].veinsmobility.accidentStart = 60s
*.node[*0].veinsmobility.accidentDuration = 40s
*.node[*0].veinsmobility.accidentInterval = 70s
The application used in the Veins example simulation is https://github.com/sommer/veins/blob/veins-5.2/src/veins/modules/application/traci/TraCIDemo11p.cc#L96. As you can see, it uses a bool member to track whether it has already sent a message and, if it has, refuses to send another.
I'm the newbie in etcd and have some confusion points about log replication:
For example, leader send out {term:2,index:3} and then {term:2,index:4}, the majority respond in order too. But due to network delay, leader receive the responses out of order, receive response of {term:2,index:4} first.
How etcd handle such case? It seems like just ignore the log {term:2,index:3}, commit {term:2,index:4} directly.
func (pr *Progress) MaybeUpdate(n uint64) bool {
var updated bool
if pr.Match < n {
pr.Match = n
updated = true
pr.ProbeAcked()
}
pr.Next = max(pr.Next, n+1)
return updated
}
How etcd retry when response packet(e.g. resp of {term:2,index:3}) loss happen? I can't find any code snippet to handle this in the etcd project.
Questions you asked are more raft than etcd related (etcd implements raft, so they are still relevant tho). To get high level understanding of raft algorithm I highly recommend you to to check out raft webpage and raft paper (it's really nicely written!). I believe that section 5.3 "Log replication" would be helpful.
First let's put some foundation: Leader keeps track of matching entries with every follower. It keeps information in nextIndex[] and matchIndex[] in the paper (check Fig. 2) and in ProgressMap in etcd.
// ProgressMap is a map of *Progress.
type ProgressMap map[uint64]*Progress
type Progress struct {
Match, Next uint64
...
}
Now let's jump to your questions.
For example, leader send out {term:2,index:3} and then {term:2,index:4}, the majority respond in order too. But due to network delay, leader receive the responses out of order, receive response of {term:2,index:4} first. How etcd handle such case? It seems like just ignore the log {term:2,index:3}, commit {term:2,index:4} directly.
Here all depends on state of the follower (from leader perspective). Let's dive into StateProbe and StateReplicate.
In StateProbe leader tries to figure out which entries it should send to the follower. It sends one message at the time and waits for response (which might be reject response in which case leader have to decrease Next related to this follower and retry). In this state sending 2 different MsgApp to the same follower is not possible.
In StateReplicate leader assumes that network is stable and sends (potentially) many MsgApp messages. Let's work on example.
Match := 2, Next := 2
Follower log : [E1, E2] (E stands for "entry")
Leader log: [E1, E2]
In this state leader gets put request for entries E3, E4 and E5. Let's assume that max batch size is 2 and thus all new entries can't be send in single message. Leader will send 2 messages: (Index: 3, Entries: [E3, E4]) and (Index: 5, Entries: [E5]). Second message will be send before ack for first one is obtained. In case in the picture, follower gets first message, checks if it can append it by using Index from request (check is performed in (raft).handleAppendEntries > (raftLog).maybeAppend > (raftLog).matchTerm > (raftLog).term), appends entries to it's log and sends ack. Later on, follower gets 2nd request and does the same for it (checks if it can append it and sends ack).
Fact that follower checks if it can append entries before sending ack is important here. Once leader get ack for any message it is sure that all entries up to Index + len(Entries) are populated in follower's log (otherwise this message would be rejected instead of acked). Thanks to that, it is not important if first ack is delayed (or even lost).
How etcd retry when response packet(e.g. resp of {term:2,index:3}) loss happen? I can't find any code snippet to handle this in the etcd project.
I'll focus on etcd now as in raft paper it is described as "the leader retries AppendEntries RPCs indefinitely", which is rather non constructive. Every short interval, leader sends MsgHeartbeat to the follower and latter responds with MsgHeartbeatResp. As part of MsgHeartbeatResp handling, leader does following
if pr.Match < r.raftLog.lastIndex() {
r.sendAppend(m.From)
}
Which should be read as: "If there is any entry that is not present on the follower, send him first missing entry". This can be seen as retry mechanism as pr.Match will not increase without ack from follower.
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.
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:
Compile in release mode: make MODE=Release
Run your simulation in the terminal environment Cmdenv: ./run -u Cmdenv ...
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.
Removing the simtime-resolution parameter from the omnetpp.ini file solves the problem.
It seems the simulation kernel has an issue when the channel delay does not match the simulation-time resolution.
You can verify the solution by cloning the following repository. Note that you need a functional installation of the OMNeT++ framework. Specifically, I test this fix in OMNeT++ 5.6.2.
https://github.com/Ryuuba/flooding
I used veins 4a2 and OMNET++ (4.6). I like to know the content of messages exchanged between vehicles in the veins example.
I have consulted waveshortmessage.msg, WaveShortMessage_m.cc and WaveShortMessage_m.h but I have not found messages content.
In waveshortmessage.msg, what means this line "string wsmData = "Some Data"" please?
And in TraCIDemp11p.cc, what means "blockedRoadId" declared in sendMessage function?
The demo application that comes with Veins 4.4 (and 4a2 as well) and that is used for the Veins tutorial reacts to messages that contain the name of a road to avoid because a car has stopped there for longer than 10s (and vice versa: the demo application sends a message when a car is stopped for longer than 10s).
The demo application is defined in TraCIDemo11p. It uses a demo message type, WaveShortMessage, as the container to inform other cars about a blocked road. For this, it stores the name of the blocked road (variable blockedRoadId) in the wsmData field of the message.
I am a developer, working on "Telit" GE865-Quad using AT commands.
I am planning an application, witch sends SMS when certain condition occurs. When the application does not send SMS the modem is shut-down (Therefore every time I want to send SMS I have to turn on the modem). This application sends 3 SMS to different numbers one after the other.
The application is working just fine. The problem apear after a while (after sending certain amount of SMS), when I give the command to send SMS I get "+CMS ERROR 41" ("Temporary failure"). Once this message appear, every time I try to send SMS I get the same ERROR - It is like the SIM card is stuck. The only way I have found to get rid of this error is to enter the SIM card to my privet phone and send SMS.
I have spoken to "Telit" representative and he could not give a satisfying answer other then adding more delay between messages.
This is some of the relevant code :
(Turning on sequence) // From "Telit" GE865-Quad DataSheet
> #QSS: 3 //Before I start working with the modem i wait for this response with means the SIM is ready to use and the registration is to cellular network is complete*/
AT+CMGF=1 // Text Mode
OK
AT+CMGS=+xxxxxxxxxxxx // My number.
"This is the message i want to send" //Preparing the desired message require some coding But I think this is irrelevant to the subject.
//Delay for 3 secs//
And again : AT+CMGS=+xxxxxxxxxxxx // My number.
"This is the message I want to send"
//Delay for 3 secs//
(The same thing one more time)
The questions are:
Why does it happen, what am I doing wrong??
How can I unblock the SIM? What does the phone do so I can keep sending SMS?
The purpose is the keep sending SMS automatically.
This is the first time I publish a message in this website so if something is unclear please let me know. :)
Thanks for all the helpers.
Itay.
today i encountered this +CMS ERROR: 41 error, many times.
There was about 40 unread messages in the receiving modem.
After i deleted all received messages error disappeared.
I think may be operator is protecting customers from spam.
Dmitri
It is due Either SMS service on your SIM is not available or your SMS subscription is expired.