Bug 1733

Created attachment 1636 [details]
Graph with the incorrect behaviour

Graph with the incorrect behaviour

Hi Esteban,

a *minor* increase in performance with distance beyond some point could be expected due to the interaction between the propagation delay and the medium access / backoff procedure. 

To investigate this further, I would suggest you to check:

1) the behavior with a constant propagation delay (e.g., you could use RandomPropagationDelayModel and pass a ConstantRandomVariable to it)

2) the behavior with a single packet flow (it seems to me that you have two concurrent flows)

3) (sanity check) verify the actual PHY rates reported in the PCAP trace for a few selected experiments


As for the different "collapse distance" with the DSSS and OFDM rates, I suspect it could be due to your AckTimeout setting being overridden by ConfigureStandard(). I suggest to check this by a look up into the attribute system right before Simulator::Run() is called.

(In reply to comment #2)
> Hi Esteban,
> 
> a *minor* increase in performance with distance beyond some point could be
> expected due to the interaction between the propagation delay and the medium
> access / backoff procedure. 

Hi Baldo

Thanks for your answer. I had no idea about this expected small increase in performance (and seemed to me very strange that only happened with the highest rates)

> 
> To investigate this further, I would suggest you to check:
> 
> 1) the behavior with a constant propagation delay (e.g., you could use
> RandomPropagationDelayModel and pass a ConstantRandomVariable to it)

I have already a constant propagation delay (I am using ConstantSpeedPropagationDelayModel). If I use RandomPropagationDelayModel just like that:

channel.SetPropagationDelay("ns3::RandomPropagationDelayModel", "Variable", StringValue ("ns3::ConstantRandomVariable[Constant=1]"));

the results are very strange (very low performance regardless of the distance)

> 
> 2) the behavior with a single packet flow (it seems to me that you have two
> concurrent flows)

The behaviour of the different collapse distances is the same with 1 flow than with 2 flows

> 
> 3) (sanity check) verify the actual PHY rates reported in the PCAP trace for a
> few selected experiments
> 

I didn't understand this suggestion, sorry 


> 
> As for the different "collapse distance" with the DSSS and OFDM rates, I
> suspect it could be due to your AckTimeout setting being overridden by
> ConfigureStandard(). I suggest to check this by a look up into the attribute
> system right before Simulator::Run() is called.

I have commented the funcion ConfigureStandard() in wifi-mac.cc. But I have follow your advice checking the attribute right before Run() :

          Ptr<NetDevice> n;
  	  Ptr<WifiNetDevice> wd;
  	  n = devices.Get(0);
  	  wd = n->GetObject<WifiNetDevice>();  
  	  std::cout << "SLOT: " << wd->GetMac()->GetAckTimeout() << std::endl;

And the value is always correct (500 us)

Then the concern now is these different "collapse distance", any other suggestion?

(In reply to comment #3)
> (In reply to comment #2)
> > Hi Esteban,
> > 
> > a *minor* increase in performance with distance beyond some point could be
> > expected due to the interaction between the propagation delay and the medium
> > access / backoff procedure. 
> 
> Hi Baldo
> 
> Thanks for your answer. I had no idea about this expected small increase in
> performance (and seemed to me very strange that only happened with the highest
> rates)
> 
> > 
> > To investigate this further, I would suggest you to check:
> > 
> > 1) the behavior with a constant propagation delay (e.g., you could use
> > RandomPropagationDelayModel and pass a ConstantRandomVariable to it)
> 
> I have already a constant propagation delay (I am using
> ConstantSpeedPropagationDelayModel). 

with ConstantSpeedPropagationDelayModel the delay is not constant, it increases linearly with distance.


> If I use RandomPropagationDelayModel just
> like that:
> 
> channel.SetPropagationDelay("ns3::RandomPropagationDelayModel", "Variable",
> StringValue ("ns3::ConstantRandomVariable[Constant=1]"));
> 
> the results are very strange (very low performance regardless of the distance)
> 

ok, this confirm that the performance variations are due to the variations of delay with distance.


> > 
> > 3) (sanity check) verify the actual PHY rates reported in the PCAP trace for a
> > few selected experiments
> > 
> 
> I didn't understand this suggestion, sorry 
> 

I just meant to generate a PCAP file as output, using e.g. RADIOTAP headers, and open it with wireshark to check the PHY rate of each packets. But anyway, since you reported that the performance is constant when delay is constant, I think this sanity check is not needed any more.


> 
> > 
> > As for the different "collapse distance" with the DSSS and OFDM rates, I
> > suspect it could be due to your AckTimeout setting being overridden by
> > ConfigureStandard(). I suggest to check this by a look up into the attribute
> > system right before Simulator::Run() is called.
> 
> I have commented the funcion ConfigureStandard() in wifi-mac.cc. But I have
> follow your advice checking the attribute right before Run() :
> 
>           Ptr<NetDevice> n;
>         Ptr<WifiNetDevice> wd;
>         n = devices.Get(0);
>         wd = n->GetObject<WifiNetDevice>();  
>         std::cout << "SLOT: " << wd->GetMac()->GetAckTimeout() << std::endl;
> 
> And the value is always correct (500 us)
> 
> Then the concern now is these different "collapse distance", any other
> suggestion?

