In message <009801c065c0$a2bd1200$016464c8@lorix>, "Loris Degioanni" writes:
>
>-----Messaggio Originale-----
>Da: Michael T. Stolarchuk <mts@xxxxxxxxxx>
>A: Fulvio Risso <risso@xxxxxxxxx>
>freebsd outsniffed by wintendo !!?!?
WRT: http://netgroup-serv.polito.it/winpcap/docs/performance.htm
>>
>
>>
>> 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?
ah, but the buffer sizes are fixed, and when the second buffer
is full, packets are lost. yes, the tap runs at a higher prio
than the buffer, but that doesn't alone guarnatee you won't
see packet loss.
(btw: i can confirm that behavior because i've had to work with it...
i'm familiar with these effects since i wrote the nfrd sniffing
and protocol decomposition stack)
Or saying it another way: if you increase the buffer sizes, say
to 1M each, and you're using, say completely saturdated 100Mb,
which means 12.5Mbyes/sec, you have to get the copy out of bpf
to process space in 1/12.5Mb/sec->80 Millisec.
By copy rates, that's a long time. But, typical BPF sleep
prioirities are LOW, which means that other processes complete
with the bpf-processes restart to gain the processor. (As
i recall, that has been fixed in a few architecutres). So if the
bpf is run on a loaded machine (ie: a typical intrusion detection system)
you still see periodic packet loss. That also partially explains
why just test-sniffing the traffic isn't sufficient to test a platform
for its ability to perform a decent job at ids...
>`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.
I'm sorry, but i don't see that in your paper. Near the bottom of
the paper it says that windoes sniffing buffers are 1M large. There
are *very few* bpf's with buffers that large. In fact, in several
kernels which i've used, multiple 1M kernel alloc's for space will
cause the kernel to hang indefinitly (due to multiple 1M vm space
allocations). i started my first reply with your text snippet noting
the buffer size differences.
Also, in the same article, there's not attempt at trying to
uncover the cause of performance difference, i don't see
measurements of context switch rates, number of kernel system
calls, nor number of interrupts. If i have missed it somewhere
please let me know.
What i wish i had is a good tool to discover what is going on during
the bpf packet loss. I was hoping (a few years back) to instructment
a kernel, so that instead of being able to profile the sniffing
process via statistical information about clock-tics, i could instead
collect statistical about what was going on during bpf-packet-loss
(ie: when the bpf second buffer is full). Turns out, that's hard
to do, but i haven't forgotten how worthwhile such a hack would be...
mts.