Index of /pub/linux/funet/atm
Name Last modified Size Description
Parent Directory 04-Dec-2008 10:53 -
README 27-Sep-1995 23:00 4k
api/ 11-Aug-1999 18:14 -
berlin95/ 11-Aug-1999 18:14 -
berlin96/ 11-Aug-1999 18:14 -
dist/ 29-Aug-2003 21:04 -
docs/ 24-Jul-2000 09:10 -
extra/ 24-Jul-2000 09:10 -
mailing-list/ 18-Oct-2007 10:02 -
misc/ 11-Aug-1999 18:14 -
papers/ 11-Aug-1999 18:14 -
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.