Ethereal-dev: R: [tcpdump-workers] Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed
-----Messaggio Originale-----
Da: Michael T. Stolarchuk <mts@xxxxxxxxxx>
A: Fulvio Risso <risso@xxxxxxxxx>
Cc: <opentrax@xxxxxxxxx>; <dr@xxxxxxx>; <tcpdump-workers@xxxxxxxxxxx>;
<ethereal-dev@xxxxxxxxxxxx>; <snort-devel@xxxxxxxxxxxxxxxxxxxxx>;
<freebsd-hackers@xxxxxxxxxxx>; <tech@xxxxxxxxxxx>; <mts@xxxxxxxxxx>
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.
