ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] Wireshark Performance on Laptops

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 20 Aug 2009 14:00:21 -0700

On Aug 20, 2009, at 1:47 PM, Sake Blok wrote:

I'm curious about:
- When capturing, how well do Linux and MacOS/X perform on a full Gbit link?

Note that performance could depend on the particular OS version and on the particular libpcap version. I don't know whether the mmap support in libpcap 1.x would make a difference; Luca Deri:

	http://luca.ntop.org/

seems to indicate that it might not (libpcap-mmap is Phil Wood's version, not Paolo Abeni's version which is what's in libpcap 1.x, but they might perform similarly):

The experience learnt from this experiment is:
• At 100 Mbit using a low-end PC, the simplest packet capture application is not
able to capture everything (i.e. there is packet loss).
• During the above experiment, the host used for capturing packets was not
responsive when the sender injected packets on the network.
• Out of the box, Windows and winpcap [winpcap], the port of libpcap to Win32,
perform much better than other popular Unix-like OS.
• Linux, a very popular OS used for running network appliances, performs very
poorly with respect to other OSs used in the same test.
• Libpcap-mmap [libpcap-mmap], a special version of libpcap that exploits the mmap() system call for passing packets to user space, does not improve the
performance significantly.
• Implementing a Linux kernel module based on netfilter [netfilter] improves the performance significantly, but still under Linux most of the packets are lost. This means that Linux spends most of its time moving packets from the network
card to the kernel and very little from kernel to userspace.

Mac OS X might behave *somewhat* similarly to FreeBSD, because they both use BPF, but Luca seems to indicate that stuff below the capture mechanism makes a big difference - one issue is that if you get one interrupt per packet, your performance will suck at high packet rates, so polling, which causes multiple packets to be picked up per (clock) interrupt, can improve matters. I don't know offhand whether OS X's drivers and networking stack do polling or any other form of interrupt batching.

(I don't capture enough traffic to speak from experience - I mostly either read capture files supplied to me or do small captures of traffic to and from my own machine.)