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.
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:
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?
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.