Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
(Hurm Wintendo outperforming unix???!?? Something's improper about this, and it ought to be fixed... :-) Comments? Other OS numbers: more recent FreeBSD versions? Solaris? Tru64? Optimization patches? Can those OO MSDN lobotomies actually be good things? Hurm... The Italian gauntlet has been thrown down --dr :-) url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm Performance and tests 1. Packet Capture Driver Performance The main goal of a packet capture driver are performance. This means low use of system resources (memory and processor) but also low probability of loosing packets. The following main parameters influence the performances of the capture process: the efficiency of the filter, size of the packet buffer, the number of bytes copied and the number of system call that needs to be executed by the application. 1. The efficiency of the packet filter is a very important parameter, because the filter must be applied to every incoming packet (i.e. thousands of times per second). The packet capture driver uses the fast and highly optimized BPF filter (for more details about the performances of BPF filter, see [McCanne and Jacobson 1993]), whose virtual-processor architecture is suited for modern computers architectures. 2. More optimized packet filters have been developed after the original BPF. The more interesting for this kind of applications are MPF [13], and BPF+ [12]. The packet capture driver does not offer at the moment the advenced features of these two filters. It could be very useful to include in the driver the possibility to efficiently handle similar filters in a way similar to MPF. 3. Kernel buffer's size is the parameter that influences the number of packet loss during a capture; a bigger buffer means lower loss probability. Since the correct size of the buffer is a very subjective parameter and depends on various factors like network speed or machine characteristics, the packet capture driver offers a dynamic buffer that can be set to any size whenever the user wants to do that. In this way it is possible to set very big buffers on machines with an huge amount of RAM. Notice however that the buffer is freed when the driver's instance is closed, therefore the memory is used by the driver only during the capture process (i.e. when really needed). 4. Performances are strongly influenced by the number of bytes that need to be copied by the system. This task can absorb a lot of processor time and buffer memory. To overcome the problem, the packet capture driver applies the filter to an incoming packet as soon as it arrives to the system: the packet is filtered when it is still in the NIC driver's memory, without copying it. This means that no copy is needed to filter the packet. The filter tells how many bytes of the packets are needed by the user-level application (for example WinDump needs only the first 68 bytes of each packet). The packet capture driver copies only this amount of bytes (instead of the whole packet) to the circular buffer. This is very important also because reduces the space occupied by the packet in the circular buffer that is used more efficiently. The selected packet is then copied to the user-level application during a read system call. Summarizing, there are two copies of the cut packet, none of the entire packet that is equivalent of the number of copies done by the UNIX version. 5. Each read system call implies a context switch from user-mode (ring 3) to kernel-mode (ring 0) plus another another to return to user-mode. This process is notoriously slow and can influence the capture performances. Since a user-level application might want to look at every packet on the network and the time between packets can be only a few microseconds, it is not possible to do a read system call for each packet. The packet capture driver collects the data from several packets and copies it to the application's buffers in a single read call. The number of packets copied is not fixed and depends on the dimension of the application's buffer that will receive the packets: the driver detects the size of this buffer, and copies packets to it until it's full. Therefore, it is possible to decrease the number of system calls increasing the size of the application's read buffer. 2. Tests This Section aims at giving some indications about the performance of the capture process on various operating systems. Results obtained under the various Windows platforms have been compared with the ones provided by BPF/libpcap/TCPdump in FreeBSD 3.3 in order to determine the goodness of our implementation. 2.1 Testbed The testbed (shown in next figure) involves two PCs directly connected by means of a Fast Ethernet link. This assures the isolation of the testbed from external sources (our LAN), allowing accurate tests. A Windows NT workstation using the 'TG' tool (available into the developer's pack) based on the packet capture device driv
Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
(Please don't spam this many lists with such a large message.) The test is pretty questionable. FreeBSD 3.3 is over a year old, and I would suspect that the one actual outstanding criticism here (filesystem latency) is probably due to the default synchronous-mode filesystem. A more valid test would use one of the 4.x family FreeBSD releases and soft updates. There are still plenty of things that could be done to further accelerate the system, but that's the one clear item here. > (Hurm Wintendo outperforming unix???!?? Something's > improper about this, and it ought to be fixed... :-) > Comments? Other OS numbers: more recent > FreeBSD versions? Solaris? Tru64? Optimization > patches? Can those OO MSDN lobotomies actually > be good things? Hurm... The Italian gauntlet has > been thrown down --dr :-) > > url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
: : :(Hurm Wintendo outperforming unix???!?? Something's : improper about this, and it ought to be fixed... :-) : Comments? Other OS numbers: more recent : FreeBSD versions? Solaris? Tru64? Optimization : patches? Can those OO MSDN lobotomies actually : be good things? Hurm... The Italian gauntlet has : been thrown down --dr :-) : :url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm Oh yah, I remember this... this is a pretty old benchmark, by the way. Sigh. All this demonstrates is that the person tring to write the packets to disk doesn't know what he's doing. There's nothing wrong with FreeBSD, per say. Looking at the data I would guess that they are appending to a file using write()'s on a packet-by-packet basis or with a redirect from tcpdump on a shell line, rather then spend the 60 seconds it would take to program-in some fairly trivial user-level buffering. The program is obviously stalling on the write and causing the BPF filter to overflow its output buffer. Just because FreeBSD refuses to use all available memory to buffer a single file's writes doesn't mean it's broken, just that the benchmark is. I'm guessing simply double-buffering the disk writeing with two dd's would be sufficient to capture all packets to disk and if someone seriously intended to use a FreeBSD box as a packet-capture system they would write a capture program to talk to the BPF socket directly and implement proper buffering in that rather then tring to use tcpdump. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
> > > > (Hurm Wintendo outperforming unix???!?? Something's > > improper about this, and it ought to be fixed... :-) > > Comments? Other OS numbers: more recent > > FreeBSD versions? Solaris? Tru64? Optimization > > patches? Can those OO MSDN lobotomies actually > > be good things? Hurm... The Italian gauntlet has > > been thrown down --dr :-) > > > > url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm > > I'm looking at this, FreeBSD seems to better on all accounts except > writing the packets to disk. > > Can any of the winpcap people explain exactly how they measured > the disk performance? > ... > Honestly, it really looks like the fault lies with the way tcpdump > writes to disk and not with FreeBSD. What I couldn't figure out from the url was if they were using dma for the disk. Maybe they were using it on Windows and not on FreeBSD? (On FreeBSD 3 you have to enable it with flags in the kernel config file.) Also they don't say if they have changed the debug.bpf_bufsize sysctl from its default smallish 4096 bytes. Those 2 things can make a huge difference. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
* Dragos Ruiu <[EMAIL PROTECTED]> [001207 21:18] wrote: > > (Hurm Wintendo outperforming unix???!?? Something's > improper about this, and it ought to be fixed... :-) > Comments? Other OS numbers: more recent > FreeBSD versions? Solaris? Tru64? Optimization > patches? Can those OO MSDN lobotomies actually > be good things? Hurm... The Italian gauntlet has > been thrown down --dr :-) > > url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm I'm looking at this, FreeBSD seems to better on all accounts except writing the packets to disk. Can any of the winpcap people explain exactly how they measured the disk performance? The graph's title is: "WinDump performance" under the section called "WinDump capture performance". I'm very curious how they managed to run "windump" on FreeBSD. I'd also be interested in at least getting a copy of their emulator. :) Honestly, it really looks like the fault lies with the way tcpdump writes to disk and not with FreeBSD. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On 7 Dec, Dragos Ruiu wrote: > > (Hurm Wintendo outperforming unix???!?? Something's > improper about this, and it ought to be fixed... :-) > Comments? Other OS numbers: more recent > FreeBSD versions? Solaris? Tru64? Optimization > patches? Can those OO MSDN lobotomies actually > be good things? Hurm... The Italian gauntlet has > been thrown down --dr :-) > > url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm > I'm not sure if we could find someone of this caliber to run the test again. For once I must agree with Mike Smith ;-) Clearly the page: http://netgroup-serv.polito.it/winpcap/ says, "partially sponsored by MicroSoft Research". IMHO, it bait -- bad bait at that. IMO, M$ has found some hole in the FreeBSD kernel and is intending to expose it. Although I suspect the hole's been cleaned up by now by core. If Terry Lambert can chimes in, I know we might get some real answers. I'm not convinced by this M$ agent. Jessem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
Im confused as to what difference it makes? No production server should ever use bpf for any "performance" oriented function anyway. Plus if you are doing network testing you should write to dev/null or a ram disk or better yet dump the packets rather than store them, Every disk will be different so you need to get that variable out of the equation. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [tcpdump-workers] Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On Thu, Dec 07, 2000 at 09:06:04PM -0800, Dragos Ruiu wrote: > (Hurm Wintendo outperforming unix???!?? Something's > improper about this, and it ought to be fixed... :-) > Comments? Other OS numbers: more recent > FreeBSD versions? Solaris? Tru64? Optimization > patches? As an experiment, changing BPF_MAXBUFSIZE to 1MB, and changing libpcap to use a 1MB buffer, on FreeBSD? (That might help the "whole packet dumped" test.) Somehow measuring how large the byte count in the capture file "write()" calls in FreeBSD and "WriteFile()" calls are? (FreeBSD is probably doing 8K writes, assuming it's writing to an 8K/1K file system; I don't know what block size the MSVC++ version of the standard I/O library uses, but it might well use bigger chunks than 8K.) > Can those OO MSDN lobotomies actually be good things? I'm not sure the parts of the OS that are actually involved are particularly object-oriented; I have the impression most of the COM, etc. stuff lives well up in userland on Windows. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
R: [Ethereal-dev] Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
ults. In particular, we saved every dump (under Win98,Win2k and freebsd) on the same fat32 partition, and tested tcpdump also with a kernel-buffer size of 2*512K. Moreover, we stressed the capture architectures with a more sustained traffic (until 83kpps). I don't attach the results to this message because they are in an 88k excel file, but I have not problems to send them to the people interested. They show that the cpu performance of winpcap for winNTx is now comparable with the one of freebsd and that freebsd has still lower dump performance, but saving on fat32 it is able to obtain better results and in a case (22000 500bytes packets per second) it is better than win2k. The really strange thing is that BPF seems not to perform noticeably better if a 1 megabyte buffer is used instead of the standard 64k buffer, and in some cases the 32k buffer performs even better. I wrote a message to the tcpdump mailing list (http://www.tcpdump.org/lists/workers/2000/msg01135.html) to ask about this behaviour, but I obtained no satisfactory answer. Finally, I would like to say that since I know we can't be considered very impartial, we would like to see other tests and evaluations on this subject, because we think it is a very important matter. We had to make a comparison with bpf because we didn't find any quantitative value on this subject before. If anyone obtained different results, please let us know. Loris. From: Dragos Ruiu <[EMAIL PROTECTED]> To : <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Subject: [Ethereal-dev] Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? > > (Hurm Wintendo outperforming unix???!?? Something's > improper about this, and it ought to be fixed... :-) > Comments? Other OS numbers: more recent > FreeBSD versions? Solaris? Tru64? Optimization > patches? Can those OO MSDN lobotomies actually > be good things? Hurm... The Italian gauntlet has > been thrown down --dr :-) > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
:> or with a redirect from tcpdump on a shell line,
:
:Assuming, as I suspect is the case, that they're using the same command
:on the OSes in question (or using "tcpdump" on FreeBSD and "windump" on
:Windows), that's also unlikely - it's just "{tcp,win}dump -w test.acp".
It amounts to the same thing, since -w does nothing more then an
fopen(..."w"). You get a pidly 8K buffer out of that, and it isn't
even double buffered.
But I think the last poster had it right... if the bpf buffer size
was not changed from the default 4096, just about anything can interrupt
the packet flow.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On Thu, Dec 07, 2000 at 09:47:20PM -0800, Matt Dillon wrote:
> Looking at the data I would guess that they
> are appending to a file using write()'s on a packet-by-packet basis
Unlikely, given that they're using "tcpdump", which, with the "-w" flag,
writes using standard I/O, and doesn't do "fflush()"es on a
packet-by-packet basis.
> or with a redirect from tcpdump on a shell line,
Assuming, as I suspect is the case, that they're using the same command
on the OSes in question (or using "tcpdump" on FreeBSD and "windump" on
Windows), that's also unlikely - it's just "{tcp,win}dump -w test.acp".
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On Thu, Dec 07, 2000 at 09:47:20PM -0800, Matt Dillon wrote: > Looking at the data I would guess that they > are appending to a file using write()'s on a packet-by-packet basis Or, as per my other mail, perhaps using, on Windows, a version of the standard I/O library that does bigger writes, hence fewer system calls. (That might require a bigger kernel buffer in the capture mechanism to keep the capture buffer from overflowing whilst you're busy copying data to file pages in the write, but, in fact, WinPcap is using a 1MB kernel buffer on Windows, rather than the 32K buffer that's used on FreeBSD.) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On Thu, Dec 07, 2000 at 11:39:58PM -0800, Guy Harris wrote: > Or, as per my other mail, perhaps using, on Windows, a version of the > standard I/O library that does bigger writes, hence fewer system calls. Nope. According to "strace for NT": http://www.securiteam.com/tools/Strace_for_NT_-_low_level_system_calls_tracer.html and the Windows(R) NT(R)/2000 Native API Reference: http://www.newriders.com/books/title.cfm?isbn=1578701996 it's doing 4K writes in the underlying NT system call "NtWriteFile()". I suspect that running the test on FreeBSD 4.x and tweaking libpcap to use a 512KB buffer might make a big difference here. At this point, we might want to limit followups to one or more of: [EMAIL PROTECTED] - for discussing changes to libpcap to allow the buffer size to be set from an application and/or changing the size it initially tries on BSD (the current version in CVS starts at 32768 and keeps dividing that in half until it finds something that works); [EMAIL PROTECTED], [EMAIL PROTECTED] - for discussing changes to allow the buffer size to be changes with BIOCSBLEN even if the BPF device is attached to an interface. (Both FreeBSD and OpenBSD have the maximum buffer size for BPF as 512KB in the top of the CVS tree; NetBSD still has it as 32K.) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On Thu, Dec 07, 2000 at 11:38:09PM -0800, Matt Dillon wrote: > It amounts to the same thing, since -w does nothing more then an > fopen(..."w"). You get a pidly 8K buffer out of that, and it isn't > even double buffered. > > But I think the last poster had it right... if the bpf buffer size > was not changed from the default 4096, just about anything can interrupt > the packet flow. (If "the last poster" suggested cranking up BPF_MAXBUFSIZE, that was me.) libpcap's default in FreeBSD 3.4 is 32768, not 4096 - 4096 is the kernel's default, but libpcap overrides that - but that's still significantly lower than 1MB. I'm curious whether there's any compelling reason why you can't do an SIOCSBLEN on a device that's already been attached to an interface; perhaps it could do a "bpf_detachd()" if it was attached to an interface, and then do a "bpf_attachd()" after changing the size. However, that would work only on systems with a modified kernel; an alternative would be to add an variant of "pcap_open_live()" that took a buffer size argument, which could be made to work on existing BSD systems (as well as many other systems - including Windows :-)). That wouldn't help, though, unless BPF_MAXBUFSIZE were cranked up; it's 524288 in 4.x - that happened in delta 1.21: Revision 1.21 / (download) - annotate - [select for diffs], Sat Jan 15 19:46:12 2000 UTC (10 months, 3 weeks ago) by phk CVS Tags: RELENG_4_BP Branch point for: RELENG_4 Changes since 1.20: +2 -2 lines Diff to previous 1.20 (colored) |The hard limit for the BPF buffer size is 32KB, which appears too low |for high speed networks (even at 100Mbit/s this corresponds to 1/300th |of a second). The default buffer size is 4KB, but libpcap and ipfilter |both override this (using the BIOCSBLEN ioctl) and allocate 32KB. | |The following patch adds an sysctl for bpf_maxbufsize, similar to the |one for bpf_bufsize that you added back in December 1995. I choose to |make the default for this limit 512KB (the value suggested by NFR). so it might be interesting to retry the tests on a 4.x system, with the 32768 in pcap-bpf.c changed to 524288. It might also be interesting to try throwing a "setvbuf()" call into libpcap, to crank up the standard I/O buffer size (although on systems with small kernel buffers in the capture mechanism, a large write *might* take enough time that you could fill up and then overflow that buffer). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [tcpdump-workers] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On Thu, Dec 07, 2000 at 09:51:42PM -0800, Alfred Perlstein wrote: > I'm very curious how they managed to run "windump" on FreeBSD. Presumably they're referring to tcpdump there, as per the first paragraph in "2. Tests": This Section aims at giving some indications about the performance of the capture process on various operating systems. Results obtained under the various Windows platforms have been compared with the ones provided by BPF/libpcap/TCPdump in FreeBSD 3.3 in order to determine the goodness of our implementation. > Honestly, it really looks like the fault lies with the way tcpdump > writes to disk and not with FreeBSD. Perhaps. However, from my stracing of windump on NT 4 SP4 and trussing of tcpdump on FreeBSD 3.4, the only difference appears to be that tcpdump does 8K writes and windump does 4K writes Currently, I suspect that it lies with the BPF kernel buffer only being 32K; that's the most you can get on FreeBSD 3.x, but you can crank it up to 512KB on 4.x - libpcap on 4.x only sets it to 32K, though. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
I do not agree with you. Partially supported by Ms Research means that we got: - software - 1 Dell workstation That's it. I *strongly* suggest to ask someone before opening your mouth. Cheers, fulvio PS As Loris said, we sent an e-mail to tcpdump-workers asking for that. We were really surprised by the poor performances of BSD. Anyway, no one answered. So, please... - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, December 12, 2000 3:36 PM Subject: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? > > > On 7 Dec, Dragos Ruiu wrote: > > > > (Hurm Wintendo outperforming unix???!?? Something's > > improper about this, and it ought to be fixed... :-) > > Comments? Other OS numbers: more recent > > FreeBSD versions? Solaris? Tru64? Optimization > > patches? Can those OO MSDN lobotomies actually > > be good things? Hurm... The Italian gauntlet has > > been thrown down --dr :-) > > > > url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm > > > I'm not sure if we could find someone of this caliber to > run the test again. For once I must agree with Mike Smith ;-) > > Clearly the page: > > http://netgroup-serv.polito.it/winpcap/ > > says, "partially sponsored by MicroSoft Research". > > IMHO, it bait -- bad bait at that. IMO, M$ has found > some hole in the FreeBSD kernel and is intending to expose it. > Although I suspect the hole's been cleaned up by now by core. > > If Terry Lambert can chimes in, I know we might get some > real answers. I'm not convinced by this M$ agent. > > Jessem. > > > > > ___ > Ethereal-dev mailing list > [EMAIL PROTECTED] > http://www.ethereal.com/mailman/listinfo/ethereal-dev > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On 2000-12-08 00:38 -0800, Guy Harris <[EMAIL PROTECTED]> wrote: > (Both FreeBSD and OpenBSD have the maximum buffer size for BPF as 512KB > in the top of the CVS tree; NetBSD still has it as 32K.) You can change both the default and maximum BPF buffer sizes at run time (affecting an subsequent open()) in FreeBSD: # sysctl -w debug.bpf_bufsize=32768 debug.bpf_maxbufsize=4194304 makes the default buffer size 32K and limits the size to 4MB, for example. There were further changes to the BPF kernel code suggested by the NFR folks, which do not seem to have made it into FreeBSD, though. The original patches were for FreeBSD-2.2.x, I ported them to 3.x, but there have been many changes to bpf.c since then ... I can dig out the old patch and accompanying rationale, if anybody is interested, since it has been removed from the NFR download area. Regards, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
In message <000701c06453$b2e83740$[EMAIL PROTECTED]>, "Fulvio Risso" writes: >I do not agree with you. >Partially supported by Ms Research means that we got: >- software >- 1 Dell workstation > >That's it. >I *strongly* suggest to ask someone before opening your mouth. >Cheers, > >fulvio > >PS As Loris said, we sent an e-mail to tcpdump-workers asking for that. We >were really surprised by the poor performances of BSD. Anyway, no one >answered. So, please... fulvio, did you write this paper? were you involved in some of the work? notice at the end of the article: Notice that WinDump has been launched with the standard kernel buffer (1MB); in presence of heavy traffic the size of this buffer can be increased with a simple command line switch, improving further the overall performance of the system. Our conclusions are that BPF architecture for Windows performs well, that the dynamic buffer improves effectively the overall performances and that, among all the Windows flavors, Windows 2000 is the best platform for an high performance network analyzer. and -- : 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... 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. 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. mts. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
Fulvio Risso wrote: > > I do not agree with you. > Partially supported by Ms Research means that we got: > - software > - 1 Dell workstation > > That's it. > I *strongly* suggest to ask someone before opening your mouth. Mr. Risso, you should know that jessem (who seems to be JMJr. in masquerade) is basially a cartoon character. The rest of us realize that Microsoft sponsorship of such a web site means you get their software for the same price we NORMALLY charge for ours, i.e. free. We appreciate your frank discussion of the performance of the two systems, but I have to wonder if you tried capturing data to a ufs filesystem. I found it a little strange that your FreeBSD captures were written to a FAT filesystem, my impression is that FAT performance has never been a goal of the FreeBSD project. Have you attempted the same benchmarks using an ufs filesystem, and if so, how did it perform? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On 12 Dec, Fulvio Risso wrote: > I do not agree with you. > Partially supported by Ms Research means that we got: > - software > - 1 Dell workstation > > That's it. > I *strongly* suggest to ask someone before opening your mouth. > Your tone strongly suggest your research is less than objective. Given that questioning technical ability is something I'll leave to someone else. It's not in my interest, nor is it benificial to continue discussion with yourself when you readily admit to being open to financial influences. I'll leave it at that and wish you well in life. best regards, Jessem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
R: [tcpdump-workers] Re: Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
> On 2000-12-08 00:38 -0800, Guy Harris <[EMAIL PROTECTED]> wrote: > > (Both FreeBSD and OpenBSD have the maximum buffer size for BPF as 512KB > > in the top of the CVS tree; NetBSD still has it as 32K.) > > You can change both the default and maximum BPF buffer sizes at > run time (affecting an subsequent open()) in FreeBSD: > > # sysctl -w debug.bpf_bufsize=32768 debug.bpf_maxbufsize=4194304 > > makes the default buffer size 32K and limits the size to 4MB, for > example. Notice however that in pcap-bpf.c, pcap_open_live() forces the buffer size to 32K through an IOCTL. This means that the sysctl is overridden if BPF is used throug libpcap. Loris. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
R: [tcpdump-workers] Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
-Messaggio Originale- Da: Michael T. Stolarchuk <[EMAIL PROTECTED]> A: Fulvio Risso <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: R: [tcpdump-workers] Re: Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On 2000-12-11 10:49 +0100, Loris Degioanni <[EMAIL PROTECTED]> wrote: > > # sysctl -w debug.bpf_bufsize=32768 debug.bpf_maxbufsize=4194304 > > > > makes the default buffer size 32K and limits the size to 4MB, for > > example. > > Notice however that in pcap-bpf.c, pcap_open_live() forces the buffer > size to 32K through an IOCTL. This means that the sysctl is overridden > if BPF is used throug libpcap. Yes, you are of course correct mentioning that ! The override used to up the buffer size from the kernel default of 4KB to 32KB, but now that the default has become 32KB, we probably should use the default as is and leave the user the option of choosing a different default by means of sysctl ... Regards, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: R: [tcpdump-workers] Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
In message <009801c065c0$a2bd1200$016464c8@lorix>, "Loris Degioanni" writes: > >-Messaggio Originale- >Da: Michael T. Stolarchuk <[EMAIL PROTECTED]> >A: Fulvio Risso <[EMAIL PROTECTED]> >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. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
R: R: [tcpdump-workers] Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
Hi. -Messaggio Originale- Da: Michael T. Stolarchuk <[EMAIL PROTECTED]> A: Loris Degioanni <[EMAIL PROTECTED]> Data invio: giovedì 14 dicembre 2000 16.39 Oggetto: Re: R: [tcpdump-workers] Re: R: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!? > > 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... Ok, but I was testing only the capture performance, without any other process running at user level. In this situation, increasing the size of the buffer from 32k to 1M should give considerably better performance. This happens regularly in Windows, but very strangely, does not seem to happen in freebsd. > >`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. Sorry, my phrase was not clear. I speak English like Tarzan... :-) I was trying to say that if you set the same buffer size in winpcap and in BPF, you will obtain approximately the same number of system calls, because the structure and the basic optimizations are the same. I say 'approximately' because this parameter is fixed in freebsd, while in windows it is possible to change it. However, standard buffer sizes are different, and I confirm that the buffer in windows is usually 1M. Notice that this size can be increased to bigger values without problems, and this seems to increase capture performance quite linearly. For example, on my Win2000 machine with 64M of RAM I am able to set a 40M kernel buffer, that grants very good performance when dumping to disk a 100Mbit ethernet. > 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. Measuring these values can be quite complex, and we are not sure to do it properly in freebsd. My opinion, however, is that the discrepancy in performance is due not only to the number of system calls, but also to architectural differences, for example: - BPF is optimized to use small buffers, winpcap for big buffers. The circular buffer architecture of winpcap is more efficient with a 1M buffer. - DMA (or polling) transfers from the NIC driver to the RAM are handled more effectively by Windows than by freebsd. > 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... Yes, it would be very intersresting. Another interesting thing, in my opinion, would be the development of a standard benchmark to measure the performance of a capture architecture/program. This would allow to test precisely and impartially a capture system, and to obtain acceptable comparisons/references among different systems. Anyone interested at working on this? Loris. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
