Slashdot Mirror


ATM Adapters for Linux?

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?"

62 comments

  1. better question by passthecrackpipe · · Score: 0

    What is the state of ATM, and is it worth it? I have worked with ATM several times, and keep coming back to the basic opinion that it stinks. Just like Token Ring stinks.

    --
    People who think they know everything are a great annoyance to those of us who do.
    1. Re:better question by isorox · · Score: 0, Troll
  2. From the grooveyard of forgotten classics... by Anonymous Coward · · Score: 1, Interesting

    A while back [maybe 1997/1998], there was one of those glossy magazines [in the ComputerWorld/InfoWorld/InformationWeek genre] that did a HUGE review of ATM cards [like 25 or more], on a huge variety of OS's [NT, NetWare, OS2, etc.] and concluded they ALL sucked, and refused to endorse any of them.

    Since I can't even remember the name of the now defunct glossy magazine, I'm not doing you much good, but after reading the review, I've always been prejudiced against ATM on the desktop.

    Then I was talking to my cousin, who, back in the day, was a big muckety-muck with Juniper [he cashed out shortly after they went public], and he pointed out to me that ATM doesn't even perform error checking on its packets - i.e. ATM freeloads off the software error checking way up the TCPIP stack. [Remember, classical ethernet gives you both a hardware checksum at layer 2 and the software checksum in the TCPIP stack.]

    The final thing you need to now about ATM is that its greatest proponent was one Albert A "Arnold?" Al-Gore. 'Nuff said.

    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: 0

      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.

      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.

      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. Without the ethernet chipset acting as a gatekeeper, the bad packets have to go all the way up into the software protocol [typically the TCP stack], and then the software protocol has to send its rejection message all the way back down the bus and out the network interface [where the error should have been caught in the first place].

      Fuckwad.

    3. 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.
    4. Re:From the grooveyard of forgotten classics... by Anonymous Coward · · Score: 0

      Nice flamefest... But why haven't either of you pointed out the *rationale* behind leaving error handling to the IP stack?

      ATM was intended for telecom applications. When you're dealing with voice data - or lots of other types of realtime streams - you don't need or *want* error checking on the bulk traffic; the endpoints need *something* to play back out of the handset, and they need it *now.* Lots of applications require a realtime guarantee more than an accuracy guarantee.

      Now, while using INTARWEB PROTOKAL, well - there you go, TCP is ONE OF MANY protocols you can choose from atop IP, should you care about your data integrity. Of course, very few parts of the Internet infrastructure at large offer anything approaching a timing guarantee, but now that RAM for buffers has become cheap, 100ms latency with the occasional non-deterministic spike can be acceptable for a lot of applications... including telephony that's far better than 'good enough,' if you're *not* conducting error checking and retransmittals just to avoid the rare-ish chance of 'scratchiness on the line.' (Video feeds are much the same way, though with MPEG, any data corruption is going to smear around until the next keyframe. Still, better that on your wartime coverage than 'Buffering...')

    5. Re:From the grooveyard of forgotten classics... by Cato · · Score: 1

      I have news for you - IP and Frame Relay don't do per-packet error checking either, and that's a *feature*. One big innovation introduced by Frame Relay when it superseded X.25 was precisely this dropping of link level error checking - the point being that digital lines were reliable enough that it wasn't a problem to only do error checking end to end. X.25 people still say it's better to do this but it proved expensive and slowed down the switch hardware.

      ATM has many issues including complexity, switches that drop on a per cell basis not per frame (i.e. you lose one 53 byte cell but forward all the other cells from the packet all the way across the network), and so on. These days, many carriers are not investing in more ATM infrastructure, but are doing ATM traffic over Juniper or Cisco type routers, using 'MPLS Layer 2 VPNs' to carry the traffic. MPLS is not quite up to ATM QoS and traffic engineering (for resilience and network utilisation) but it's getting quite close.

    6. Re:From the grooveyard of forgotten classics... by afidel · · Score: 1

      This matters because bogus packets can be dropped without being passed to other routes, also failing/messed up interfaces can be taken down programatically. Knowing that you are having an error condition can be VERY usefull.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
  3. Possibly up to the task... by ComputerSlicer23 · · Score: 4, Informative
    Well, I know that there have been ATM drivers in the kernel since 1.2 series at least (when I started using Linux). I believe that there are any number of comercial routers based on linux which do ATM. The old LRP (Linux Router Project), always talked about how you could use it to do anything from ATM to dialup banks, to firewalling. That it could handle a T1, or ATM if you had the proper card.

    LRP died a while ago (at least thats the impression I get), and some guys followed it up with LEAF. I'd check that out. I believe it's leaf.sourceforge.net.

    I have no idea where you would get cards for it, but I'd buy 3 or 4 of them (to have redundant cards, and a one in a failover machine). I'd imagine the leadtime on a part like that could be a bit brutal (it's not like you just go pick one up down at the local CompUSA). So it's at least a day out, possibly two at the soonest.

    If the driver is good, Linux is easily up to the task of doing nearly anything you want it to in terms of routing. Other then the proprietary Cisco protocols, it does nearly everything other good routers can on similar hardware.

    Kirby

    1. Re:Possibly up to the task... by MerlynEmrys67 · · Score: 4, Informative
      If the driver is good, Linux is easily up to the task of doing nearly anything you want it to in terms of routing. Other then the proprietary Cisco protocols, it does nearly everything other good routers can on similar hardware.

      Well the last point is correct - on similar hardware. However many times when you start wanting to go fast (and by fast I mean multiple Gig interfaces, General Purpose Hardware just doesn't cut it... The PCI bus (and by that I mean PCI-X or PCI-EXPRESS) is not fast enough to handle the traffic, so your box can not keep up with the interfaces.

      Linux works well as a replacement for low end routers, a handfull of 100Mbit interfaces... but if you are talking a real router with several 1Gbit interfaces and a couple OC-12/OC-48 connections out to the real world - General Purpose Hardware just won't cut it, and you need to get a real router from a company that has spent the bucks developing the ASICs and cross connects to handle the throughput for you

      --
      I have mod points and I am not afraid to use them
    2. Re:Possibly up to the task... by cybermage · · Score: 1

      Well the last point is correct - on similar hardware. However many times when you start wanting to go fast (and by fast I mean multiple Gig interfaces, General Purpose Hardware just doesn't cut it.

      I couldn't agree more. If you find support for ATM under Linux it is most likely done for the sake of doing it or to run on hardware designed to be a router. ATM only makes sense when you're shoving around LOTS of traffic. It's one thing to use PCs for routers when you're talking traffic up to a few Mbits. After that, as he said, the hardware will become the bottleneck no matter how good the software support.

      If you're building your own WAN with low traffic, but want to route it using a link layer protocol, try frame-relay. I think it's easier to understand and implement.

    3. Re:Possibly up to the task... by ComputerSlicer23 · · Score: 4, Informative
      Yeah, I just got my first set of Gigabit cards a while back... You are way out of my realm of experience. Linux can easily route a T1, probably could do a T3. It can route simple situations pretty darn fast. Two network cards, anything that comes in on one gets passed to the other, modulo a spoof filter.

      I really meant it could do BGP/OSPF and get you real redundant backup links. It can easily do the Multi-homing. It can easily do all the filtering. It can easily do stateful firewalling (with 2.4 at least). It can do pretty sophisticated IP configuration (local/global IP's/Links, the same IP on several cards). It can do policy routing. It can do bandwidth shaping. It can do channel bonding. It can do redundant failover (vrrpd). It can do VLAN's. It can do VPN. It can do IPv6. I can do IPSec (with patches). It can do tunneling. It can do virtually anything you want it to, that involves relatively low bandwidth. If you are talking about slower then T3 speeds, and you trust the Linux drivers for your hardware, there is very little need for Cisco equipment. I wonder when someone will finally build out the hardware and put Linux on it, and leverate Linux as the software and give Cisco a run for their money.

      Kirby

    4. Re:Possibly up to the task... by Creepy+Crawler · · Score: 1

      You're right in what features Linux networking syssection has. The features scale up to what Packeteer has (20000$ piece of equip).

      Still the statements about the PCI architecture doesnt have enough bandwidth is 100% correct. Even 64Bit PCI cannot handle more than 2 or 3 of those cards. There's just not enough PCI bandwidth to keep a gigabit card buffers full.

      --
    5. Re:Possibly up to the task... by Raxxon · · Score: 1

      Last I checked the PCI bus (when in 64Bit mode) was capable of multi-gigabit speeds. Given that I'd be looking for a single OC3, possibly a dual, there should be NO problems with it.

      Heck, from what you're saying I can do 66% the number of 100Mbit feeds if I stick with OC3 just fine.... ;) it's only 155Mbit at that point. If I were talking about OC12 or 48... *shudder* That's just damn scary.

    6. Re:Possibly up to the task... by Cato · · Score: 1

      I don't believe Linux does everything that Packeteer does (TCP rate shaping etc, which is per-flow based and fiddles with ACKs etc). However, if you want the equivalent of what most people use Cisco routers for, including full routing and QoS, you should be fine. A suitable routing oriented distro would be best - or you can just buy Imagestream routers which are 'like Cisco' in capabilities but fully Linux based.

  4. hmmm.... by Anonymous Coward · · Score: 0

    are you really sure you want Linux to work with bank ATMs? You would at least expect something as secure and reliable as Windows to do that. Money from a Linux ATM might funnel itself quickly into the account of...

    oh wait, you meant Asynchronous Transfer Mode. never mind......

  5. I was about to just suggest OS/2 by dacarr · · Score: 1

    Considering you said ATM, my first thought was Automated Teller Machines - which run on an OS/2 package.

    --
    This sig no verb.
    1. Re:I was about to just suggest OS/2 by ArmorFiend · · Score: 1

      Yeah me to, what the heck does it stand for in this context?

    2. Re:I was about to just suggest OS/2 by phaze3000 · · Score: 1

      Asyncronous Transfer Mode

      --
      Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
    3. Re:I was about to just suggest OS/2 by Raxxon · · Score: 1

      The good thing about that is, I haven't seen an ATM BSOD. :)

      I actually saw a guy working on one a year or so back. Kinda supprizing that it's OS2 behind the scenes there.

    4. Re:I was about to just suggest OS/2 by sxpert · · Score: 1

      I have a pic of an atm running win95 that had the banking application (written obviously with MSC++) crashed

    5. Re:I was about to just suggest OS/2 by Anonymous Coward · · Score: 0

      Where? I don't see it...

  6. Linux ATM works by doozer · · Score: 4, Informative

    In later 2.4 and 2.6 kernels, alot of stuff was cleaned up, and it
    works quite well now.

    Interphase makes a couple of fairly nice cards (the 5575 and 5576)
    that work under linux.

    1. Re:Linux ATM works by gnuage.cowboy · · Score: 1

      Great now SCO will take credit for THAT too! :-p

      --
      Yeah, I'm city livin' chillin' but I'm country at heart...
    2. Re:Linux ATM works by Raxxon · · Score: 1

      I'll have to check them out...

      Has anyone used these cards that can give direct feedback on their quality/durability/usablilty?

    3. Re:Linux ATM works by doozer · · Score: 1

      I've only been using them for a few months, so I'm not sure of the long term durability of them.

      There are drivers in the stock kernel for the 5575, and Interphase supplies half-and-half
      drivers for both the 5575 and 5576 which work even better (and support stuff like VBR and
      the failover capabilities of the 5576)

      The 5575 can do 4096vc while the 5576 with full memory can do 64k. The 5575 only supports using a
      single PVC at a time, while the 5576 is a little more flexible.

      Driving the 5576 at line rate using the interphase driver is no problem. We use them to do
      IP traffic via IPIP tunnel to PPPOEOATM re-encapsulation and have no problems with the cards.

      The interphase drivers also come with some interface utils, although the standard utils work
      fine also.

    4. Re:Linux ATM works by Raxxon · · Score: 1

      If you don't mind me asking, how much did you blow on the cards?

      I've looked at their website and can't find any pricing info, and no one is around to ask till Tuesday. ;)

    5. Re:Linux ATM works by doozer · · Score: 1

      I'm not sure, i wasn't involved in buying them, but I heard it was around 1k$US

  7. Hello, HyperTransport! by Anonymous Coward · · Score: 0

    The PCI bus (and by that I mean PCI-X or PCI-EXPRESS) is not fast enough to handle the traffic

    True, Intel's PCI bus is, has always been, and, for the foreseeable future, will remain, a shared bus, which is not of much use for the kinds of switched applications we're talking about here.

    However, AMD has got this new bus, called "HyperTransport," which is fully switched, and can handle multiple gigabits per second of data.

    In the very near future [which shouldn't be a whole lot more than 6-9 months time, as they iron out the kinks], I can imagine some absolutely bitchin' 64-bit linux/freebsd dual or quad Opteron solutions in this category...

    1. Re:Hello, HyperTransport! by shaitand · · Score: 1

      although the bus is certainly needed, that would be one hell of a waste of processor ;)

      On one hand, dual and quad processing should help to handle the numerous simultaneous requests, 1ghz worth of processing power would do the job without a hiccup. Of course, NEW boards, with a NEW bus, are going to require NEW processors, whether they are needed or not.

    2. Re:Hello, HyperTransport! by MerlynEmrys67 · · Score: 1
      Wrong bus...

      Ok, HyperTransport is a CPU bus to the Northbridge of the Chipset, to prove my point - can you come up with a URL to a HyperTransport NIC ?

      HyperTransport systems will still have PCI busses - hopefully they will get PCI-EX slots that will be able to switch traffic at 8 Gbit/sec and be able to drive a 10Gig nic at about 2/3 throughput

      --
      I have mod points and I am not afraid to use them
  8. I've had bad experiences by mnmn · · Score: 1

    I bought two ATM cards, Madge Collage Horizon cards to use back to back to start up using ATM. All kernels I tried simply crashed and this was maybe a month ago. Yes I tried different computers, removing all options from the kernels, different compilers etc. I tried 2.4.0, 2.4.5, 2.4.20, 2.4.21, 2.5.75 and a pre version of 2.6. I joined the mailing list where they said not much could go wrong there.

    I suggest you buy and try the cards and networks before deciding to implement it. I've ordered more (Efficient) cards from eBay and an old IBM switch. For a reliable ethernet to ATM connection, I would use a cisco 4000 series router, or 3600 or 3700 series if I had the money. Theres also a sub-$100 1000 series cisco router with one ATM and one eth ports but I would imagine its crap.

    --
    "Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
    1. Re:I've had bad experiences by NoMoreNicksLeft · · Score: 1

      I thought those old IBM things were only the 25mps ATM. Which isn't even real ATM, as far as I've ever been able to tell.

      I have a Cabletron SmartCell zx250, and I use the 32bit pci Fore cards... can't remember the model # at the moment. I only got them because I like to play with weird networking stuff... but I have had some minor success. Driver's load at least, and I get the equivalent of a link light. My understanding of AAL5 and LANE isn't good enough, I fear, to do anything truly interesting.

      On the other hand, a buddy of mine with the 3com ATMlink cards had absolute zero luck. Couldn't even find a linux driver, and the NT drivers were'nt able to do a damn thing. So I dunno.

      Just wish I could find the 622mps blade for my zx250... if anyone is selling one, let me know.

    2. Re:I've had bad experiences by mnmn · · Score: 1

      I like to play with weird networking stuff

      I know where you're coming from. Ive got a 2-hub Tokenring, arcnet (remember that?) FDDI and framerelay setup at home (and of course ethernet and 802.11). I tried the hardest and had the least luck with the 25-speed ATM cards (I still have 5 of em).Yeah I got the driver to work well in the kernel with lights on, but atmsigd always crashes. I tried various kernels, atm tools versions, and various library versions that the atm tools depend on.

      I'm waiting on some sparcstations with sun-atm 155 sbus cards ordered from eBay. I'm determined to have ATM at home, but would be cool to be able to use FreeBSD and Linux rather than Solaris. Even the 25-speed cards will be an improvement over my 10mbps ethernet (and arcnet) and 16-mbps TR, and 4mbps FR.

      --
      "Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
    3. Re:I've had bad experiences by NoMoreNicksLeft · · Score: 1

      Arcnet is what I use to network my Amigas. I really want the TRS-80 Model 2/16 arcnet card though.

      I haven't gotten a FDDI concentrator yet, but do have the nics. Also have an extensive, even obscene localtalk network. Macs, apple2s, a Newton, linux/x86, NeXTstation, and possibly an SGI.

      And, I do have that 2slot sbus HIPPI card... too bad I can't find more gear to build it.

      Good luck on the ATM, but what switch are you using? I've yet to see a switch that will do both 25mps and 155mps... lord knows I'd love to have a blade for mine that did 25.

      Check out my Metanet page, if you haven't already. I'm building an even bigger network now, and we could probably use a guy like you...

    4. Re:I've had bad experiences by mnmn · · Score: 0, Offtopic

      localtalk network
      <br>What in the world... I missed one networking technology.
      <br><i>Macs, apple2s, a Newton, linux/x86, NeXTstation, and possibly an SGI.</i><br>
      Ive got ultrasparc and sparcs, planning to get an iMac, otherwise have not been exposed to macs much. Got an RS6000 with AIX, Pentium1 with Unixware, and will get the Octane with IRIX, something with HP-UX and Tru64 too. I wanted to get a complete UNIX-clone set but the OS390 is a little out of reach.
      <br><br>I am using the IBM 8250 switch with certain extensions I dont know about. I suspect it has two 155 fibre connectors but the seller's details were hazy. Got it on eBay for $50. I'm studying for a CCIE, so have a pile of routers 2500s, and am getting 4000s with ATM cards. For some reason I'm obsessed with ATM over everything else.<br><br>Right now I'm on Solaris on sparc, but after by SCSA certs, I'll get back to trying to use Plan9 as a desktop... with lots of command line tools, it works!

      --
      "Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
  9. why? by jovlinger · · Score: 1

    I thought that ATM was basically uncompetetive compared to gigabit ethernet, and that you could afford to overspecify an ethernet solution with wide-enough a margin so that you could provide reasonable QoS guarantees, and still have money left over for lunch, compared to the comparable ATM solution.

    Not assertions, questions!

    1. Re:why? by Anonymous Coward · · Score: 0

      I think you're right on the money here. ATM is a legacy solution. If you're buying your bandwidth from somebody that wants to sell you ATM, then that's a good reason as your real cost is the bandwidth, but you could be buying 1GbE from Cogent for $1000 a month. Why you would want to use ATM on your internal network was never clearly explained. If you've got some legacy requirement, well that would be a good answer.

    2. Re:why? by Anonymous Coward · · Score: 0

      Oops, that's $10,000 a month for 1GbE from Cogent. Sorry about that. But this just highlights the fact that it's the bandwidth that's going to take all the money, so saving a few grand on a router shouldn't be irrelevant if you can shave costs on the bandwidth.

    3. Re:why? by Raxxon · · Score: 1

      when you're feeding directly off of a telco link, doesn't it make sense to talk what the telco is talking? ;)

      I can do everything over 100Mbit ether if I wanted to, but I'm looking at what can be done to reduce the number of SAR (Segmentation And Reassembly) jumps that have to be made on my network. If I can avoid some of them by bringing the feed in as ATM, and it's as reliable as doing 100Mbit ether, why not do so?

    4. Re:why? by Black+Copter+Control · · Score: 1
      I'm not sure that the question here is bandwidth.. I'm guessing that it's more like knowing how to do all the work you want with Linux and not wanting to have to learn how to do it on a Cisco too. On the other hand, the notes about the fact that it's the bandwith that's gonna kill you compared to the cost of a router also apply to the cost of training someone to use the router. I think that it might be quite worth it to get a Cisco and get yourself sent off to a Cisco course.

      You can still put a Linux box (or four) on the inside of the router and the rest of the firewalling at your leisure.

      --
      OS Software is like love: The best way to make it grow is to give it away.
  10. Odd question. by duffbeer703 · · Score: 1

    If you have the money for an ATM network equipment you should be using something other than a linux box as a firewall.

    --
    Conformity is the jailer of freedom and enemy of growth. -JFK
    1. Re:Odd question. by shaitand · · Score: 1

      Exactly what do you have in mind that is more secure than a linux box?

      The PCI bus is certainly not up to spec for handling anything that truely would justify ATM levels of traffic, but linux itself will rival anything cisco has on the market.

  11. Bring on Hypertransport! Telecomm for the masses! by Anonymous Coward · · Score: 0

    although the bus is certainly needed, that would be one hell of a waste of processor ;)

    Not when you get into some serious Access Control Lists and other kinds of filtering. Imagine, say, one processor per network interface [or per subset of network interfaces] for interface-specific access control lists, and a spare processor for multi-interface calculations [Open Shortest Path First, Exterior Gateway Protocol, etc.].

    For maybe $10,000 dollars, you could build a quad processor Hypertransport/Opteron system that would kick the living shit out of a $100,000-$1,000,000 solution from Cisco, Nortel, Lucent, or Juniper.

    And don't pretend for a second that the suits at those companies aren't aware of this...

    Bring on Hypertransport! Telecomm for the masses!

  12. ATM WAN on Linux? by freebase · · Score: 1

    I'm gonna make a couple of assumptions...
    #1 If you're using ATM, you've got at least 4xT1 IMA group. Anything smaller and Multi-link PPP or Multi-link Frame Relay makes more sense.

    #2 There's something about ATM that you need for your application. Most of the QoS functions you can get now with the DSCP bits and other IP QoS techniques.

    ATM uses 58 byte cells. A 4xT1 IMA group is roughly 6.1Mbps. With these numbers, we can see that this 4xT1 IMA group will handle slightly more than 13K Cells/s.

    At layer 1, ATM is easy... listen for 58 bytes, send the cell up the stack... listen for 58 bytes, send the cell up the stack...

    At layer 2, though, you have segmentation and reassembly functions, which take all those 58 byte cells and turn them back into packets. The SAR code has to check every cell for packet data.

    Once all that is done, then you can get your L3 IP packet, examine it as needed, and route it.

    All this is to say that while a large portion of this process begs to be implemented in hardware, as most router companies have, Linux does this mostly in software, burning CPU proportionately to the ATM traffic load.

    If you're going to use a PC with Linux to handle ATM and routing, then make sure you've got the CPU, memory, and backplane to handle the load. I would not use a box that is also going to be hitting the disk on a regular basis; I wouldn't want disk i/o sharing the bandwidth across the backplane.

    --
    Sig??? I don't need no stinkin Sig!
    1. Re:ATM WAN on Linux? by Raxxon · · Score: 1

      The ATM pipe we're looking at tapping is a feed between a Cisco ONS and our Telco Switch.

      Basically I was looking at what the benefits might be of offloading the SAR process from the Telco Switch to a Linux box (most ATM cards that I've seen are hardware based SAR, they just return an IP frame) since we're going to set one up for the router anyway. IF I can keep the traffic ATM based, given that a chunk of it comes in as ATM to begin with and most of it will leave as ATM, it should be an overall benefit to network performanc not to have to undergo 2 SAR dumps, shouldn't it?

    2. Re:ATM WAN on Linux? by spackled42 · · Score: 1

      Just FYI, ATM actually uses 53 byte cells... This odd number came as a result of some compromise in the standards process. Europe wanted 64 bytes and the US wanted 48(?) bytes, because of the slight differences between an E1 and a T1.

    3. Re:ATM WAN on Linux? by freebase · · Score: 1

      If you're using an ONS, why not just use an ethernet card in the ONS?

      --
      Sig??? I don't need no stinkin Sig!
    4. Re:ATM WAN on Linux? by freebase · · Score: 1

      Yeah.. I was thinking 53 (48+5) and typed 58...
      and it wasn't all of Europe... was France.. Propagation delay on 48 byte cells would have let them send it across the country without electrical regeneration of timing.

      --
      Sig??? I don't need no stinkin Sig!
    5. Re:ATM WAN on Linux? by Raxxon · · Score: 1

      Because the ONS is at a physically different site.

      Plus, as I've said in other posts, I can do this via ethernet off the Telco switch, but I'm looking at eliminating as many SAR jumps as I can. Up front it won't mean that much, but later on (assuming things go well once we have the gear in place) it could make for some very noticible performance differences.

    6. Re:ATM WAN on Linux? by freebase · · Score: 1

      I read your Journal entry. A couple of things for you-

      1. Are you doing Voice or Data CLEC? The type of traffic will dictate the network you use. ATM is good for data, but TDM is better for Voice, even now.

      2. Have you gotten your certificate from your state PUC? Without it, the local ILEC won't (and doesn't have to) give you the time of day.

      3. If you've gotten your certificate, have you negotiated your ICA (inter-connect agreement)? The ICA will specify exactly what the ILEC has to provide you, and at what prices. You might still be able to opt into an existing ICA between the ILEC and another CLEC if you can find one you like.

      4. Have you applied to your area co-ordinator for your number block? Who's hosting your SS7? How are you handling connectivity to the required 911 PSAPs?

      5. Do you have an OSS platform that's flexible enough to do what you need, but simple enough to operate on a shoe string?

      You might want to subscribe to the isp-clec lists at http://isp-lists.isp-planet.com .

      --
      Sig??? I don't need no stinkin Sig!
    7. Re:ATM WAN on Linux? by Raxxon · · Score: 1

      The paperwork stuff is up to the boss. ;) I'm just the geek getting everything wired.

      I know that there's a ton of paperwork that's gone out to the PUC, and I think that part is done. The ICA is being worked on now. We have our initial number block and the SS7 hosting is being worked on. As far as 911 goes, I have no idea.

      We will be voice and data. Are there any nightmares that I should be aware of looking at setting this up?

    8. Re:ATM WAN on Linux? by pyrrhonist · · Score: 1
      Are there any nightmares that I should be aware of looking at setting this up?

      Uh, quite possibly the telecom market?

      --
      Show me on the doll where his noodly appendage touched you.
  13. Wrong Wrong bus = RIGHT BUS!!! by Anonymous Coward · · Score: 1, Interesting

    Wrong bus...

    Ok, HyperTransport is a CPU bus to the Northbridge of the Chipset, to prove my point - can you come up with a URL to a HyperTransport NIC ?

    HyperTransport(TM) Technology - Overview

    Best of all, HyperTransport is software and operating system compatible with the popular Peripheral Component Interconnect (PCI) interface that is commonly used in most systems today. Unlike the older multi-drop architecture of PCI that reduces throughput when more devices are attached, HyperTransport is a point-to-point line that maintains full throttle performance at all times. Point-to-point attachment also means that there is no bus arbitration overhead, keeping actual I/O bus throughput near the theoretical maximum.

    http://www.hypertransport.org/tech_overview.html

    Don't have to give you a URL - the hypertransport bus is backwards compatible with the old PCI bus, so PCI cards and their drivers [knock on wood] should be able to plug right in!

    And, guess what? It's had chipsets for almost a year now:

    http://www.google.com/search?safe=off&q=AMD-8111+s outhbridge
    1. Re:Wrong Wrong bus = RIGHT BUS!!! by MerlynEmrys67 · · Score: 1

      Yup, connects to a PCI bridge. Again - show me a "HyperTransport (TM)" card... There aren't any, HyperTransport - much like other Front Side busses connect the chip interconnects to PCI bridge chips to connect to PCI busses... Compare and contrast HyperTransport to PCI-Express - very different architectures. You will see HyperTransport connecting CPUs to chipsets and whatnot, then PCI-Express connecting I/O devices (Nics, HBAs, HCAs etc.)

      --
      I have mod points and I am not afraid to use them
  14. linux ATM driver page.. by kfuq · · Score: 2, Informative

    Here is the "linux-atm" page.

    when all else fails, try sourceforge !!!!

    LOL |-)

    --
    iF yOu WAnT to C YOUr iP agaIn gAThEr tWO MilLIon dOLLArS IN Non - cONsEcuTivE TweNtY's AnD AWaiT FuRThER iNstrUctIoN
  15. more linux ATM info...... by kfuq · · Score: 1
    --
    iF yOu WAnT to C YOUr iP agaIn gAThEr tWO MilLIon dOLLArS IN Non - cONsEcuTivE TweNtY's AnD AWaiT FuRThER iNstrUctIoN
  16. I would think it should work. by Bridog · · Score: 1

    I was back at Case Western Reserve University (see /.'s recent wiffy post about CWRU) when they were running ATM to student rooms in residence halls on campus. We were using Fore PCA200Es at the time; they were kinda crappy cards, but they worked. There were various Linuxes running on ATM. I was running RedHat 2.0.36 at the time (yeah, this was circa 1998/9), and the ATM driver worked only as a module. Once things were set up, there were very few substantial problems. The 2.2 kernels brought some better support, but I soon switched to OpenBSD and all bets were off.

    If you need the support, I see no reason why it shouldn't work. If you don't really need it, Ethernet support is so built-into-everything that the fact that it has 0% software hassle may make it more worthwhile. Of course, if you're talking about networked games... ATM. Yum.

    --
    Most likely the #1 Unfunny Meta/Moderator on /.!
  17. Just use FBSD... by Brew+Bird · · Score: 1

    FreeBSD has had good PCI ATM support since 1999 or so...

    I used it for building IP over ATM test gear in the Williams labs back then... worked great!