Bug 873 - Queue occupancy counter not decremented in WifiMacQueue::Remove()
Queue occupancy counter not decremented in WifiMacQueue::Remove()
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: wifi
ns-3-dev
All All
: P3 normal
Assigned To: Dean Armstrong
: bug
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-13 05:26 EDT by Dean Armstrong
Modified: 2010-05-10 08:36 EDT (History)
1 user (show)

See Also:


Attachments
proposed patch (358 bytes, patch)
2010-04-13 05:49 EDT, Nicola Baldo
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dean Armstrong 2010-04-13 05:26:08 EDT
When playing with the Wi-Fi MSDU aggregation (i.e., A-MSDU) support at the head of ns-3-dev (changeset 6191) I noticed that in my simulation (which involved UDP from an on-off source on a QstaWifiMac with an installed MsduStandardAggregator, toward a packet sink on a QapWifiMac) the aggregation would start out as expected but, as the "over-the-air" PCAP trace showed, after a short while the aggregation would stop and I would just get a single frame at a time.

I've traced this back to the fact that in WifiMacQueue::Remove() the m_size member is not being decremented when the packet is removed.
Comment 1 Nicola Baldo 2010-04-13 05:49:10 EDT
Created attachment 829 [details]
proposed patch
Comment 2 Nicola Baldo 2010-04-13 05:49:48 EDT
(In reply to comment #1)
> Created an attachment (id=829) [details]
> proposed patch

can you confirm that the patch fixes your problem?
Comment 3 Dean Armstrong 2010-04-13 06:51:39 EDT
Thanks for your quick work, Nicola.

Yes, that is exactly the patch which fixes the issue. I hadn't quite yet got around to posting this comment pointing out a regression test which demonstrates the problem at:

http://codereview.appspot.com/854047

...and my proposed patch (which was identical to yours) at...

http://codereview.appspot.com/809046
Comment 4 Nicola Baldo 2010-04-16 14:13:26 EDT
changeset 6224	8386567abea1
Comment 5 Dean Armstrong 2010-04-23 04:15:07 EDT
(In reply to comment #4)
> changeset 6224    8386567abea1

Should the regression test for this bug that I proposed above at:

http://codereview.appspot.com/854047

...be pushed too (obviously not while code is frozen for ns-3.8)?
Comment 6 Nicola Baldo 2010-04-23 05:30:09 EDT
(In reply to comment #5)
> Should the regression test for this bug that I proposed above at:
> 
> http://codereview.appspot.com/854047
> 
> ...be pushed too (obviously not while code is frozen for ns-3.8)?

Good point... sorry for overlooking that. 
I had a look at your test, it is ok for me (and in general more tests are always welcome!). So I agree with pushing it to ns-3-dev as soon as it gets in the open phase. 

I am reopening this bug to not forget this issue.
Comment 7 Dean Armstrong 2010-05-10 08:08:38 EDT
(In reply to comment #6)

Regression test pushed to ns-3-dev as changeset 6293:11a2f62de3ec

Bug is now resolved.