Subject: Re: packet capturing
To: Darren Reed <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 01/20/2004 11:01:15
Just to put this in perspective:
table 1 of the paper smb cites compares percentage of packets caught,
for "stock" configurations of Linux, FreeBSD, and win2k. (the packet
load was a replay of a previously-acquired trace).
Linux captured 0.2% of the packets. FreeBSD captured 34%. Win2k
Just which of those is astonishing? I agree that the figure for Linux
is poor, but I dont find it particularly surprising.
OTOH, bpf/pcap capture rates (38%, above) can be increased
significantly by increasing the size of the bpf buffer. Bpf is already
double-buffered, or should be; increasing the buffer size reduces the
minimum context-switch rate to feed the packets to the libpcap app
without drop, *and* gives a bigger window for the userspace app to
process its buffer and ask for the next one, before the kernel
captures another full buffer's worth. We should be able to meet oir
exceed the win2k capture rate simply by increasing bpf_bufsize.
We could make bpf_bufsize sysctl'able; or raise the default to
something that reduces bpf drop at high packet rate (somewhere between
128 and 512k); or both.
Which of these would you support?