Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet Operating Systems Upgrades BSD

What's New in the FreeBSD Network Stack 169

Posted by CowboyNeal from the shiny-new-features dept.
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."
This discussion has been archived. No new comments can be posted.

What's New in the FreeBSD Network Stack More

What's New in the FreeBSD Network Stack

Comments Filter:

  • a.k.a. Project Evil (Score:5, Interesting)

    by Goyuix ( 698012 ) on Saturday September 04, 2004 @11:13AM (#10157443) Homepage
    NDIS Binary Compatibility

    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
    # /* Compile and install new kernel with "options NDIS" */
    # kldload intel0

    Man ndis(4), ndisapi(9), ndiscvt(

  • ?pps (Score:3)

    by BladeMelbourne ( 518866 ) on Saturday September 04, 2004 @11:14AM (#10157446)
    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...

    • Re:?pps (Score:2, Informative)

      by dave_f1m ( 602921 )
      packets per second

    • Re:?pps (Score:2, Informative)

      by bohnsack ( 2301 )
      Pakets per second.

    • Re:?pps (Score:5, Informative)

      by Shanep ( 68243 ) on Saturday September 04, 2004 @11:22AM (#10157483) Homepage
      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.

      • Re:?pps (Score:4, Informative)

        by FooAtWFU ( 699187 ) on Saturday September 04, 2004 @11:41AM (#10157573) Homepage
        It is usually high packets per second that brings a machine to its knees, as opposed to bits or bytes per second.

        Which is what you see in DoS [wikipedia.org]c attacks: stuff like SYN floods [wikipedia.org] and smurf attacks [wikipedia.org].

        • Re:?pps (Score:5, Informative)

          by Shanep ( 68243 ) on Saturday September 04, 2004 @11:59AM (#10157646) Homepage
          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.
        • I'm surprised we don't see more DoS attacks like the following:

          Connect to a web server from your botnet, and send the query line by line, with ~60 seconds between each line (IE 60 seconds, then send GET, 60 seconds, send User-Agent, so on). You could run an Apache server out of processes in no time, and there'd be no easy way to block what is going on, without also blocking legit traffic.

      • Re:?pps (Score:5, Interesting)

        by Homology ( 639438 ) on Saturday September 04, 2004 @12:37PM (#10157808)
        It is usually high packets per second that brings a machine to its knees, as opposed to bits or bytes per second.

        Indeed, in this is very you will see a very marked difference between low and high quality network cards. For instance, the common Realtek NIC offloads alot onto the CPU, and induce many interrupts. While high quality cards, like Intel gigabit, will do much prosessing on the card itself. A "ping -f" while using top can be instructive.

    • Re:?pps (Score:1, Informative)

      by Anonymous Coward
      the M and K dont need defining...

      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.

  • pps? (Score:1)

    by XO ( 250276 )
    I'm presuming that Mpps = Million Packets-per-Second
    and Kpps = Thousand Packets-per-second.

    Not exactly a standard notation that I've ever heard of, but I'll go with it.

    Great, now, let's see if you can actually GET a Million Packets in a Second just to the hardware, let alone to the software. Hmm.

    Now, correct me if I'm wrong, but to be able to RECEIVE that much data, in the smallest POSSIBLE TCP/IP packets, you would need 500Mbit network link. Sure, I realise that faster than 100Mbit exists, but it sur

    • Re:pps? (Score:5, Informative)

      by ryanmoffett ( 265601 ) on Saturday September 04, 2004 @12:16PM (#10157708)
      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.

      • Re:pps? (Score:5, Informative)

        by Shanep ( 68243 ) on Saturday September 04, 2004 @12:52PM (#10157888) Homepage
        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.

        • Packets per second says a lot about the stack, bits per second says more about the interface driver.

          Packets per second says alot about the NIC as well. Use one of those cheap (cheap, like in bad quality) Realtek cards, and do a "ping -f" while watching top. See the CPU usage increase alot. Now, try some better cards, and you don't see the same.

          • Re:pps? (Score:5, Informative)

            by Fweeky ( 41046 ) on Saturday September 04, 2004 @03:30PM (#10158550) Homepage
            From FreeBSD /usr/src/sys/pci/if_rl.c [freebsd.org]:
            * The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is
            * probably the worst PCI ethernet controller ever made, with the possible
            * exception of the FEAST chip made by SMC. The 8139 supports bus-master
            * DMA, but it has a terrible interface that nullifies any performance
            * gains that bus-master DMA usually offers.
            Hopefully RealTek have improved matters with their more recent offerings, especially with the new consumer level GigE chips, one of which I'm using right now...

            • Re:pps? (Score:2)

              by XO ( 250276 )
              Hmm. My server has 3 RT8139's in it.

              Perhaps the Linux driver handles it better.. (this is a 486sx/33 that is hammered by doing routing for anywhere from 3 to 10 other computers, email services for a whole metric arseload of accounts that receive a ton of spam a day..) still pulls out around 80-95Mbps on transfers within the network, and gets me up to the max 3Mbps incoming speed for Internet usage.

              I'm happy with my RT8139's :)
              • you have a 33 MHz box that pulls 90Mbps of traffic ? I'm impressed ....
              • I dunno; the only reference I can find comparing them is this [scyld.com], where the FreeBSD driver is said to be using a faster technique. What's your system load when network's saturated?

                My machines all have NetGear FA311's, which seem to hasis0: Applying short cable fix (reg=5)ve a few of their own problems, but at least they don't have pages of pained commentary in their drivers on how awful the developers think the hardware is ;)
              • You've got PCI slots in that 486SX/33 ? That is not that common.
            • * It's impossible given this rotten design to really achieve decent
              * performance at 100Mbps, unless you happen to have a 400Mhz PII or
              * some equally overmuscled CPU to drive it.

              That being said, wow, that's a truly awful design.

              --Dan

    • Great, now, let's see if you can actually GET a Million Packets in a Second just to the hardware, let alone to the software. Hmm.

      When I worked at Chiaro, we routinely handled saturated optical GbE links as part of testing. Of course, these didn't handle bulk data traffic, just the routing protocol updates :-> for the control processor(s) for the real router, which was all optical. I forget how many hundred OC-192 (10 Gb/s) ports it could handle.

      My job there involved, among writing and backporting GbE

    • Re:pps? (Score:3, Insightful)

      by psyconaut ( 228947 )
      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
    • common? in the mac community, powermacs (and some powerbooks) have had gigabit ethernet as standard and the rise of feature rich mobos (quick - here's SATA raid, 2 channels of ATA raid, a dancing lemur, and gigabit ethernet) are making it steadily more common.
    • It's not a question of actually doing 1 million packets per second, it's the efficiency that gives it the POTENTIAL to do 1 million packets per second that's important. This gives everything else that much more time to do what they need so the same hardware can do MORE work.

  • Heh (Score:1, Funny)

    by k4rm4_p0l7c3 ( 583281 )
    Nice throughput- so how long before MS implements it in Longhorn or XP ? :D

    • Nice throughput- so how long before MS implements it in Longhorn or XP ? :D

      As long as OpenBSD and OSX get it, I'll be happy.

      The BSD's look pretty lively to me (he says, sitting in his OpenBSD shirt).

    • Re:Heh (Score:3, Insightful)

      by rtaylor ( 70602 )
      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.

      • 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.

        • Re:That's exactly the point (Score:2, Insightful)

          by Anonymous Coward
          Sometimes I'm amazed by Linux developers humbling asking to use my software. "Go right ahead," I tell them, "That's why I put it under the BSD license!" But they still don't get it. While I appreciate the asking, it still find it strange that I get an email about once a quarter asking me to release my BSD licensed work under the GPL so it can be used in GPL projects.

          I guess it's hard for users of a "members only" license to grok the concept of "free for everyone".
          • Part of it is etiquette, and the other part is some BSD license fanatics who insist their software can not be relicensed under the GPL. By asking, even if you can fairly safely assume the answer is yes, you avoid nasty situations like that. Most of the people who support the BSD license are reasonable just like most of the people who support the GPL license are reasonable. It's the extremists that are a bit of a problem.
            • Any of the newer BSD licenses is GPL compatible, so you can relicense it to the GPL as you please, no permission necessary. This is the same as a company "stealing" the code and selling it in a commerical product.

              GPLing BSD code doesn't really "protect" it though. You can't strip the copyright notice off, so anyone that wants to use it can find out where it came from and grab the original to use however they like. It protects any changes made to the GPLed version, but those changes can't be released into t
              • It protects any changes made to the GPLed version, but those changes can't be released into the BSD licensed original either.

                Part of the reason for the etiquette is to arrange things so that if the changes are worthwhile they will be released into the BSD licensed original. Being easy to fork does not mean that it's desirable to fork. Whatever is desirable in a fork stands a much higher chance of survival if it is incorporated into the main line that if it orphans itself. If the main-line is BSD licensed,
            • 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.

              • 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.

                Not everybody always uses the most precise language in informal contexts such as Slashdot. In colloquial discussion of free software, to "relicense" a work means to distribute a derivative work under a different license, often from permissive to GPL or the like.

    • Never? Microsoft has long since replaced the BSD TCP/IP stack with their own.

      • Still doesn't mean Microsoft can't borrow some of the cheats used in FreeBSD's drivers in a future version of Windows's stack or (less likely) go back to a BSD stack.

    • What'd really be funny is if MS replaced their own NDIS guts with the BSD implementation, since (*big assumption*) MS created NDIS for themselves.

  • Sounds great (Score:1)

    by Anonymous Coward
    This is just another proof on the superiority of the freebsd tcp-stack. I can't wait for a full benchmark between 5.3 (or 5.4, too much changes on 5.3 might not work just wounderfully right now) and the linux kernel.
    • I'm too itching for real benchmarks for packet receiving, routing, switching as a bridge etc between the BSDs including both FreeBSD 4 and 5.x, and Linux and the rest, including maybe cisco 2600 routers.

      For some reason, I dont think cisco or Microsoft would fund such studies.

  • WIll this make it to Mac OS X? (Score:3, Interesting)

    by AIXadmin ( 10544 ) on Saturday September 04, 2004 @01:28PM (#10158045) Homepage
    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.
  • Reading through the presentation I realised I'll be reinstalling my FreeBSD firewall again after 5 becomes officially STABLE, heh.
    Yes, I always do a fresh install and not an upgrade.

  • We survived a DoS on .edu network (Score:4, Interesting)

    by agent dero ( 680753 ) on Saturday September 04, 2004 @04:18PM (#10158747) Homepage
    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.

  • About FreeBSD and Mac OS X (Score:2, Informative)

    by Anonymous Coward
    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:// [kernelthread.com]

  • Comment removed (Score:3, Informative)

    by account_deleted ( 4530225 ) on Saturday September 04, 2004 @10:22PM (#10160330)
    Comment removed based on user account deletion

  • Seen in Slide 21 in the PDF file....
    • Compressed TIME_WAIT2 State

      TCP connections in TIME_WAIT2 state (connection closed) waiting for the 2MSL timeout maintain only a minimal set of necessary information instead of a full blown TCP control block. This saves about 80% memory per connection in that state. Especially for HTTP servers this give a far better kernel memory resource usage and a higher number of concurrent connections that can be served within a short time frame ("Slashdot effect").

    ... so

Slashdot Top Deals

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Close