Bug 1034

Could you please point out the line(s) of code you are referring to?

WifiMacQueue::Enqueue - packet is only pushed onto the queue at line 101 if the queue is not full. Otherwise function returns at line 98 with absolutely no indication that the packet was dropped.

WifiMacQueue::Cleanup - packets currently on the queue may be dropped at line 123 if its lifetime expired. This function is called in many places within the class, and there are no indication that packets have been dropped.

Created attachment 1015 [details]
Proposed patch to add trace source to WifiMacQueue

On another related note - WifiMac have the capability to trace packet drops during Tx (WifiMac::NotifyTxDrop, wifi-mac.cc:237), but is never used anywhere other than for the packet not being queued when not associated in the STA mode. Getting these packet drops to trigger the WifiMac's trace source would be good.

Created attachment 1016 [details]
Patch creating and linking a chain of trace sources back to NotifyTxDrop

Here, I've created trace sources at Dcf and WifiMacQueue, as well as the associated Notifyxxx functions that abstracts the triggering of the traces.

RegularWifiMac and DcaTxop subscribes to the trace sources down the chain and forwards notifications up through the Notifyxxx functions.

I can't reach the accessor "PacketDrop" from my NS3 code patched in attachment 1015 [details] in comment 3. I try something like this: 
Config::Connect("/WifiMacQueue/PacketDrop", MakeCallback(&DequeueFirstAvailable)); 
What is the correct way of reaching this callback function for different sender nodes / access categories?

(In reply to comment #6)
> I can't reach the accessor "PacketDrop" from my NS3 code patched in attachment
> 1015 [details] in comment 3. I try something like this: 
> Config::Connect("/WifiMacQueue/PacketDrop",
> MakeCallback(&DequeueFirstAvailable)); 
> What is the correct way of reaching this callback function for different sender
> nodes / access categories?

It's been a very long while since I've touched NS3 code. I recall I've always just attached the traces the long way - first get a Ptr<WifiMacQueue>, then call the TraceConnectWithoutContext function.

I can't remember using Config::Connect. In any case, this TraceSource will tell you when a specific MAC queue drops a packet (not when any que drops a packet). Therefore you actually need to connect to a specific WifiMacQueue (ie. the queue that is attached to a specific MAC of a specific Node).

Unfortunately I can't give any more help than this other than referring you to http://www.nsnam.org/docs/release/3.13/manual/singlehtml/index.html#overview

(In reply to comment #7)
> (In reply to comment #6)
> > I can't reach the accessor "PacketDrop" from my NS3 code patched in attachment
> > 1015 [details] in comment 3. I try something like this: 
> > Config::Connect("/WifiMacQueue/PacketDrop",
> > MakeCallback(&DequeueFirstAvailable)); 
> > What is the correct way of reaching this callback function for different sender
> > nodes / access categories?
> 

may I suggest this:
http://www.nsnam.org/wiki/index.php/HOWTO_determine_the_path_of_an_attribute_or_trace_source

I've spent four years on your trail 
Four long years 
On your trail 

This bug is still relevant, see https://groups.google.com/forum/?hl=en#!topic/ns-3-users/47_F14UMlFE

Created attachment 2833 [details]
Connect the MacTxDrop trace of WifiMac to the Drop trace of the wifi MAC queues

Recently, WifiMacQueue has been made a Queue subclass and therefore it gained a Drop trace that is fired every time a packet is removed from the queue (e.g., the case for stale packets) and every time a packet is dropped because the queue is full. The proposed patch connects such Drop trace to the MacTxDrop trace of the WifiMac class, meaning that every time the Drop trace is fired, the MacTxDrop trace is fired as well.

Thanks, I do not have much comment on this. Can the other patches be discarded?

(In reply to sebastien.deronne from comment #11)
> Thanks, I do not have much comment on this. Can the other patches be
> discarded?

Yes. The first patch (which is included in the second one) is not needed anymore because WifiMacQueue now inherits the Drop trace (and others) from the Queue base class. The second patch follows the same approach as mine, but it is not applicable because lots of things changed since then.

If you agree, I will push my patch (after applying a few cosmetic changes).

(In reply to Stefano Avallone from comment #13)
> If you agree, I will push my patch (after applying a few cosmetic changes).

+1

Fixed with changeset 12844:0b63167eadc5.