Schedule Simulator

[ioa...@tcd.ie]

Hello everyone, 

I am currently facing a problem with Simulator::Schedule function in ns3. I have two different implementations/simulations that have some Schedule events to be executed under certain if statements. The goal here is to introduce some delay to my nodes. I've used the form:

Simulator::Schedule(NanoSeconds(), .., ... ) - as seen from previous posts.

I've tried to double check my implementations by using NanoSeconds(0) as the input value in the time that the event should be executed and see if the whole program runs as normal - as without these Schedule events. I use the delay metric for it.

On my surprise, the results where not the same regardless the fact that the "delay" introduced is 0 and the event should be executed immediately. However, I read that if more than one events are to be executed at the same time this may give some misleading results on the execution. Correct? 

I also get different results when I run the two implementations (simulations) side by side with the delay being 0. The results are correct until a certain point but then some other extra values are popped up in one of the implementation's results, hence, I can't get them compared. My id statements are mutually excluded, hence, each of them should be executed once. 

Are there any ideas what may be wrong to this? Honestly, appreciated.

Thanks in advance,

Andriana. 

[Tommaso Pecorella]

Hi,

to be honest only you can define what is "correct" and what is not.

However, it seems that you need a clarification about one point.

You said "if more than one events are to be executed at the same time this may give some misleading results on the execution"

This is NOT correct.

The results are not misleading, they're affected by randomness.

First and foremost, an event is something happening at a given time. In ns-3 (like in 99% of the simulators) the events are simulated by their starting time, and they are executed in zero time. Meaning, if a packet is sent, you have two events (Tx start and Tx end), but when a packet is processed (e.g., IP header is built), this is done in zero time.

If two events happens at the very same time, one of them will be executed before the other. Which one is (somewhat) random.

IF the two event are not disjoint - i.e., if one can modify the status of the system such as the other one execution is affected, then you'll see an (apparent) confusion.

The most common example is: two packets arriving at the very same time.

The problem is: it's the model that should be improved. Two simultaneous events happens, and the model should be robust against it. In the above case, a poorly written model will have one packet received and the other discarded. A correctly implemented model will trash them both. An even more correct model will pick one according to a rule.

If you are using a model which is dependent on the event execution order, even a single event, even with zero delay, can change the simulation.

However... all this should vanish in the big sand of statistics. Meaning, the simulations will be slightly different, but they should be statistically equivalent.

Hope this helps,

T.