queueLength:max is incorrect

[admaio]

I am trying to simulate queueless IEEE 802.11 ad-hoc networks (INET v4.2.0 cb6cc37b)

In my inifile, I added:

**.wlan[*].**.dcf.channelAccess.pendingQueue.packetCapacity = 1

However, in my scalar result file, I see queueLength:max is 2.0

We know that the queueLength statistic is updated when any one of these signals is emitted: packetPushed, packetPopped, packetRemoved, or packetDropped.

By checking the vector file with queue transitions, I noticed that the artifact happens because a signal to add a packet to the queue is emitted immediately before the signal to remove a packet from the queue, so the actual time at which the queue is long 2 is zero, but this is enough for the queueLength:max to be incorrect.

Here is a screenshot of the queue length vector of a simple experiment.

[levy]

Yes, this is a known bug for which I haven't figured out a correct solution. The packet has to be inserted into the queue first in order to provide the complete list of packets to the dropper function. The reason is that the function is allowed to select a different packet that will be dropped (e.g. based on length or priority). So conceptually the packet is really pushed into the queue, and perhaps a different packet is removed from the queue. Unfortunately, the way the queueLength is computed doesn't know about this and the signal jumps above the limit for 0 amount of time.

[admaio]

As a follow-up, a similar issue was faced for the inProgressFrames, where the queueLength can take negative values. The issue seems a bit more critical here because the value of queue length at -1 is kept for a non-zero amount of time. The issue could stem because I set a 100ms warmup time, so there is a chance that the first signal registered is a dequeue, but it is just speculation at this point.

Here is a screenshot:

[levy]

Thanks for reporting this issue. I didn't know about this, and it looks very bad.

[levy]

The queue length hazards has been fixed in INET master. The queue length is not updated until the end of the push packet operation, this change allows the packet to be dropped, removed or pulled before the queue length gets updated. With this change, there should be no queue length value recorded above the maximum packet capacity or below zero.

I'm not sure if it also fixes the warmup period issue with the InProgressFrames.