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.
