From owner-freebsd-isp Thu Feb 25 21: 4:46 1999 Delivered-To: freebsd-isp@freebsd.org Received: from mail1.realtime.net (mail1.realtime.net [205.238.128.217]) by hub.freebsd.org (Postfix) with SMTP id 94D4B14EB5 for ; Thu, 25 Feb 1999 21:04:27 -0800 (PST) (envelope-from gee2@oldzoom.bga.com) Received: (qmail 13464 invoked from network); 26 Feb 1999 05:04:10 -0000 Received: from oldzoom.realtime.net (HELO oldzoom.bga.com) (gee2@205.238.183.13) by mail1.realtime.net with SMTP; 26 Feb 1999 05:04:10 -0000 Received: (from gee2@localhost) by oldzoom.bga.com (8.9.1/8.9.1) id XAA02895; Thu, 25 Feb 1999 23:04:08 -0600 (CST) From: Fred Gee Message-Id: <199902260504.XAA02895@oldzoom.bga.com> Subject: Re: cdrom.com bandwidth limits To: jjw@admin.us.net (John Woodruff) Date: Thu, 25 Feb 1999 23:04:08 -0600 (CST) Cc: jjw@admin.us.net, isp@FreeBSD.ORG In-Reply-To: <36D5AB69.FC915382@admin.us.net> from "John Woodruff" at Feb 25, 99 02:58:33 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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