>Dear Howard,
>
>Thank you very much for the response. Everything is starting to come
>together now. I still have one problem though---
>
>>8000 bps, or every 193rd bit, is used for framing and control. 1536
>>Kbps + 8 Kbps = 1544 Kbps = 1.544 Mbps.
>
>I see how it works so there would be 1544 Kbps, but 1544Kbps =
>1.5078125Mbps (1544Kpbs * (1 Mbps/1024Kpbs)).
M is 10**6, K is 10**3 in this context. Forget K in the binary sense.
24 * 64,000 bps = 1,536,000 bps
+ 8,000 bps framing overhead
___________
1,544,000 bps
The 64,000 bps is the worldwide assumption for a basic PCM-digitized
voice signal, based on sampling a 4 kHz analog channel 8000 times per
second, and taking an 8-bit signal value. There are several
algorithms for the sampling, primarily A-law in Europe and mu-law in
the US, Canada, and Japan. I've been told that Mexico has its own
algorithm, K-law, but I've never worked with it.
Modern digitizing algorithms are far more bandwidth-efficient than
any of these traditional algorithms, which are late 1950-early 1960
technology.
> When the phone company tells us that we're getting 1.544 Mbps, do
>they really mean that we're getting 1544 Kbps??
You're getting 1.536 Mbps/1536 Kbps usable bandwidth, but the
interface has a 1.544 Mbps bit rate. (brushing off side comments
about isochronous signals, AMI/B8ZS bit stuffing, etc. Yes, yes, I
know.)
>
>Sincerely,
>
>Fred Danson
No, "
>
>
>
>>From: "Howard C. Berkowitz" <[EMAIL PROTECTED]>
>>Reply-To: "Howard C. Berkowitz" <[EMAIL PROTECTED]>
>>To: [EMAIL PROTECTED]
>>Subject: Re: A few quick Remote Access questions
>>Date: Tue, 13 Feb 2001 15:09:12 -0500
>>
>>>I've been reading through the Sybex BCRAN book and have a few "quick"
>>>questions:
>>
>>I like your questions. There's always a need to observe if the
>>emperor is really wearing any clothes. You point out a number of
>>inconsistencies, which, in many cases, have historical causes.
>>
>>>
>>> First, I understand the theoretical difference between Autoconfigure
>>>and Autodiscovery, but in the book, it appears that the different commands
>>>do the same thing. For Autoconfigure, the book says "The modem autoconfigure
>>>command is used to instruct the router to use this feature. This feature
>>>will detect the type of modem connected to the router and then supply the
>>>initialization string to the modem-- a process that can require up to five
>>>seconds."
>>> It sounds as if the modem autoconfigure command also performs
>>>autodiscovery functions. Did they really mean to say that the command is
>>>modem autoconfigure modem_type ?
>>
>>Yakov Rekhter, one of the patron saints of routing and the IETF
>>(formerly at IBM, formerly Cisco Fellow, and now at Juniper), once
>>wrote, "at a sufficiently high level, everything is the same."
>>
>>You are correct that both autodiscovery (for LANs) and autoconfigure
>>(for modems) both do things necessary to get the physical and data
>>link layers to work. The interface types and protocols are very
>>different, and were in all probability developed by different people
>>who didn't talk to one another. As far as I can tell, CLI developers
>>have no equivalent of Martha Stewart as arbiter of good taste and
>>grammar. Internally, Nortel does in principle have some committees
>>that oversee the consistency of command languages in new products,
>>but I'd hardly call it high priority. Other vendors' mileage will
>>vary.
>>
>>>
>>> The second question that I have involves RTS and CTS.
>>
>>Part of the problem is that RTS and CTS were originally developed as
>>part of the EIA RS-232 standard. Originally, when RS-232 was
>>started, it was purely intended for use between a data terminal
>>equipment (DTE) and a data circuit terminating equipment (DCE). In
>>the minds of the developers, DTE=computer and DCE=modem.
>>
>>Modems of the time (1970 or so) often worked over half-duplex lines.
>>Long before hub-and-spoke topologies such as frame relay, there were
>>analog hub-and-spoke topologies in which the hub was a Master
>>Computer that sent out a poll -- an invitation to transmit -- that
>>could be heard by all slaves. When a slave recognized an invitation
>>addressed to it, and it had something to say, it would assert RTS to
>>bid for the transmit rights to the line. Think of listening for your
>>poll as similar to waiting for a shared Ethernet to become quiet, or
>>to receive the token. Depending on the analog technologies in use, it
>>could take up to several seconds before your modem was ready to
>>transmit and sent CTS.
>>
>>
>>>The stated
>>>function of RTS from the book is "Request to send is one of the two hardware
>>>flow control wires. It signals that the DTE can receive data from the DCE.
>>>This depends on having sufficient buffers available." The states function of
>>>CTS from the book is "Clear to send is the second hardware flow control
>>>wire, and it signals that the DCE is ready to receive from the DTE." I
>>>previously thought that there were two steps to hardware flow control using
>>>RTS and CTS.
>>
>>The use of RTS and CTS to control traffic between a computer and a
>>local device such as a printer came later. RTS and CTS weren't
>>designed, per se, for this application, and you may equally well see
>>DTR and DSR used for this sort of flow control.
>>
>>>I used to think that the sending side would first send a RTS
>>>message to the receiving side, and in turn the receiving side would send a
>>>CTS message so that the sending side would know that the receiving side was
>>>ready for data. The thing that gets me with their explanation is that they
>>>say that CTS is used by the DCE saying that it is ready to receive, and RTS
>>>is used by the DTE saying that it is ready to receive. My impression from
>>>this explanation is that it is a one step process, but I still dont see how
>>>this would work. How does it really work??
>>>
>>>My third question is: What exactly is the difference between ISDN PRI and a
>>>leased line T1??
>>
>>Electrically: no difference
>>Bit framing: no difference, although ISDN is probably more likely
>>to use ESF
>>Channelization: T1 is not necessarily channelized.
>> When channelized, it is most commonly channelized
>> into 64 Kbps DS0's or multiples of 64 Kbps.
>> For voice applications, call control can be
>>channel associated
>> (bit-robbing) or common channel. The latter is
>>similar to ISDN.
>> PRI is channelized into DS0's, of which one, the D channel,
>> is designated as a control channel.
>>
>>
>>>
>>>And Finally, my last question is: How the heck do they get the number 1.544
>>>Mbs for the speed of a T1? When I multiply 24 (# of B channels) by 64Kbs I
>>>get 1536kbs. 1536Kbs converted to Mbs (1536/1024)is 1.500 Mbs! Where are the
>>>other 0.44 Mbs at??
>>
>>8000 bps, or every 193rd bit, is used for framing and control. 1536
>>Kbps + 8 Kbps = 1544 Kbps = 1.544 Mbps.
>>
>>>
>>>If anyone can answer atleast one of the questions, please do. I know that
>>>I'm digging real deep here, but thats how I learn best. Thanks.
>>>
>>>Fred Danson
>>
>>_________________________________
>>FAQ, list archives, and subscription info:
>>http://www.groupstudy.com/list/cisco.html
>>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
>_________________________________________________________________
>Get your FREE download of MSN Explorer at http://explorer.msn.com
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
