Slashdot Mirror
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."
packets per second
Pakets per second.
Packets Per Second.
It is usually high packets per second that brings a machine to its knees, as opposed to bits or bytes per second.
If you had a given amount of sustained data coming into a machine, it would typically be much less taxing if those packets where large, as opposed to the same bandwidth being used up with very small packets.
Packets are variable length and a single packet will be much larger than a single byte.
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
Which is what you see in DoSc attacks: stuff like SYN floods and smurf attacks.
The World Wide Web is dying. Soon, we shall have only the Internet.
Which is what you see in DoSc attacks:
Yes. A DoS should be most effective with the smallest packets you can send.
stuff like SYN floods
SYN floods work by requestion permision to statefully connect, without then going through with replying to the handshake that is sent back. When done over and over, this eventually fills the table of half-connections, which in turn prevents the initiation of any more connections and thus a denial of service.
The fact that these packets are small, is coincidental to this discusion. In other words, SYN floods don't work because the packets are small, they work because completing the required handshake sequence is not done.
and smurf attacks.
Ahh, DDoS of lots of little packets, via simple spoofing. What fun.
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
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?
For those that don't know, M is an abreviation for the prefix "Mega" which means 10^6 (1 million). K stands for Kelvins, a unit of measurement for temperature where 0K is absolute 0.
Unlikely.
a) While MacOS X libraries are from FreeBSD, Darwin (the kernel) is Mach derived and has very little to do with the FreeBSD kernel. The same tricks might work if they were ported, but that would be more of a rewrite with the same concepts rather than a port.
b) Who in their right mind uses MacOS X for routing? Serving, fine, but actual network infrastructure? I highly doubt it.
I rarely criticize things I don't care about.
The networking functionality of Mac OS X is in fact derived from BSD, FreeBSD in particular. There is actually a fair bit of FreeBSD kernel stuff in the Mac OS X kernel, and you can see this in the Darwin source code:
http://gobsd.com/code/darwin/
http://gobsd.com/code/darwin/xnu/bsd/
http://gobsd.com/code/darwin/xnu/bsd/net/
While MacOS X libraries are from FreeBSD, Darwin (the kernel) is Mach derived and has very little to do with the FreeBSD kernel.
That's not true. The FreeBSD network stack is used in Darwin with a compat layer. Look at OpenDarwin's cvsweb for an example.
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.
While I am mostly in agreement with you about Linux being crap compared to OpenBSD security wise, your statement regarding nothing beating OpenBSD as a firewall is pure bunk.
i d=466&lang=en
The Sidewinder G2 firewall implemented on top of "Secure OS" (a BSDi derived OS developed by the people who co developed the technology used by the NSA's "Security Enhanced Linux" has not yet been compromised, and has recently achieved full EAL4+Common Criteria (CC) certification. It is unlikely that OpenBSD will ever do that.
Had I the money, I would use nothing else myself, as Secure OS is *Hard Core* Military grade security built into a BSD OS.
http://www.securecomputing.com/news_display.cfm?n
Read. Learn. Grow.
Comment removed based on user account deletion
It might not be required but it is at the very least part of proper social interaction. You don't just "steal" bits from somewhere else and include it in your own *BSD project.
Now concerning the case of the DragonFly network stack, Hsu's chooses to use a time-limited advertisement clause for his code. That's his very own right to do. IIRC the reason was exactly the goingons with certain FreeBSD commiters not willing to correctly attribute his and others changes.
Actually you CANNOT relicense BSD code under the GPL. I don't think you understand what "relicense" means. It means to remove the BSD license from the code completely. No Open Source license allows relicensing.
What you can do, however, is to redistribute BSD licensed code under the GPL. You can also license your own derivative works under the GPL. But you certainly may not take BSD licensed code and file off the license.
Don't blame me, I didn't vote for either of them!