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?"
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.
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
Considering you said ATM, my first thought was Automated Teller Machines - which run on an OS/2 package.
This sig no verb.
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.
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
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!
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
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.
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!
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
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 ?
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:
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
ATM on Linux
linux ATM links
iF yOu WAnT to C YOUr iP agaIn gAThEr tWO MilLIon dOLLArS IN Non - cONsEcuTivE TweNtY's AnD AWaiT FuRThER iNstrUctIoN
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
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!