Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Dec 1998 22:30:42 +0100 (CET)
From:      Andrzej Bialecki <abial@nask.pl>
To:        Javier Henderson <javier@kjsl.com>
Cc:        Dennis <dennis@etinc.com>, Alan Batie <batie@rdrop.com>, isp@FreeBSD.ORG
Subject:   Re: ATM WAN interface
Message-ID:  <Pine.BSF.4.02A.9812282200060.13290-100000@korin.warman.org.pl>
In-Reply-To: <199812281955.LAA26758@kjsl.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Dec 1998, Javier Henderson wrote:

> Dennis writes:
> 
>  > Note that ATM has a LOT of overhead (like 30%). so  ATM over a DS3 
>  > is not nearly the bandwidth of using straight HSSI or PTP. ATM is meant
>  > as a medium that can be switched at high speed, but as a PTP mechanism
>  > it is very poor.
> 
> 	I've often wondered how well IP would do, throughput-wise,
> over ATM with its 53 byte cells. "Packet fragmentation overhead" comes
> to mind. I've never seen actual performance figures, however.

Quite bad.. :-/

Let's do some math:

1) Suppose we have a 256-byte IP packet (which is quite close to average
   packet length on the net). This is usually wrapped into LLC/SNAP (8
   bytes), then passed to AAL5 (which adds 8-byte trailer), and finally
   broken into 48-byte pieces of ATM payload (with 5-byte overhead). This
   gives us 6 cells to transmit, and total of 318 bytes. The overhead is
   around 24%. Of course this is only the overhead of ATM.

2) Suppose we have an interactive session, where 1-10 bytes are
   transmitted as a TCP payload. This gives us a 41-50 byte IP packets.
   Let's add LLC/SNAP and AAL5 (16 bytes, total 57-66 bytes), then we
   break it into cells (2 cells), and the total sum of bytes to
   transmit is 106. The overhead is 86% (for 41-byte IP packets), and
   61% for 50-byte packet. The overhead counted against the TCP payload
   is quite horrendous.. :-))

So, the beauty of ATM is its ability to transmit _different_ types of data
over the same link (such as IP, circuit emulation, video etc..), and not
its efficiency when it comes to throughput - because this is where it
really sucks...

Hope this helps a bit.

Andrzej Bialecki

--------------------   ++-------++  -------------------------------------
 <abial@nask.pl>       ||PicoBSD||   FreeBSD in your pocket? Go and see:
 Research & Academic   |+-------+|       "Small & Embedded FreeBSD"
 Network in Poland     | |TT~~~| |    http://www.freebsd.org/~picobsd/
--------------------   ~-+==---+-+  -------------------------------------


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isp" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.02A.9812282200060.13290-100000>