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