Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Feb 1999 23:04:08 -0600 (CST)
From:      Fred Gee <gee2@oldzoom.bga.com>
To:        jjw@admin.us.net (John Woodruff)
Cc:        jjw@admin.us.net, isp@FreeBSD.ORG
Subject:   Re: cdrom.com bandwidth limits
Message-ID:  <199902260504.XAA02895@oldzoom.bga.com>
In-Reply-To: <36D5AB69.FC915382@admin.us.net> from "John Woodruff" at Feb 25, 99 02:58:33 pm

next in thread | previous in thread | raw e-mail | index | archive | help
From the desk of John Woodruff...
> 
> John S. Dyson wrote:
> > It is not likely to get that much due to protocol overheads, but I
> > have seen >160KBytes/sec on a good T1.  Don't T1's do bit stealing
> > for signalling (I forget?)
> 
> The signaling was on the extra channels that the Extended SuperFrame
> format provided.  The old-style SF used 1/24 (?) of the bits for clock
> sync; the new ESF used three of those for signalling and the Facility
> Maintenance Link.  This is the SF/ESF switch (aka D4/ESF).  Unless
> I'm wrong, SF/ESF doesn't affect the bandwidth available at the V.34
> (V.32?) plug.
> 
> Dennis wrote:
> > The problem they face is that there is a specific one's density
> > requirement when pushing bits over the wire; if you have too
> > many zero bits in a row, then the T1 span will blow it's clocking.
> >
To clear things up a bit...

There are two things being discussed here, and they are different.

First, the issue of HDLC 0-bit stuffing, the term used for inserting
1's where there is a run of 0's that will be difficult to detect.
This does not affect bandwidth, and is done directly in the hardware
along the path.  It is worth knowing about if you design HDLC hardware,
but otherwise it is just "so what?".

The second issue, robbed bit signalling AKA AMI encoding, high bit signalling
etc.  This is where the 8th bit of every byte is stripped off in hardware
and used for signalling (or simply set to 1 in CSU's that had no 0 bit
stuffing hardware (old ones)).  This robs 1/8th of the bandwidth.

B8Zs is popular in most places, and provides the full 8 bits.  You have to
be careful to ask for it... or not.  The fact is that some T1 tariffs make 
AMI advantageous.  If you loose 1/8th the bandwidth, and 1/3rd the cost,
AMI can make sense on T1's expected to be lightly loaded.  It also works
fine for PBX trunking (in fact, many PBX's require AMI).

G


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?199902260504.XAA02895>