|
Bugzilla – Full Text Bug Listing |
| Summary: | Simulation fails when transmitting very small MPDU subframes | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | sebastien.deronne |
| Component: | wifi | Assignee: | sebastien.deronne |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | matis18, ns-bugs, tomh |
| Priority: | P5 | ||
| Version: | ns-3-dev | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
patch to avoid null or negative duration for the last MPDU subframe
new patch to avoid null or negative duration for the last MPDU subframe reworked patch to avoid null or negative duration for the last MPDU subframe |
||
I revise the patch and seems ok to resolve the problem mentioned. However, I couldn't totally understand why is the calculation done that way. For example, for the last packet, why the number of symbols is calculated as the difference between the total ampdu symbols and the symbols already sent? Isn't the problem there? Is there any issue if the numSymbols for the last packet is calculated as for the previous packets? Wouldn't that solve the problem? Matias, Thanks for having a look. This is not an issue, the subtraction is done in order to not overpass the total duration previously calculated for the entire frame. Can you avoid using the special value '0' at the API? I think it is a bit confusing to have 0 mean actually non-zero; users of the API can just provide explicitly the size, right? Also, in doxygen, specify that totalSize must be <= size. Perhaps rename "totalSize" to "ampduSize" if this is what it is about? Created attachment 2171 [details]
new patch to avoid null or negative duration for the last MPDU subframe
Based on Tom's comments, I refactored a bit the patch.
However, I propose a different solution: different functions will be called whether it is a normal frame transmission or a MPDU subframe in an A-MPDU.
This makes the API much easier for users who do not want to bother about A-MPDU.
Parameters have also been renamed as suggested by Tom.
I still hit this assert when testing your most recent patch, on a HtMcs15 situation with 128 bits.
I also see the 'workaround' keyword in the patch:
+ if (m_totalAmpduNumSymbols == expectedTotalSymbols)
+ {
+ //Workaround to avoid to have null duration for the last MPDU when it is has a small size (e.g. BAR, ...).
+ m_totalAmpduNumSymbols--;
+ }
which makes me wonder whether it is a good final solution.
What is the problem with directly fixing the CalculateTxDuration to return the right quantity when the number of bits is fewer than needed for a symbol?
Tom, I had that in mind first as well, and now looking back in the code I think it could be indeed the best solution. I am working a new fix, I'll try to finish it this week. Thanks for your feedback. Created attachment 2173 [details]
reworked patch to avoid null or negative duration for the last MPDU subframe
I reworked the previous patch, CalculateTxDuration can now return a time value smaller than the symbol duration. It should fix the remaining issues observed by Tom.
I suggest to deliver those changes, this should in any case provide improvement. I have used this for about a week on the LBT repo and it seems to avoid the issue now. I also like the shorter function signatures for CalculateTxDuration(). changeset 11773:f5b20a1c6eb3 |
Created attachment 2162 [details] patch to avoid null or negative duration for the last MPDU subframe When sending a very small MPDU subframe in an A-MPDU, such as the transmission of a BAR to flush the receiver (as last MPDU), we most likely get a null or even negative TX duration, which is protected by raising the following assert: NS_ASSERT (txDuration > NanoSeconds (0)); In that case, the simulation simply fails. The explanation is that the last MPDU subframe has only few bits, making it’s duration smaller than the symbol duration, and is thus included in the symbol which belongs to the previous MPDU subframe. The workaround proposed here is to indicate the total size of the whole A-MPDU, so that WifiPhy can guarantee that the last MPDU does not have a null or negative duration. Note that an assert is still raised when two or more small subframes are transmitted (and not only the last subframe), but this is very unlikely to occur.