[tcpdump-workers] Huge latency increase libpcap-1.4.0 -> libpcap-1.5.3

Steve Bourland sbourland at swri.edu
Fri Nov 14 17:08:10 EST 2014

On Fri, 14 Nov 2014, Guy Harris wrote:

> On Nov 14, 2014, at 1:17 PM, Steve Bourland <sbourland at swri.edu> wrote:
>> I have some programs that suffered terrible performance degradation 
>> when moving from Ubuntu 12.04 to Ubuntu 14.04.
> Are those programs capturing and processing network traffic, are they 
> sending packets and expecting to receive a response, or are they doing 
> something else?

They are essentially servers, listening for specific packets and then 
building and sending the appropriate reply to the client.

> Is the performance issue one of high latency or of dropped packets when 
> capturing?

Sorry, the main concern I have is high latency, I only saw the dropped 
packets when I started changing the links in /usr/lib/x86_64-linux-gnu/ so 
I am fairly confident I messed something up there.

>> I then reduced the problem to a program that simple returned ICMP ECHO 
>> replies when requests were received.
> So that's a program sending packets and expecting to receive a 
> response...

It simply replaces the stack and replies to ICMP ECHO REQUESTs using 
libpcap.  I did that so I could just use ping as the stimulous and have 
automatic statistics.

>> Under 12.04, this program works very well (with reported responses from 
>> ping of under 500 usec), however, if I point the libpcap.so files to 
>> the downloaded version 1.5.3 (originally tested with 1.6.2 and problem 
>> seen there as well), the response times jump to sometimes over 100 
>> msec.
> ...and the issue you're talking about there is latency.

Yes, sorry, the times reported are reported from the other machine's 
(stock) ping command.

> What timeout are you specifying with pcap_open_live() or 
> pcap_set_timeout()?

In the test program I am using 1 msec as the timeout for 
pcap_open_live...but then have a selectable fd and am using a select call 
to let me know when a packet arrives.

> Note that:
> For programs passively capturing and processing network traffic, you 
> probably want a long timeout (tcpdump uses 1 second, Wireshark uses 100 
> ms or so), so that as many packets are delivered per wakeup as possible.
> For programs sending packets and expecting a response for each packet, 
> you probably want a *low* timeout (note that 0 is *not* a valid timeout 
> - it may mean "no timeout" in the sense that you won't see packets until 
> the capture mechanism's buffer fills up, which could take an 
> indefinitely long period of time) or, with newer versions of libpcap, 
> you might want to use "immediate mode", instead, in which no 
> timeout-based packet buffering is done - packets are delivered 
> immediately.  pcap_set_immediate_mode() first appeared in libpcap 1.5.0.

This is exactly the information I was hoping you would be able to provide. 
I will try this out and report back with my findings as soon as possible, 
but I expect you have identified where my problem lies.
 				Thank you very much,

More information about the tcpdump-workers mailing list