Why the .pcap file doesn't contain the records of the packet loss(MacTxDrop) ?

Tianye

unread,

Aug 13, 2016, 5:47:50 PM8/13/16

to ns-3-users

Dear All,

I got a question about the trace file(.pcap). In my simple simulation, I found one packet loss by using the flow-monitor and it was a MacTxDrop(Trace source indicating a packet has been dropped by the device before transmission). But I can't see any packet loss record from the trace file(.pcap).

Some information about my simulation:

Two nodes.(one client: uses onOffApplication: constant ontime:1 offtime:0 PacketSize:100 Bytes DataRate: 1623 kBps; one server: uses sinkApplication)

TCP protocal

PointToPointNetDevice: DataRate: 20Mbps; Delay: 1.42 ms (I didn't configure ReceiveErrorModel. So I thought there shouldn't be any packet loss, but there is one.)

Thank you so much!

Best Regards,

Tianye

unread,

Aug 15, 2016, 1:34:47 PM8/15/16

to ns-3-users

Dear All,

I actually would like to figure out why there exits packet loss when I didn't configure any packet loss for the channel. However, packets are lost when I set the DataRate of onOffApplication larger than a certain value. That's why I use the flow monitor and trace source(MacTxDrop).

Thanks

Tianye

unread,

Aug 15, 2016, 3:48:13 PM8/15/16

to ns-3-users

Dear All,

I think the overflow of node's queue causes the packet loss. Because the DataRate of the onOffApplication is too large and the NetDevice can't handle it. Due to the packet was dropped by the node, the .pacp trace file is also unable to record this packet loss. Although no one answer my question, I still would like to thank all you guys.

Best Wishes,

Tianye

Tommaso Pecorella

unread,

Aug 15, 2016, 7:08:01 PM8/15/16

to ns-3-users

Hi,

you have found the problem before we was able to answer.

If the App is sending too many data, they'll be dropped in the Tx queue, and (obviously) they're not recorded in the pcap.

The only way to track these is with the Ascii trace or by hooking the relevant point where the packets are dropped.

Cheers,

T.

Tianye

unread,

Aug 15, 2016, 8:31:22 PM8/15/16

to ns-3-users

Hello Tommaso,

Thanks for your further explanation.

Yes, I found the problem by finding the time when the packets are lost and looking at the number of the packets in the queue.