no idea, I suggest just to turn on logging, e.g., for MacLow, and try to understand what's happening.

Created attachment 1646 [details]
Throughput vs Distance with optimized time slot

A strange increase of throughput in long distances for the last three ofdm rates

Hi 

I have some additional information that may be  in relation with the possible bug

I have simulate the same link, variating the distance and observing the throughput, but in this case, leaving an acktimeout quite sufficient to permit normal performance, and setting the optimal slot time for each distance.
This optimal slot time has been calculated through: 

slot=(slot_init-2)+(2*(distance/1000)/0.3); from -> [1]

where slot_init is 9 us
and slot is the current slot time in us for each distance.

I attach a graph where it can be seen an strange behaviour(show a lightly increase of the performance) in the last three OFDM rates: 36, 48 and 54 Ofdm rates. This are the same rates that had the strange behaviour said in https://www.nsnam.org/bugzilla/attachment.cgi?id=1636

Any idea of this behaviour? 
Maybe could be a error in the implementation of those phy rates??



[1] - Modeling and Optimizing IEEE 802.11 DCF for Long-Distance Links Francisco-Javier Simo-Reigadas, Andres Martinez-Fernandez, Francisco-Javier Ramos-Lopez and Joaquin Seoane-Pascual. IEEE Trans. Mobile Computing, vol.9, no.6, pp. 881-896, June 2010

Hi,

What PropagationDelayModel are you using in the last scenario? Are you still using the constant speed one?

Since I'm also working on a kind of "Wi-Fi" long distance scenarios in ns-3, I maybe can help you further on your troubles.

Did you try it in the last ns-3 version (ns-3.18), since the Wifi module has been updated?
Have you made some modifications on your own in the Wifi module for supporting long distance scenarios?

(In reply to comment #7)
> Hi,
> 
> What PropagationDelayModel are you using in the last scenario? Are you still
> using the constant speed one?

Yes, I always use the same propagation delay model:

channel.SetPropagationDelay ("ns3::ConstantSpeedPropagationDelayModel", "Speed", DoubleValue (300000000.0) );

(In reply to comment #7)
> Hi,
> 
> What PropagationDelayModel are you using in the last scenario? Are you still
> using the constant speed one?

Yes, I always use the same propagation delay model:

channel.SetPropagationDelay ("ns3::ConstantSpeedPropagationDelayModel", "Speed", DoubleValue (300000000.0) );


(In reply to comment #8)
> Since I'm also working on a kind of "Wi-Fi" long distance scenarios in ns-3, I
> maybe can help you further on your troubles.
> 
> Did you try it in the last ns-3 version (ns-3.18), since the Wifi module has
> been updated?

Yes, I have tried also with the new version 3.18 and I have obtained same results. The same "increasing staircase" is perceiveid for Ofdm 36, 48 and 54 Mbps.

However, I think that I have found de response to the "problem" with the fall of the throughput at different distances with same acktimeout. For DSSS rates, the distance limit is around 30km because the plcp transmit rate is the lowest rate, 1Mbps. For Ofdm rates the plcp transmit rate is higher (6Mbps). Since acktimeout must be set using the expression for long distances:

acktimeout= SIFS + SlotTime + 2*propagationDelay + PLCP_transmit_time

propagationDelay depends of the PLCP_transmit_time and it is different for both techonologies, and therefore, the distance achieved is lower. So this is not a bug but a good implementation.

But the problem with the increase of performance for long distances is still there, although Nicola Baldo have said that it can be expected due to the interaction between the propagation delay and the medium access / backoff procedure.

So if you think that it is normal, this bug can be closed. Otherwise I could make more tests to continue study this behaviour.

Finally, I have tried the new rates of 11n, and I have found the same behaviour (the increasing staircase in the highest rates).


> Have you made some modifications on your own in the Wifi module for supporting
> long distance scenarios?

No modification I have been done in the Wifi module but the wifi-mac.cc ones.
These consist in comment the lines of the method WifiMac::Configure80211g (or 11n) since I modify them from my script:

wifiMac.SetType ("ns3::AdhocWifiMac",
  	    		"Ssid", SsidValue (ssid),
  	    		"Sifs", TimeValue (MicroSeconds (10)),
  	    	        "Slot", TimeValue (MicroSeconds (m_slot_time)),
	    		"EifsNoDifs", TimeValue (MicroSeconds (10+304)),
  	    		"Pifs", TimeValue (MicroSeconds (10+m_slot_time)),
  	    		"AckTimeout", TimeValue (Seconds (m_acktimeout)),
  	    		"CtsTimeout", TimeValue (Seconds (m_acktimeout)));

There is no bug, it can be closed,