Date: Thu, 25 Feb 1999 14:58:33 -0500 From: John Woodruff <jjw@admin.us.net> To: jjw@admin.us.net Cc: isp@FreeBSD.ORG Subject: Re: cdrom.com bandwidth limits Message-ID: <36D5AB69.FC915382@admin.us.net> References: <Your message of "Tue, 23 Feb 1999 23:55:38 MST." <36D3A26A.922CE5A9@softweyr.com> <199902231921.OAA03755@y.dyson.net> <36D3A26A.922CE5A9@softweyr.com> <199902251455.JAA14731@etinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36D5AB69.FC915382>