Rise and Fall in LogDistancePropagationLoss

[Claudio Ragona]

Hi all,

I'm using the LogDistancePropagationLoss combined with the ConstantSpeedPropagationDelayModel, the only parameters I'm changing during the different simulations is the distance and on the attached picture you can see the result.

What I can't understand is why there are this rise and fall considering that the logarithmic shouldn't be like this. Does someone tell me why?

Thank you,

Claudio

[Tommaso Pecorella]

Hi,

mind checking the plot you posted ?

The axes are TIME (?) Vs Distance (?). I guess there's a mistake.

Moreover, how many bytes have you transmitted to draw the results ? I don't see the confidence bars, so I assume you transmitted at least 10 millions packets per point. Right ?

Cheers,

T.

[Claudio Ragona]

Hi Tommaso,

first of all thank you for your interest!

For what concern the axis you can be right to say that i have to swap them in title, but on the axis labels they are right: on the x-axis there is the distance, while on the y-axis the time

.

About the amount of the data, I'm sending 100 KB at different distances (between 0.5 and 5 meters). So the amount of data still the same on every distance. To understand when i received the desired amount of data there is, on the sink of the receiving device, a counter of packets. When the counter reaches the value corresponding 100KB, I get the time.

In this case the size of the packet is 512 so the number of packets is 196 (Data Amount/Packet Size). When the counter receives 196 packets I get time and with this is the time I used to plot the charts.

I hope this can be useful!

Thank you,

Claudio

[Tommaso Pecorella]

Yo Claudio,

now I understand. You're measuring the e2e delay.

Well, let's do some math.

Increasing the distance you have 3 effects:

1) Longer path. I'd say that the effect on the delay is negligible.

2) Increased path loss, with:

2a) Higher packet drop, and

2b) Lower transmission rates (if you're using ACM).

Point 2a is negligible. In Wi-Fi there's a sharp cut-off, and the probability to "see" a packet retransmission are very low. You could see them but with 200 packets is a matter of sheer luck (or bad luck).

Point 2b is not negligible. With lower Tx rates packets will need more time to be transmitted, and this effect sums up.

Still, the ACM is not perfect, and the channel sensing may be not precise. Hence, you may experience glitches in particular points, i.e., where it is unclear which modcod should be used.

Check examples/wireless/wifi-adhoc.cc

it is a good example, and the data are... very clear.

Hope this helps,

T.

PS: call it Delay, not Time.

[Claudio Ragona]

Hi Tommaso,

thank you for the explanation! I would like to ask another question.

Tell me if I'm wrong, the behaviour is like this because I set the "SetRemoteStationManager" as "AarfWifiManager" which has an adaptive rate control, while if I were to use "IdealWifiManager" it shouldn't have the rise and fall, but just a growth?

Thank you,

Claudio

[Tommaso Pecorella]

Hi,

it should, but I can't guarantee.

Cheers,

T.

[Claudio Ragona]

Hi Tommaso,

I would like to thank you for the help!

In order to be helpful if someone is asking the same question, I can confirm that changing from "AarfWifiManager" to "IdealWifiManager" the results are not having the rise and falls, but a steps growth as in the attached picture.

Claudio