Subject: Re: packet capturing
To: Antti Kantee <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 01/13/2004 14:47:37
I really don't understand. Why are using a NetBSD mailing list to
discuss the poor quality-of-implementation of Linux packet-capture
tools? The decidely weak paper that SMB cited does a lousy job of
using bpf (by the standards of published prior art) using bpf, yet
even so it's still quite competitive.
My local datapoint: with bge drivers tuned for low latency (high
ihterrupt load), running in a P4 Xeon 3.06Ghz under test, I can
approximate the rate of an (untuned) fxp driver. I have only one
client handy to run the stream ACK-DoS tool, but I can trivially hit
an input rate of 160k packets/sec and 80k interrupts/sec. After
enabling interrupt deferral, the exact same "DoS" [sic] traffic load
yields under 3k interrupts/sec -- at a point where heavily-buffered
bpf can keep up fine, thanks.
Here's the tcpdump exit stats after 10 seconds at 160k packets/sec,
(the rate quoted for the sunfire experiments)
2547185 packets received by filter
0 packets dropped by kernel
(I think that's with a default 4k bpf bufsize; certainly no more than
512k, which is the kernel limit. I dont _think_ I patched tcpdump on
this machien to up the limit, but I could have forgotten).
Oh, and Fig. 1 of the cited paper has no scale, and no indicated datapoints.