What's New in the FreeBSD Network Stack
jjgm writes "As FreeBSD 5-STABLE approaches, Andre Oppermann has produced a high-level presentation on the changes to the FreeBSD 5.3 network stack. There are many clever tricks for performance and scalability. Amongst other things, Andre claims that FreeBSD can now route 1Mpps on a 2.8GHz Xeon whilst Linux can't do much more than 100kpps."
NDIS Binary Compatibility
/* Compile and install new kernel with "options NDIS" */
FreeBSD i386 can use binary Ethernet and WLAN network drivers written to the
Windows XP NDIS 5.1 specification. It is a little cumbersome to convert a NDIS driver
into a FreeBSD Kernel Loadable Module (KLD): (By: wpaul)
# ndiscvt -O -i neti557x.inf -s neti557x.sys -n intel0
#
# kldload intel0
Man ndis(4), ndisapi(9), ndiscvt(
All this talk of Mpps and Kpps is making my need to pee more urgent.
Can someone explain what the 'pps' means? the M and K dont need defining...
I know you're being funny -- but I think the answer most of us would have is "Hopefully not too long".
If those changes made it into every OS that could use the improvement, then everything networked would find things just that much better without throwing away the old hardware.
Rod Taylor
Actually, pps (packets per second) is a quite common if not misleading statistic spewed by networking equipment vendors, and has been for years. Packets-per-second doesn't really tell you the characteristics of the packets being sent. One interpretation might be the following:
The minimum ICMP packet size with Ethernet II encapsulation is 46 bytes. The minimum TCP packet size with Ethernet II encapsulation is 54 bytes. So, 1000000pps of 46 byte ICMP is 368 megabits/sec. And, 1000000pps of 54 byte TCP is 432 megabits/sec. Both of these figures seem realistic to me.
Now, the maximum length of an Ethernet II packet, regardless of any upper layer protocols is 1514 bytes. 1000000pps of 1514 bytes is 12.1 gigabits/sec. Obviously, that packet size isn't what they were referencing.
In respect to the link speed, a 1000Mbit or a Gigabit Ethernet link is quite common these days and the above minimum packet size stats aren't out of line.
Actually, on both OS's with a larger packet size, and thus a lower amount of packets-per-second, a decent machine with 66mhz PCI Gigabit NICs can easily route 500mb/sec through the box.
Packets-per-second doesn't really tell you the characteristics of the packets being sent.
No it doesn't, however, being capable of sustaining 1 million packets per second, even if they are the smallest packets possible, is pretty impressive.
The packets have to each be serviced, so at around the same line bandwidth, smallest packets could be coming around 30 times more frequently than the largest packets.
Lots of small packets tend to be more taxing than much fewer large packets.
The fact that there is perhaps a 10 fold difference in performance ceiling between Linux and FreeBSD, should show that this is not a simple bandwidth limit. I would go so far as to say that bits per second can be more misleading than packets per second if used alone or in an inappropriate context.
Packets per second says a lot about the stack, bits per second says more about the interface driver.
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
The more interesting thing for me is: Will these enhancements make it to Mac OS X?
As far as I am concerned, the closer Mac OS X under the hood, makes itself closer to FreeBSD the better.
your ignorance is great, pf is already ported to FreeBSD for quite some time as a kernel loadable module, and it will be integrated with 5.3-RELEASE. Have you copy-pasted a FreeBSD flaming text a year old ?
Please.
When even my laptop has 1Gbit networking built-in, I'm not sure how you can say "faster than 100Mbit exists, but it sure isn't common".
And Mpps is a standard notation for packet forwarding....FYI.
-psy
You GNU/LNUX zealots with your NIH syndrome. Nothing on earth beats OpenBSD for firewall usage, not even your piece of shit netfilter thing. When it comes to performance FreeBSD and DragonFlyBSD win hands down. But don't worry, you still get the hype.
The BSD networking stack or some sort of clone thereof is in use on every modern operating system in the world. TCP/IP was originally made on BSD. Try opening ftp.exe on Windows in Notepad. Yep, there it is. Copyright Regents of the University of California. It's everywhere. Even the paradigm of sockets is everywhere. BSD defines networking.
Also, features lead to bloat, the opposite of "high-performance" so your argument needs further detail to be of any credibility.
I read some comments on "it is likely you'll be able to through Mpps at it?"
YES, it's happened to us, here on our university boxen, somebody got r00ted, and _crackers_ got in through some backdoors on a LOT of machines, then started DoS'ing my department, we have a small P-II 5.2.1 box tossing packets like nobody's business.
When the college network runs mostly Gigabit, Mpps is a plausible measure of connectivity.
Error 407 - No creative sig found
You've got it. Unlike what is perceived from Linux (all software must be free), BSD is about making all software better. That's the benefit of the BSD license that many people (usually GPL fans) don't understand.
The best way to predict the future is to invent it
Sadly it seems that people here are very ignorant about the connection between FreeBSD, and Mac OS X, especially where the Mac OS X kernel is concerned. There are a few people here that are claiming that there is not FreeBSD code in the Darwin kernel, only in the Mac OS X command line apps, and this is blatantly untrue.
In order to better see just how much FreeBSD code there is in the Darwin/Mac OS X kernel, and how relevant this work in FreeBSD will be to Mac OS X, please read the following links:
http://www.kernelthread.com/mac/osx/
http://gobsd.com/code/darwin/xnu/
http://www.apple.com/ca/macosx/features/darwin/
http://developer.apple.com/darwin/
Seriously, with so much documentation available, it's unacceptable for supposedly technical people involved with BSD to not know just how important BSD code is to the kernel of a very nice, and hardly secret or obscure operating system like Mac OS X.
Comment removed based on user account deletion
/*
s rc /sys/sys/socketops.h?rev=1.5&content-type=text/x-c vsweb-markupi ts+hsu&btnG=Go ogle+Search&domains=leaf.dragonflybsd.org&sitesear ch=leaf.dragonflybsd.orgd .org/mailarchive/kernel/20 04-07/msg00121.html
* Copyright (c) 2003, 2004 Jeffrey M. Hsu. All rights reserved.
*
* License terms: all terms for the DragonFly license above plus the following:
*
* 4. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
*
* This product includes software developed by Jeffrey M. Hsu
* for the DragonFly Project.
*
* This requirement may be waived with permission from Jeffrey Hsu.
* This requirement will sunset and may be removed on July 8 2005,
* after which the standard DragonFly license (as shown above) will
* apply.
*/
http://www.dragonflybsd.org/cgi-bin/cvsweb.cgi/
http://www.google.com/search?q=comm
http://leaf.dragonflybs
This took a total of 2 minutes to find.
Why not use google next time before looking like a flaming linux jackass?
Please point out an example where DFBSD doesn't attribute correctly. I think you won't find any. (and if you do, please mail the kernel-list, since the dfbsd crew is very strict about that)
I suppose you mean getopt_long and not getopt (which IIRC originated in BSD). I suspect that if you use BSD for a while, you may find that you have less need to for the --long-options because the documentation is usually much better on BSD systems (and not suffed into those atrocious info files). If you value terseness or you have to write portable shell scripts, then you probably won't want to use the --long-options anyway.