[Snort-devel] R: [tcpdump-workers] Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
loris at ...153...
Thu Dec 14 05:57:41 EST 2000
Da: Michael T. Stolarchuk <mts at ...159...>
A: Fulvio Risso <risso at ...157...>
Cc: <opentrax at ...156...>; <dr at ...40...>; <tcpdump-workers at ...142...>;
<ethereal-dev at ...143...>; <snort-devel at lists.sourceforge.net>;
<freebsd-hackers at ...144...>; <tech at ...76...>; <mts at ...159...>
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
> you'd get much better results, but the actual results are kinda
> 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...
> 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
`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.
More information about the Snort-devel