Wireshark-users: Re: [Wireshark-users] wireshark performance issues
From: Guy Harris <[email protected]>
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  
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.