|
Bugzilla – Full Text Bug Listing |
| Summary: | MinstrelHt provides strange results at low SNR with A-MPDU enabled | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | sebastien.deronne |
| Component: | wifi | Assignee: | sebastien.deronne |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | matis18, ns-bugs |
| Priority: | P3 | ||
| Version: | ns-3.28 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
MinstrelHt with A-MPDU
Ideal with A-MPDU enabled MinstrelHt with A-MPDU enabled MinstrelHt with A-MPDU disabled Use AmpduTag to obtain the number of MPDUs in the failed AMPDU MinstrelHT with A-MPDU enabled after the patch proposed |
||
Created attachment 3102 [details]
Ideal with A-MPDU enabled
Created attachment 3103 [details]
MinstrelHt with A-MPDU enabled
Created attachment 3104 [details]
MinstrelHt with A-MPDU disabled
I've found that in MacLow::BlockAckTimeout when reporting txop->MissedBlockAck the number of MPDUs reported is always 0. Hence, Minstrel receives an AmpduTxStatus of 0 successful MPDUs and 0 failed MPDUs and fails to correctly calculate the rates. the problem is that in MacLow::BlockAckTimeout using the aggregateQueue size to obtain the number of MPDUs in the AMPDU transmitted is wrong because the MPDUs are dequeued when transmitted. I propose to use the AmpduTag of the currentPacket which has the number of remaining mpdus in the aggregated packet. Created attachment 3105 [details]
Use AmpduTag to obtain the number of MPDUs in the failed AMPDU
(In reply to Matías Richart from comment #5) > Created attachment 3105 [details] > Use AmpduTag to obtain the number of MPDUs in the failed AMPDU Thanks Matias, it looks fine, I will check if this does not cause any issue. Created attachment 3106 [details]
MinstrelHT with A-MPDU enabled after the patch proposed
We should push the fix still today to have it wrapped in the release. Fixed in changeset 13624:95d61e579c5b |
Created attachment 3101 [details] MinstrelHt with A-MPDU I was plotting some results for MinstrelHt and for Ideal rate manager and I observed very strange results for MinstrelHt when SNT is low . Also, this only happens when A-MPDU is enabled (see attachments). I suspect something is going wrong in MinstrelHt when complete A-MPDUs are lost, resulting in usage of a too high rate and making any transmission impossible at low SNR. I made those tests in 802.11ac, but this is also seen with 802.11n. This also made me realize we do not check output of rate managers in regression (though this issue seems there for a long time, I reverted back quite some commits to check). In parallel, I will add some checks, at least on the first and last values, but ideally we should check the complete curve.