Thanx for that information! I think I have used something big like 65535. But using 1514 should be enough in my case (CRC is dropped).
I hope I will find some time to play around with the snap_len in the next weeks and let you know what happens. All the best, Bernd > Subject: Re: [tcpdump-workers] libpcap capture performance drop > From: g...@alum.mit.edu > Date: Fri, 20 May 2011 12:02:42 -0700 > To: tcpdump-workers@lists.tcpdump.org > > > On Sep 6, 2010, at 11:45 AM, Doktor Bernd wrote: > > > If I recompile with the HAVE_PACKET_RING stuff *not* commented out I get > > the bad performance as with the packaged versions from Ubuntu. So the > > performance drop is caused by that part of libpcap. > > The packet-ring stuff has fixed-length slots, which means that the number of > slots is the buffer size divided by the size of the slots. > > The slot size is calculated from the snapshot length; what snapshot length > are you using? If, for example, this is on Ethernet, and your snapshot > length is > 1518 (1518 just in case the CRC is delivered as part of the > packet; it is with BPF in Mac OS X, for example, and I think on some other > BPF platforms, but it might not be on Linux), that might reduce the number of > ring buffer slots and thus increase the number of packet drops, especially if > the snapshot length is, for example, the tcpdump/Wireshark default of 65535.- > This is the tcpdump-workers list. > Visit https://cod.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
