Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Whether or not libpcap will handle 10Gbps with 0 packet loss is a matter of the machine that you are using and libpcap version. If the machine, CPU and HDD I/O are fast enough, you may get 0 packet loss. Otherwise you may need to perform the following actions:</p> <ul> <li><p>Update your libpcap to the most recent version. Libpcap 1.0.0 or later, supposts zero-copy (memory-mapped) mechanism. It means that there is a buffer that's in both the kernel's address space and the application's address space, so that data doesn't need to be copied from a kernel-mode buffer to a user-mode buffer. Packets are still copied from the skbuff (Linux) into the shared buffer, so it's really more like "one-copy", but that's still one fewer copy, so that could reduce the CPU time required to receive captured packets. Moreover more packets can be fetched from the buffer per application wake up call. </p></li> <li><p>If you observe a high CPU utilization, it is probably your CPU that cannot handle the packet arrival rate. You can use xosview (a system load visualization tool) to check your system resources during the capture. </p></li> <li><p>If the CPU drops packets, you can use PF_RING. PF_RING is an extension of libpcap with a circular buffer: <a href="http://www.ntop.org/products/pf_ring/">http://www.ntop.org/products/pf_ring/</a>. It is way faster and can capture with 10Gbps with commodity NICs <a href="http://www.ntop.org/products/pf_ring/hardware-packet-filtering/">http://www.ntop.org/products/pf_ring/hardware-packet-filtering/</a>.</p></li> <li><p>Another approach is to get a NIC that has an on-board memory and a specific HW design for packet capturing, see <a href="http://en.wikipedia.org/wiki/DAG_Technology">http://en.wikipedia.org/wiki/DAG_Technology</a>.</p></li> <li><p>If the CPU is not any more your problem, you need to test disk data transfer speed. hdparm is the simplest tool on Linux. Some distros come with a GUI, otherwise: <code>$ sudo hdparm -tT /dev/hda</code></p></li> </ul> <p>If you are developing your own application based on libpcap:</p> <ul> <li><p>Use pcap_stats to identify (a) the number of packets dropped because there was no room in the operating system's buffer when they arrived, because packets weren't being read fast enough; (b) number of packets dropped by the network interface or its driver.</p></li> <li><p>Libpcap 1.0.0 has an API that lets an application set the buffer size, on platforms where the buffer size can be set. b) If you find it hard to set the buffer, you can use Libpcap 1.1.0 or later in which the default capture buffer size has been increased from 32K to 512K. c) If you are just using tcpdump, use 4.0.0 or later and use the -B flag for the size of the buffer</p></li> </ul>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload