From owner-freebsd-isp Thu Feb 25 12: 1:29 1999 Delivered-To: freebsd-isp@freebsd.org Received: from admin.us.net (admin.us.net [198.240.72.18]) by hub.freebsd.org (Postfix) with ESMTP id 2C33614DE4 for ; Thu, 25 Feb 1999 12:01:21 -0800 (PST) (envelope-from jjw@admin.us.net) Received: from admin.us.net (admin.ofc.us.net [198.240.65.1]) by admin.us.net (8.8.8/8.8.8) with ESMTP id PAA09507; Thu, 25 Feb 1999 15:22:08 -0500 (EST) X-Provider: US Net - Advanced Internet Services - 301-361-USNET - info@us.net Where Business Connects! (tm) -- http://www.us.net/ Message-ID: <36D5AB69.FC915382@admin.us.net> Date: Thu, 25 Feb 1999 14:58:33 -0500 From: John Woodruff Organization: US Net X-Mailer: Mozilla 4.04 [en] (Win95; U) MIME-Version: 1.0 To: jjw@admin.us.net Cc: isp@FreeBSD.ORG Subject: Re: cdrom.com bandwidth limits References: <199902231921.OAA03755@y.dyson.net> <36D3A26A.922CE5A9@softweyr.com> <199902251455.JAA14731@etinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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. > > So, some really stupid CSU/DSU's will format the data where they > "force" every 8th bit to a one. This is how you end up with 1344 > kb/s of bandwidth. I understand that form of "bit stealing" allows you to use non-B8ZS lines, where the ones-density requirement exists. This is derived from the way D4 banks encoded voice - there is never a string of that many zeros. These DSU's force in some extra ones, and the result is that you end up with 1344 Kb/s. This is the AMI setting on your DSU - it enables the bit-stealing stuff. On B8ZS-enabled links, they use a "double pulse" to encode the zeros that would otherwise cause the reciever to lose sync, so you can really use all the bits (aside from the SF/ESF framing). This is an added hardware capability that has to be in every line amplifier along the span, not just the end cards. > The other more common way to do this is to observe that most modern > uses of T1 spans for data transmission use HDLC bit-synchronous > framing these days. If the DSU inverts the data coming in, then the > HDCL framing will ensure adequate one's density on the T1 span. > In this instance, you get to use all 1536 kb/s of capacity > (64kb/s*24 channels) of the T1 span. I was unaware that inverting the data had any effect. Since just about eveything I know about uses HDLC, are you saying that just by inverting the data I can use an AMI span (and don't have to mess with ensuring it's B8ZS-clear)? Now *that'd* be useful info! Dennis probably knows all about this, considering what ETINC builds for a living. Perhaps he'd clear up any misconception's I've voiced here... -- John Woodruff, Sr. Network Engineer, US Net - 301-361-USNET Washington/Baltimore/Richmond ISP - $6.95/month for full PPP! PGP KeyFP: 66 18 1A 4E 55 08 40 E2 C7 B1 F2 D1 81 12 6D BF To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message