Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] wireshark performance issues

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 3 Sep 2009 11:23:25 -0700

On Sep 2, 2009, at 11:10 PM, Haitham Al-Saif wrote:

Hi I'm using tshark which is installed in embedded linux running on powerpc 440 of FPGA board. I use tshark to analyze MPEG transport stream for FHD H.264. but I'm getting packet loss when I analyze the video stream in real-time with tshark and therefore I used tcpdump to capture packets instead of tshark and then analyze the saved packets with tshark. I'm getting much better result but still there is packet loss. I don't know why I get packet loss. I don't think that it is caused by the cpu getting overloaded because many times I'm able to analyze FHD with tshark without getting packet loss. is there anyone who knows what causes the packet loss? is there some buffers in embedded Linux causing the packet loss?

There's a buffer in Linux (embedded or not) that could cause packet loss if it's too small - it's the socket buffer on the PF_PACKET socket libpcap uses on Linux.

If packets get put onto the socket buffer faster than, at some particular point in time, dumpcap or tcpdump can read them from the socket buffer through libpcap, *even though, over the time the capture is running, the CPU isn't overloaded*, that can cause packet loss. It's not sufficient to have the CPU, on average, capable of analyzing packets as they arrive without dropping packets; a burst of packets, or (in the case of using TShark to analyze the packets as they arrive) some packets that require a lot more work, or some I/O that happens to happen at some time, or some work that consumes CPU at some particular time, could cause packets to be dropped.

Buffers can be used to alleviate this problem - if you have a big enough buffer, then packets can be stored in the buffer faster than they are drained from the buffer, to handle either faster-than-usual arrival of packet data or slower-than-usual reading of packet data, as long as the buffer is big enough that it doesn't fill up before the reader can drain it.

Try downloading libpcap 1.0.0 from www.tcpdump.org:

1) on Linux kernels with memory-mapped capture support, it uses the memory-mapped capture mechanism, which might be able to handle packet bursts a little better, and might allocate a memory-mapped ring buffer larger than the default socket buffer size;

2) it has an API that, on platforms where the buffer size for the capture mechanism used by libpcap can be set, allows you to set it at the time you open the network interface for capturing (on systems with BPF, such as *BSD, AIX, and Mac OS X, it can't be set *after* that, so that's not supported), so if the buffer is too small, it can be made bigger.

If tcpdump 4.0.0, also available from www.tcpdump.org, is built with libpcap 1.0.0, it supports the "-B" flag to set the buffer size.