ATM on Linux, release 0.4 (pre-alpha) by Werner Almesberger, EPFL LRC ===================================== werner.almesberger@lrc.di.epfl.ch This is experimental software. There are known major bugs and certainly even many more yet unknown problems. Internal and external interfaces are far from being stable. In fact, they change daily. Use at your own risk. This package contains a kernel patch for ATM protocol stacks and for ATM device drivers, source for management and test tools, and this description. The following network devices are supported: ATM over TCP pseudo device for "dry runs" Efficient Networks ENI155p-MF 155 Mbps ATM adapter The following connection types are supported: constant bit rate (CBR) permanent connections best-effort (UBR) permanent connections support for signaling is available in a preliminary state The following protocols are supported: "raw" unreliable ATM transport without AAL ("AAL0") "raw" unreliable ATM transport over AAL5 IP over ATM (NULL or SNAP encapsulation) The API is loosely based on the Linux ATM API proposed on the linux-atm mailing list. This implementation is _not_ (yet) a reference but will change in the future to fully support the final API. Known bugs and restrictions --------------------------- ENI driver - should use bottom-half interrupt handler - didn't test >1 adapter per machine - doesn't handle unsolicited OAM cells gracefully - adapter may deadlock if buffer full of loss indications - doesn't properly zero padding area of AAL5 PDUs ATM over TCP - ATM over TCP driver is very limited - system crashes if atmtcp is killed - should support explicit downing - doesn't work with IP over ATM ATM protocol stack - doesn't compile if proc FS is disabled - API doesn't conform to Linux API draft - bind/connect don't pass back modified traffic parameters - getname isn't implemented yet - poor integration with other network code IP over ATM - doesn't support InARP - should support explicit downing other parts - "applications" are ugly Performance (version 0.1) ----------- Note that version 0.4 has some debugging code enabled in the ENI driver. It is therefore about 10% slower than indicated below. Platform: Pentium 90 MHz, Neptune and Triton PCI board, 32 MB RAM, ENI155p-MF-C 2048 PDUs, 8192 bytes each, no wait for close Directly connected, no switch, max buffers (128kB) allocated on board Kernel buffers were only limited by available memory Results (average of ten ttcp runs): Transport TX Mbps RX Mbps Loss (bytes) raw AAL5 (unchecksummed) 128-132 101 0-13% UDP, checksummed 111-127 17- 55 49-76% (*) UDP, unchecksummed 114-128 73- 82 27-41% TCP (checksummed) 63- 67 63- 67 0% (* additional slowdown because driver printed warning messages) For reference, the results with the 0.0 version (average of ten ttcp runs, only between Neptune-based PCs): Transport MMU hacks TX Mbps RX Mbps Loss (bytes) raw AAL5 (unchecksummed) no 132 97 0% yes 1607 129 0% UDP, checksummed no 117 51 56% UDP, unchecksummed no 118 72 39% TCP (checksummed) no 38 38 0% Because ttcp does not measure the time spent in the close system call for datagram protocols, the raw AAL5 TX rate reflects the rate at which data can be enqueued to the device driver. The performance measurements are only accurate within about +-5%. Even marginal changes can lead to a systematic change of 2-3%. The theoretical limits are 135.367 Mbps for raw AAL5 and 134.580 Mbps for UDP, assuming data is sent in blocks of 8192 bytes each. When the Neptune-based PC was the receiving machine, transfers were always as good or better (in terms of throughput and loss) with version 0.1 than with version 0.0. So it seems that my Triton still needs some tuning. TCP is now pleasently fast.