Bug 2656

Summary: Minstrel and MinstrelHt provide different results for 802.11a/b/g
Product: ns-3 Reporter: sebastien.deronne
Component: wifiAssignee: Matías Richart <matis18>
Status: RESOLVED FIXED    
Severity: minor CC: ns-bugs
Priority: P4    
Version: ns-3.27   
Hardware: All   
OS: All   
Attachments: 802.11a minstrel results
802.11a minstrelht results
Remove rate initialization at "half way"
Results after the patch
Results after the patch
Correct several bugs and improve logging
Results after the patch

Description sebastien.deronne 2017-02-11 02:17:21 UTC
MinstrelHt should behave the same as Minstrel for 802.11a/b/g.
This is apparently not the case, when I run them with exactly same configuration, same stepTime and same stepSize.
Comment 1 sebastien.deronne 2017-02-11 02:18:54 UTC
Created attachment 2780 [details]
802.11a minstrel results
Comment 2 sebastien.deronne 2017-02-11 02:19:27 UTC
Created attachment 2781 [details]
802.11a minstrelht results
Comment 3 sebastien.deronne 2017-03-02 15:24:04 UTC
Matias, do you have an idea for this one?
Comment 4 Matías Richart 2017-03-02 15:57:54 UTC
(In reply to sebastien.deronne from comment #3)
> Matias, do you have an idea for this one?

I haven't been able to look at it.
I'll do it for next week.
Comment 5 Matías Richart 2017-03-10 17:12:28 UTC
I found that Minstrel was not initialized at the lowest rate in some cases.
My understanding is that it should always be initialized at index 0.

With this change the result is as shown in the figure.
I'll dig a bit more to explain the small differences that still persist.
Comment 6 Matías Richart 2017-03-10 17:14:04 UTC
Created attachment 2790 [details]
Remove rate initialization at "half way"
Comment 7 Matías Richart 2017-03-10 17:14:31 UTC
Created attachment 2791 [details]
Results after the patch
Comment 8 Matías Richart 2017-03-10 17:46:18 UTC
Created attachment 2792 [details]
Results after the patch
Comment 9 sebastien.deronne 2017-03-18 06:06:59 UTC
(In reply to Matías Richart from comment #6)
> Created attachment 2790 [details]
> Remove rate initialization at "half way"

Thanks Matias.
Any update since then?
Comment 10 Matías Richart 2017-03-20 20:07:11 UTC
(In reply to sebastien.deronne from comment #9)
> (In reply to Matías Richart from comment #6)
> > Created attachment 2790 [details]
> > Remove rate initialization at "half way"
> 
> Thanks Matias.
> Any update since then?

The differences are because different random sample rates are selected in both cases. Those rates are obtained using the random number generator.
I'm still investigating where is the difference in the usage of the generator, as in both cases the same code is executed.
Comment 11 sebastien.deronne 2017-04-21 05:52:03 UTC
Matias, any updates on this? Maybe you need to set the seed to have control on the randomness.
Comment 12 Matías Richart 2018-01-23 21:28:31 UTC
Hello.

I've revised the code and the logs in detail.
I have corrected some discrepancies between both codes, however small differences still appear in the rate observed.

I attach the patch. The changes are:
- in Minstrel initialize rate at 0
- in Minstrel, do not trace sampling rates
- in Minstrel, stop retries when the counter reaches the max value.
- setting seed in Minstrel and MinstrelHt
- Also, for both codes I improve the logging so as to make comparison easier.

My opinion, after revising the logs for many hours, is that the differences in the rate observed are generated because of the differences in timing. In the logs can be seen that in the 100ms between updates Minstrel sends more frames than MinstrelHt.
I think this is because it is not exactly the same code, MinstrelHt calls Minstrel functions, but it also executes its own code.
Comment 13 Matías Richart 2018-01-23 21:29:57 UTC
Created attachment 3012 [details]
Correct several bugs and improve logging
Comment 14 Matías Richart 2018-01-23 21:30:43 UTC
Created attachment 3013 [details]
Results after the patch
Comment 15 sebastien.deronne 2018-01-25 16:07:06 UTC
Matias, thanks a lot for your support, it looks quite the same now, I agree to push those changes and close this bug.
Comment 16 sebastien.deronne 2018-01-31 14:18:41 UTC
pushed in changeset 13270:f074a6ada683