Slashdot Mirror

← Back to Stories (view on slashdot.org)

ATM Adapters for Linux?

Posted by Cliff on from the penguins-on-reasonably-fast-pipes dept.

Raxxon asks: "I've been working with some guys in my company laying the groundwork for our next phase of network upgrades. We're looking at having an ATM feed for the main pipe but we're unsure of the Linux ATM support. I know that the firewall code is good (and plentiful) and that for an Ether/Ether or Ether/WAN (frame, DSL, etc) it's great, but with limited knowledge of how well Linux handles ATM, I'm a bit worried about suggesting this as an interface on the router/firewall given that we can convert it back to Ethernet (and in 60% of the case, it's going to stay ether anyway). What's the current state of Linux ATM and is it really worth it?"

2 of 62 comments (clear)

  1. Re:From the grooveyard of forgotten classics... by Anonymous Coward · · Score: 1, Funny
    ATM doesn't even perform error checking on its packets - i.e. ATM freeloads off the software error checking way up the TCPIP stack
    Neither does Frame Relay or HDLC. Ethernet is better in that it detects errors anywhere in the packet, but it still doesn't correct them. The hell with speed! Everyone should use X.25 for everything. Now that we're enlightned we realize that we don't want faster, cheaper networks! What we really want is networks that perform packet level error checking so that that IP stack doesn't need to do it.

    TCP is going to do the checks anyway (and UDP protocols like NFS are doing their own checks also), so why introduce the additional latency, complexity and cost by doing it on mediums that are largely error-free???

    Let me guess. You just got CCNA, right? Or perhaps you're one of the experts who sign all of your e-mails with CCIE-Written?

    Dork.
  2. Re:From the grooveyard of forgotten classics... by Anonymous Coward · · Score: 1, Funny
    And maybe you're one of those turds who doesn't realize that a hardware based solution is INFINITELY faster than a software based solution.
    Now stop and think about that for a second.
    The ethernet chipset performs its checksums in hardware, on the chipset, and rejects all the bad packets without sending them down the bus and into the general purpose processor.
    But TCP is still performing checksums. And Ethernet still isn't correcting error frames, so TCP is still doing it. Dropped packets still go unretransmitted (like in ATM) making retransmit messages go all the way back down the bus and out the network interface [where the error should have been caught in the first place]. So this is better than ATM how? To me it sounds like you're still confusing Ethernet with X.25.

    Stop and think about it. How many error packets are you seeing on your Ethernet interfaces? Not that many I bet. How many error packets do you found on ATM interfaces? Even less. A handful perhaps, and then only if the link has been up a really long time. Still think checksums are that important?

    Stupid CCNA Jerkwad.