Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Dec 2000 11:22:55 -0500
From:      "Michael T. Stolarchuk" <mts@off.off.to>
To:        "Fulvio Risso" <risso@polito.it>
Cc:        opentrax@email.com, dr@kyx.net, tcpdump-workers@tcpdump.org, ethereal-dev@ethereal.com, snort-devel@lists.sourceforge.net, freebsd-hackers@freebsd.org, tech@openbsd.org, mts@off.off.to
Subject:   Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? 
Message-ID:  <200012121622.eBCGMtH16626@off.off.to>
In-Reply-To: Your message of "Tue, 12 Dec 2000 16:53:31 %2B0100." <000701c06453$b2e83740$14ec1fc3@ssgrr.it> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <000701c06453$b2e83740$14ec1fc3@ssgrr.it>, "Fulvio Risso" writes:
>I do not agree with you.
>Partially supported by Ms Research means that we got:
>- software
>- 1 Dell workstation
>
>That's it.
>I *strongly* suggest to ask someone before opening your mouth.
>Cheers,
>
>    fulvio
>
>PS As Loris said, we sent an e-mail to tcpdump-workers asking for that. We
>were really surprised by the poor performances of BSD. Anyway, no one
>answered. So, please...

fulvio, did you write this paper?  were you involved in some
of the work? 

notice at the end of the article:
	Notice that WinDump has been launched with the standard
	kernel buffer (1MB); in presence of heavy traffic the size
	of this buffer can be increased with a simple command line
	switch, improving further the overall performance of the
	system. Our conclusions are that BPF architecture for Windows
	performs well, that the dynamic buffer improves effectively
	the overall performances and that, among all the Windows
	flavors, Windows 2000 is the best platform for an high
	performance network analyzer.

and -- :

typical buffer sizes for bpf these days are still 32K,
One could then say that if you up the buffer sizes to (2) 512M buffers, 
you'd get much better results, but the actual results are kinda suprising....
you may/may not get better performance... 
by increasing the buffer size, you incur a longer kernel copy of
the buffer's out into user space.  In short bursts, the performance
may be better, but under long heavy loads, you could get *more*
packet loss...

even so, 32K is abysmal... and changing it, to, say, 128K may
be a much better alternative...

----------
don't discount this article and its measurements...
----------


i was asked some serious questions about sniffing by some
microsoft developers...  The people i talked to were 
very serious about doing good analysis of sniffing performance.
This is another example of a similar analysis, and i do belive
the results...  i do not think they are skewed, but i would
have liked a bit more information about the bpf which was
used (for example, what were the buffer sizes which
were used, do you have more information about how
system resources were consumed?)

But i'll also point out that there ARE several platforms in
existance today which use non-windows platforms and get very
good sniffing results.   

Even so, i'd like to know whether the  `wintendo' sniffing
is done without ever doing any context switches; ie: much
of the bpf cost in doing sniffing arised out of the need to
isolate the process spaces from the kernel spaces...  if you
don't have the same isolation, you lose safety, but gain
performance.

mts.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012121622.eBCGMtH16626>