Bug 873 – Queue occupancy counter not decremented in WifiMacQueue::Remove()

Bug 873 - Queue occupancy counter not decremented in WifiMacQueue::Remove()


Summary:	Queue occupancy counter not decremented in WifiMacQueue::Remove()

Status:	RESOLVED FIXED

Product:	ns-3
Classification:	Unclassified
Component:	wifi
Version:	ns-3-dev
Hardware:	All All

Importance:	P3 normal
Assigned To:	Dean Armstrong

URL:
Keywords:	bug

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2010-04-13 05:26 UTC by Dean Armstrong
Modified:	2010-05-10 08:36 UTC (History)
CC List:	1 user (show)

See Also:

Attachments
proposed patch (358 bytes, patch) 2010-04-13 05:49 UTC, Nicola Baldo	Details \| Diff
Add an attachment (proposed patch, testcase, etc.)

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 UTC

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 UTC

Created attachment 829 [details]
proposed patch

Comment 2 Nicola Baldo 2010-04-13 05:49:48 UTC

(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 UTC

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 UTC

changeset 6224	8386567abea1

Comment 5 Dean Armstrong 2010-04-23 04:15:07 UTC

(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 UTC

(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 UTC

(In reply to comment #6)

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

Bug is now resolved.