Date: Thu, 14 Dec 2000 11:57:41 +0100 From: "Loris Degioanni" <loris@netgroup-serv.polito.it> To: "Michael T. Stolarchuk" <mts@off.off.to> Cc: <tcpdump-workers@tcpdump.org>, <ethereal-dev@ethereal.com>, <snort-devel@lists.sourceforge.net>, <freebsd-hackers@freebsd.org>, <tech@openbsd.org> Subject: R: [tcpdump-workers] Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? Message-ID: <009801c065c0$a2bd1200$016464c8@lorix> References: <200012121622.eBCGMtH16626@off.off.to>
next in thread | previous in thread | raw e-mail | index | archive | help
-----Messaggio Originale----- Da: Michael T. Stolarchuk <mts@off.off.to> A: 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> Data invio: marted́ 12 dicembre 2000 17.22 Oggetto: [tcpdump-workers] Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? > > > 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... I think this is not a satisfactory explanation. I am not a freebsd guru but, as far as I know, bpfread is invoked during normal scheduling, while bpf_tap is called by the NIC driver, therefore I suppose during an interrupt. I am sure this is the situation in Windows. This means that the tap has always higher priority and is not influenced by the copy, so having huge buffers is not a problem, because the copy is always interrupted by the arrival of a new packet. Can anyone confirm/refute this behavior in freebsd? > even so, 32K is abysmal... and changing it, to, say, 128K may > be a much better alternative... I agree. > ---------- > 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. I am sure of this. But very few provide a detailed analysis of the performance. Our test gives precise numbers, which can be contested, but not without other numbers. > 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. > `wintendo' sniffing is done in a way very similar to the one of BPF. With the same buffer size, the number of context switches is approximatly the same. Loris. 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?009801c065c0$a2bd1200$016464c8>