WiFi packets not traced

20 views
Skip to first unread message

Vineet Gokhale

unread,
Apr 8, 2020, 5:47:04 AM4/8/20
to OMNeT++ Users
Hello,

I am simulating a star topology using a wired-cum-wireless network. There are six pairs of source-destination pairs in the network.
The sources are connected via WiFi to the AP (infrastructure mode), and the destinations are connected to the same AP via Ethernet. 
Each source is generating UDP packets at the rate of 1000 per second. The total simulation time is 5 seconds.
The packet measurements for one particular source-destination pair are as shown in the table below. The measurements look similar for other pairs as well.

image.png



Wireless source:
  • Out of 5000 packets, 4189 have been "sent without retry" and 638 (637+1) have been dropped. That leaves us with 173 more packets that are supposedly "sent with retry".
  • Only 4189 packets have been "popped" from the MAC queue. These packets happen to be the same as the packets "sent without retry". 
  • This means not all packets that are supposedly sent from the source are "actually sent" from the source.

Wired destination:
  • Only 4189 packets that are "sent without retry" or "popped from queue" at the source were successfully received.

Is there any explanation for the disappearance of "packets sent with retry"? Or is there any fundamental concept that I am totally missing here?
Any insights regarding this is highly appreciated.

Thanks in advance.

Regards,
Vineet

Levente Mészáros

unread,
Apr 8, 2020, 6:29:37 AM4/8/20
to OMNeT++ Discussion List
The "sent with retry" are just the packets which have the RETRY bit set to true, the "sent without retry" is the opposite. If a packet is sent multiple times due to packet loss, then it is counted multiple times. So the packets have not disappeared, each packet that was transmitted at least once eventually ended up being correctly received. The transmitted number of packets at the MAC level may be different then the number of arrived packets at application level.

Did you check that your queues are empty at the end of the simulation? Running the simulation for 5 secs and generating 1000 packets per sec might leave a number of packets in the queues at the end of the simulation.

Best regards,
levy

--
You received this message because you are subscribed to the Google Groups "OMNeT++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/omnetpp/dad7ff2c-8908-44b7-b888-73434f04a224%40googlegroups.com.

Vineet Gokhale

unread,
Apr 9, 2020, 5:49:09 AM4/9/20
to OMNeT++ Users
The queue length at the end of simulation is non-zero! Thanks for the pointer :-)
Is there a way to specify the start and end times for sources to generate packets? I can set the simtime slightly higher than end-time or choose a large simtime so that no. of packets in the queue at the end of the simulation is negligible.  
To unsubscribe from this group and stop receiving emails from it, send an email to omn...@googlegroups.com.

adamgeorge309

unread,
Apr 10, 2020, 9:00:53 AM4/10/20
to OMNeT++ Users
Udp apps have a start time and stop time parameter.
Reply all
Reply to author
Forward
0 new messages