From owner-freebsd-hackers Thu Dec 14 3:27:37 2000 From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 14 03:27:31 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from fep19-svc.tin.it (pop09-acc.tin.it [212.216.176.72]) by hub.freebsd.org (Postfix) with ESMTP id 0439F37B400 for ; Thu, 14 Dec 2000 03:27:31 -0800 (PST) Received: from lorix ([212.171.148.94]) by fep19-svc.tin.it (InterMail vM.4.01.02.39 201-229-119-122) with SMTP id <20001214112728.FQIE18957.fep19-svc.tin.it@lorix>; Thu, 14 Dec 2000 12:27:28 +0100 Message-ID: <009801c065c0$a2bd1200$016464c8@lorix> From: "Loris Degioanni" To: "Michael T. Stolarchuk" Cc: , , , , References: <200012121622.eBCGMtH16626@off.off.to> Subject: R: [tcpdump-workers] Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? Date: Thu, 14 Dec 2000 11:57:41 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----Messaggio Originale----- Da: Michael T. Stolarchuk A: Fulvio Risso Cc: ; ; ; ; ; ; ; 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