[Gllug] OT: MTU sizes, w/ Broadband

[Chris Bell]

On Wed 14 May, Simon Wilcox wrote:
> 
> On Wed, 14 May 2003, Chris Bell wrote:
> 
> >    The problem is that BT have been using their ATM network to carry the
> > data. Their network was specifically designed for speech using two parallel
> > data streams, one carrying route data and the other digitally coded
> > real-time audio, using very small packet sizes. It was probably very
> > advanced at the time it was designed, perhaps it was a work around when many
> > large but slow and simple chips were required, although few people
> > understand the reasons now. The optimum MTU for this system works out at
> > 1458, until they can install new equipment designed to work with an MTU of
> > 1500, although the affect is minimal unless their system approaches
> > saturation.
> 
> ATM uses fixed length packets, called cells, which allows highly efficient
> aggregation of data on backbone networks using well understood, and very
> fast, time division multiplexing techniques. It also includes quality of
> service metrics and other features useful for audio/video and other time
> senstive packet systems.
> 
> ATM cells are 53 bytes long, with 48 bytes of user data. The ethernet
> packet is chunked up and reassembled at the other end. Under length cells
> are padded to the exact length. So you can gain *margin* increases in
> speed by making the MTU of your ethernet such that you exactly fill the
> last cell thus saving the padding.
> 
> Personally, I've always considered this to be so marginal, given the 
> general latency of the internet, to be not worth bothering with. YMMV :)
> 
> Simon.
> 
> PS. ATM use is generally considered a feature rather than a problem as it 
> enables very efficient, and therefore cheaper, backbone networks. Ethernet 
> isn't very efficient but as the speeds have increased, it's cheap 
> componentry and the glut of fibre in the ground has meant that it is used 
> over longer and longer distances these days.
> 
   I think the time division multiplexing is well understood, the rather
long explanation I found for sending two separate parallel data streams was
not understood even by the book's author, even though I would assume that
they are now routed via the same multiplex links.

-- 
Chris Bell



-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug