T1 Circuit actual throughput 1290Kbps

James Carlson carlson at ironbridgenetworks.com
Fri Jul 10 16:01:49 UTC 1998


mlm at ftel.net (Mark Milhollan) writes:
> "Patrick W. Gilmore" writes:
> >PPP overhead is not even close to 200 Kbps on a T1.  
> 
> Without information on the traffic being handled this statement cannot
> be supported.  I agree that its doubtful.

Actually, we can probably do better than that.  For HDLC, the worst
case is all ones user data, which expands 6/5, plus 7 bits per packet
of shared flags.  The PPP overhead, assuming no header compression, is
four bytes of header plus two bytes of CRC per packet.  Now, if we
assume 256 byte packets (not a bad assumption of average given IP
traffic measurements I've seen) with worst case data, the user portion
will expand from 2048 to 2458 bits, and the HDLC/PPP overhead adds 55
bits.  Thus, our efficiency is .815, or 284Kbps of overhead.

With random data, rather than worst-case data, things are much
better.  The expansion is 161/160 on random data, which means that our
2048 bits of data go as 2061 encoded.  The efficiency is .968, or
49Kbps.

> >there are no "cells" in PPP. 
> 
> Its certainly possible that cells are being used, but their use should
> not impact the delivered capacity.

(!)  The cell tax is about 10% -- the SAR expands user data from 48
bytes to 53 bytes, plus an additional amount of overhead for internal
fragmentation on the final cell (AAL-5), plus overhead for whatever
encapsulation mode is being used.

On a T1, you'd be lucky to get away with only 154Kbps wasted in cell
overhead, let alone any of the L2 stuff.

-- 
James Carlson, Consulting S/W Engineer  <carlson at ironbridgenetworks.com>
IronBridge Networks / 55 Hayden Avenue  71.246W    Vox:  +1 781 402 8032
Lexington MA  02421-7996 / USA          42.423N    Fax:  +1 781 402 8092
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp



More information about the NANOG mailing list