|
Bugzilla – Full Text Bug Listing |
| Summary: | WifiMacQueue sender queue drops every 120 seconds of simulation, apparently for no particular reason | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Christian <c.facchini> |
| Component: | wifi | Assignee: | Nicola Baldo <nicola> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | andreev, ns-bugs |
| Priority: | P3 | ||
| Version: | ns-3-dev | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Attachments: | Simulation scripts reproducing the bug | ||
I confirm the behavior with latest ns-3-dev. We need to understand what is happening. (In reply to comment #1) > I confirm the behavior with latest ns-3-dev. We need to understand what is > happening. I have observed, that data is not more sent when ARP entry expires (120s). So, this is not a problem of mac queue, this is a possible problem of medium access (may broadcast collide in a scenario with two stations?) Kirill, thank you for investigating the problem. I confirm it is an ARP issue, in fact enabling logging for ArpCache we can see the following: 121.002s ArpCache:MarkWaitReply() 121.661s ArpCache:MarkAlive() ARP packets might be lost, either due to a collision (as said by Kirill) or more simply due to the overflow of the MAC queue. Still, I think the behavior seen is explained by the fact that when the ARP cache entry is in the WaitReply state, all packets from the upper layers are queued in the ARP queue, and will be forwarded to the device only when the ARP cache entry is refreshed. In the meanwhile, the MAC queue will gradually be emptied. To summarize, this is not a bug. |
Created attachment 930 [details] Simulation scripts reproducing the bug WifiMacQueue sender queue drops around 120 secs. Scenario tested: wifi adhoc net, 2 nodes, sender: node 1, receiver: node 2, OnOffApplication (always on). Specifically: - after 120 secs, no packet is enqueued. - at 121-122 secs, a packet is enqueued and the size of the queue drops. Then, the queue grows again and everything turns normal. - the behavior happens cyclically (period ~120 secs). To record the behavior I have put a couple of NS_LOG instructions in the Enqueue method: void WifiMacQueue::Enqueue (Ptr<const Packet> packet, const WifiMacHeader &hdr) { Cleanup (); if (m_size == m_maxSize) { NS_LOG_LOGIC ("qsize " << m_size); return; } Time now = Simulator::Now (); m_queue.push_back (Item (packet, hdr, now)); m_size++; NS_LOG_LOGIC ("qsize " << m_size); } Example w/ MaxPacketNumber=400,MaxDelay=2: 121.001 400 121.002 400 121.002 400 121.661 1 121.661 2 121.661 3 ... Example w/ MaxPacketNumber=1000,MaxDelay=10: 121.001 1000 121.002 1000 121.002 1000 122.002 392 122.645 2 122.645 3 122.645 4 ... AFAIK, the behavior is: - independent from the L4 protocol: tested with both TCP and UDP - independent on the MaxDelay attribute: tested with 10 (default), 2, 20 - dependent on the MaxPacketNumber attribute: tested with 400 (default), 100, 1000). With 1000 the queue first drops by ~600 packets and after another second it drops to zero. With 100 and 400 it drops directly to zero. Revision used to test this bug: 6e83ec53ba0a. Attached there's a sample script to reproduce the bug.