ATM on Linux, release 0.3 (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

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
   - API doesn't conform to Linux API draft
   - bind/connect don't pass back modified traffic parameters
   - select system call is untested
   - dup and getname aren'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.3 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.
