Newsgroups: comp.unix.sco.misc From: bill@wjv.com (Bill Vermillion) Subject: Re: Problems establishing high-speed modem connection (uucico) Message-ID: <G4t0Hw.7rs@wjv.com> References: <v7at1tohgcfajjcgvvk0kuqv0lgl4rhbj8@4ax.com>
<gpf92tkuc14p4191ra1mimp1kphhfc0u9b@4ax.com>
<G4sDHy.52K@wjv.com>
<nrla2tk9ra7q7rg86kvjecmf6dve50vdda@4ax.com> Date: Wed, 29 Nov 2000 20:49:08 GMT In article <nrla2tk9ra7q7rg86kvjecmf6dve50vdda@4ax.com>, Chris Wright <chrisw@moonridge.co.uk> wrote: >On Wed, 29 Nov 2000 12:32:22 GMT, bill@wjv.com (Bill Vermillion) wrote: >>33600 is the MAXIMUM you could ever hope to >>get. 28K is pretty normal for many connections. I've seen then >>drop into the low 20's - this is dependant on lines and just how >>good the conversion process is within the modem.
>Looks like I might have reached the optimal speed I'm going to get then >in this case then. Thanks to everyone for their help. >Are any of the principles people have kindly provided in this thread >going to be any different when using ISDN modems/lines? They will be entirely different. The modems are analog. We take a signal and encode the bits upon that signal by shifting the phase of that signal for a group of bits, along with also perhaps changing the level for a particular change in phase. I have not seen what is called a 'constellation' for anything higher than 9600bps. So I'll just describe that. The line for 9600 bits/second is bascially a 2400baud line. A baud is a state change. In 9600 we encode 5 bits/baud. Now you say 5 * 2400 is 12000 - I thought this was a 9600modem. It is. There are 4 bits of data and one extra for correction.
The data sent to the modem is pulled apart in 4 bit hunks. Four bits + 1 for error give 5 bits. 5 bits is numerically equivalent to 32 decimal. Take a chart with x and y co-ordinates with the x/y in the center and draw a circle from the center. Divide that into 32 pieces and you have 32 points in the constellation - each representing a 5 bit value. Besides each of these being at 11.5 degrees from the previous one, typically the level/amplitude of the adjacent points varies so we have a phase and amplitude difference, which is easier to separate than just a phase difference. And frequency degradation on the line is going to affect the signals because of the phase relationships. What's even more fun at the high end is that both modems talk on the line at the same time. You know how hard it is to carry on a conversation or talk when someone else is talking to you. You also know that if you put your fingers in your ear you can talk like mad and even if the other person is talking. The modems do something similar - but they don't listen to what they are saying but listing to what the far modem is saying. It's only a single wire so if both modems are talking how do you get that apart? Simple - in theory - harder in practice. Simplified description goes like this. The line that you are talking on is also connetect to your receive side. But we take the output of what we are sending, and invert it 180 degrees and put that along with the signal which is on the line, and this effectively cancels out what we are sending and we only 'hear' what the other modem is sending. All this is why it's hard to get 33.6 except on the best lines. ISDN is basically digital - and digital signals can take a lot of abuse in regards to noise, distortion, etc. All we have to do is tell whether it's supposed to be a 1 or a zero. It doen't make much difference is the one looks like spaghetti or the zero looks like a doughnut someone has stepped on, if we can tell what it was supposed to be we can use it. Years ago when it became apparent that you could not just keep adding more wire for each phone line the telcos moved to digital. Do you ever remember seeing any really old movies of telephone poles with 50 or more pairs of wires on the crossbars. Then you could only put one signal on one piece of wire. So how do we get more signal on a wire. There is FDM - frequency division multiplexing, and TDM, time division multiplexing. The first is pretty easy to do. Take a signal, and mix it with a higher frequency signal. The freqencies add so the lower frequency is now added to the higher frequency. Filter out the lower part and you have the original signal just move up in frequency. Reverse the process and you get the signal back. But we are still in the analog domain here. If we convert to digital we can take the voice and encode it. The standard rate is 56k. Encoding the audio in 8 bits give us a 7k signal stream. Nyquist theorem says we have to sample at twice the highest frequency we wish to encode. 1/2 of 7K is 3.5. You will typically see telephone lines showing as the bandwidth from about 100-300 on the low end to a bit over 3000 cycles on the top. The signal is transmitted at 64kbits. What? We said 56 before. Yup. 8kbit for signalING and 56kbit for signal and that's 64. If we take a similar approach in digital as we did in the analog mode above, we can encode more than 1 data bit per state. At this point I have forgotten the name of the encoding method and it gives about 3 bits of encoding. The end result is that we can reliably tranmist 140kbit/second on the ISDN line. The 140k comes from the fact that you have two 64K channels carrying data - called B channels - B for bearer, and one 16K D channel, which contols all the signaling. With ISDN it works or it doesn't. And depending on how old the telco equipment is you may only get 56K of data. The original T1 circuits had the 56k for voice and 8k for signalling in one 64K channel. Newer equipment uses 23 channels for B transport and one 64K D channel. THis is much more efficient than having twenty-four 56k and 24 8k channels. The latter would occupy 192k of bandwidth, where the one 64K channel now handles it all giving you effectively two more 64K lines for data transmission. Or to sum up your question paraphrasing Monty Python "It's something completely different". -- Bill Vermillion - bv @ wjv . com
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.
Click here to add your comments
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar