:
:
:(Hurm.... Wintendo outperforming unix???!?? Something's
: improper about this, and it ought to be fixed... :-)
: Comments? Other OS numbers: more recent
: FreeBSD versions? Solaris? Tru64? Optimization
: patches? Can those OO MSDN lobotomies actually
: be good things? Hurm... The Italian gauntlet has
: been thrown down.... --dr :-)
:
:url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm
Oh yah, I remember this... this is a pretty old benchmark, by the way.
Sigh. All this demonstrates is that the person tring to write the
packets to disk doesn't know what he's doing. There's nothing wrong
with FreeBSD, per say. Looking at the data I would guess that they
are appending to a file using write()'s on a packet-by-packet basis
or with a redirect from tcpdump on a shell line, rather then spend
the 60 seconds it would take to program-in some fairly trivial user-level
buffering. The program is obviously stalling on the write and causing
the BPF filter to overflow its output buffer. Just because FreeBSD
refuses to use all available memory to buffer a single file's writes
doesn't mean it's broken, just that the benchmark is. I'm guessing
simply double-buffering the disk writeing with two dd's would be
sufficient to capture all packets to disk and if someone seriously
intended to use a FreeBSD box as a packet-capture system they would
write a capture program to talk to the BPF socket directly and
implement proper buffering in that rather then tring to use tcpdump.
-Matt