tnixon@hayes.uucp (Toby Nixon) (11/06/90)
In article <90309.054925KPURCELL@LIVERPOOL.AC.UK>, KPURCELL@LIVERPOOL.AC.UK writes: > 1. What is V32bis (I'm familiar with V32, V42, V42bis, PEP, etc ... ) V.32bis is a new standard that is presently in the process of being adopted under accelerated procedures in the CCITT. It received unanimous support from Study Group XVII, and is now being translated into the official CCITT languages so that it can be mailed to all CCITT member countries for the official written ballot. The ballot will close around the end of February 1991, at which time if 70% of the ballots returned are affirmative, V.32bis will be an official CCITT standard. V.32bis is an upwardly-compatible extension of V.32. To the original V.32 speeds of 4800 and 9600, it also adds new speeds of 7200, 12000, and 14400 bps, all with trellis-coding, and all full-duplex. It also adds "rapid rate renegotiation", which allows the modems to respond to changing line conditions by increasing or decreasing the speed in less than 1/10th of a second rather than taking five to ten seconds to do a full retrain. -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
gregh@inmet.inmet.com (01/03/91)
A friend of mine wanted to know how V32bis achieves 14400 bps. Not knowing myself, I thought I would turn to a source of higher knowledge. What in short does V32bis do differently from V32 to achieve the faster speed? Thanks, Greg Herlihy gregh@inmet.inmet.com
tnixon@hayes.uucp (01/03/91)
In article <19700002@inmet>, gregh@inmet.inmet.com writes: > A friend of mine wanted to know how V32bis achieves 14400 bps. > Not knowing myself, I thought I would turn to a source of higher > knowledge. > > What in short does V32bis do differently from V32 to achieve the faster > speed? V.32 and V.32bis use Quadrature Amplitude Modulation. In both standards, the modem's "carrier" is at 1800Hz, and it indicates data by modulating the phase and amplitude of the signal according to certain rules. The phase and amplitude is changed 2400 times per second, and the value of the bits is determined by the phase an amplitude sent during each 1/2400 second period. In V.32, you can transmit at either 4800 or 9600 bps. At 4800, there are 4 possible combinations of phase and amplitude. These four combinations can represent all combinations of two bits (00, 01, 10, 11). Thus, two bits are signalled in each 1/2400 second period, for 4800 bits per second. At 9600, there are 32 possible combinations of phase and amplitude in each period, which means five bits are signalled. However, one of these bits is for redundant encoding of the other four, which helps the receiving modem decide which of the 32 possible combinations is actually being received. Therefore, four user data bits are being transmitted in each 1/2400 sec period, for 9600bps. Since V.32 was standardized, modem technology has progressed so that it's possible to transmit and received more complex signals with greater resolving capability. In V.32bis, all that was done is permit more combinations of phase and amplitude. At 12000bps, there are 64 possible conbinations, and at 14400bps, there are 128 possible combinations. V.32bis also permits 7200bps transmission, with 16 possible combinations. In all three of these cases, trellis coding is used as at 9600bps; thus, the number of user bits per symbol period sent at 7200 is 3, 12000 is 5, and 14400 is 6. The total signal power that a modem is allowed to transmit is governed by national regulations (and the reality of the capabilities of the telephone network!). The average power is determined by the combined amplitude of all of the combinations of phase and amplitude that can be sent in a particular modulation scheme (the modems use scramblers to insure that the transmission is actually spread out over all of the possible combinations). What this means is that the total power of all combinations in the 14400 modulation is limited to the same total power of all combinations in the 9600 modulation. You have 128 combinations of phase and amplitude, whose amplitudes must add up to the same total as the 32 combinations at 9600! This means that these "points" must be closer together. It is therefore more likely that line noise will cause one of the combinations to be misinterpreted by the receiving modem as being a different combination. This means that a V.32bis modem will require a cleaner phone line to transmit 14400 than 9600. You won't necessarily be able to connect at 14400 on all lines, but it should be possible on a majority of circuits -- particularly local lines in the USA. -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
root@zswamp.fidonet.org (Geoffrey Welsh) (01/07/91)
>From: tnixon@hayes.uucp >V.32 and V.32bis use Quadrature Amplitude Modulation. Is it still kosher to refer to them as QAM, even when the coding constellation (is that the proper term?) is more complex than the one described in V.22bis? I was under the impression that QAM was so called because amplitude was used to differentiate between the two possible shifts at the 90 degree angles, while the other angles represented only one bit pair each and did not require aimplitude for differentiation. Anyway, thanks for the tech stuff on V.32, V.32bis, and their 'flavours'. -- UUCP: watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent Internet: root@zswamp.fidonet.org | Kitchener, Ontario FidoNet: SYSOP, 1:221/171 | N2M 5E6 CANADA Data: (519) 742-8939 | (519) 741-9553 MC Hammer, n. Device used to ensure firm seating of MicroChannel boards Try our new Molson 'C' compiler... it specializes in 'case' statements!
bsmith@rose.cis.ohio-state.edu (brentley r smith) (01/09/91)
In article <3713.27832d53@hayes.uucp> tnixon@hayes.uucp writes: =>In article <19700002@inmet>, gregh@inmet.inmet.com writes: =>=> A friend of mine wanted to know how V32bis achieves 14400 bps. =>=> What in short does V32bis do differently from V32 to achieve the faster =>=> speed? => [much deleted] => =>Since V.32 was standardized, modem technology has progressed so that =>it's possible to transmit and received more complex signals with =>greater resolving capability. In V.32bis, all that was done is =>permit more combinations of phase and amplitude. At 12000bps, there =>are 64 possible conbinations, and at 14400bps, there are 128 =>possible combinations. V.32bis also permits 7200bps transmission, =>with 16 possible combinations. In all three of these cases, trellis =>coding is used as at 9600bps; thus, the number of user bits per =>symbol period sent at 7200 is 3, 12000 is 5, and 14400 is 6. => [much deleted] How does V.32bis compare to "HST", U.S. Robotics' proprietary protocol? Are teh mechanics of the protocols similar? Is the (theoretical) throughput similar? Brentley Smith bsmith@cis.ohio-state.edu
tnixon@hayes.uucp (01/10/91)
In article <87110@tut.cis.ohio-state.edu>, bsmith@rose.cis.ohio-state.edu (brentley r smith) writes: > How does V.32bis compare to "HST", U.S. Robotics' proprietary protocol? > Are teh mechanics of the protocols similar? Is the (theoretical) > throughput similar? V.32bis, like V.32, is a duplex modulation scheme -- it transmits and receives in both directions simultaneously at the same rate, using echo cancellation techniques so that both modems can transmit on the same frequencies. HST is "asymmetrical". One modem is transmitting at high speed (up to 14400), while the other is transmitting at low speed (300 or 450 bps). No echo cancellation is used; each modem transmits on a different frequency. Thus, it is incompatible with and quite different from V.32bis. The "constellation" (method of encoding bits into analog signal states) of V.32bis is similar to the HST high-speed modulation. The handshaking and other procedures are quite different. If you only transmit in one direction, the theoretical throughput of V.32bis and HST are identical. The sharp band-edge filters needed to make an asymmetrical modem work do make the HST more susceptible to certain line impairments, but this is traded off against the potentially damaging effects of echo path impairments in V.32bis. Of course, the performance of V.32bis is vastly superior to HST when transmitting in both directions simultaneously, which is required in many high-speed applications. Full-duplex modems are much more flexible in terms of the applications which can be supported. -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
tnixon@hayes.uucp (01/11/91)
In article <6596.27880099@zswamp.fidonet.org>, root@zswamp.fidonet.org (Geoffrey Welsh) writes: > >V.32 and V.32bis use Quadrature Amplitude Modulation. > > Is it still kosher to refer to them as QAM, even when the coding > constellation (is that the proper term?) is more complex than the > one described in V.22bis? I was under the impression that QAM was > so called because amplitude was used to differentiate between the > two possible shifts at the 90 degree angles, while the other angles > represented only one bit pair each and did not require aimplitude > for differentiation. The standards themselves refer to the modulation technique as QAM. My understanding is that the Quadrature part refers to the division of the constellation into quadrants, with the two low-order bits being differentially encoded to select the quadrant of the next signal. The Amplitude part refers to, simply, that the signal is not of constant amplitude; V.22bis uses three different amplitudes, and V.32 at 9600 has five. -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
necka@motcid.UUCP (William J. Necka) (01/12/91)
In article <3722.278c7fbc@hayes.uucp> tnixon@hayes.uucp writes: >In article <87110@tut.cis.ohio-state.edu>, >bsmith@rose.cis.ohio-state.edu (brentley r smith) writes: > >> How does V.32bis compare to "HST", U.S. Robotics' proprietary protocol? >> Are teh mechanics of the protocols similar? Is the (theoretical) >> throughput similar? > [STUFF DELETED] > >If you only transmit in one direction, the theoretical throughput of >V.32bis and HST are identical. The sharp band-edge filters needed >to make an asymmetrical modem work do make the HST more susceptible >to certain line impairments, but this is traded off against the >potentially damaging effects of echo path impairments in V.32bis. >Of course, the performance of V.32bis is vastly superior to HST when >transmitting in both directions simultaneously, which is required in >many high-speed applications. Full-duplex modems are much more >flexible in terms of the applications which can be supported. > [STUFF DELETED] > On the contrary, the success of the HST demonstrates that the majority of applications make little demand in one direction, while maximizing the other. 450 baud is much faster then I or most people out there can type, making it ideal for a user interface, and 14400 baud makes short work out of any X Y or Zmodem file transfer I have ever made. There is one important point you have over-looked. Because the HST does not have too cancel it's own echo, it can train/retain is millseconds instead of seconds. When ever I call long distance and get a bad line, I am very grateful of this. Granted the V.32 performance can be better in full-duplex operation; however that was not its intended design. Providing fast file transfers at a reasonable price was. ______________________________________________________________________________ ------------------------------------------------------------------------------ -- x || William Necka - __/ \__/\/\/\/ \____ Motorola Cellular || uunet!motcid!necka / \__/ \ _/ [][\_ Arligton Heights Il. || Opinions expressed are not \__/ \__/ (________) 708-632-4435 || necessarily my employer's. _____\__/__________()__()________________________||____________________________ -------------------------------------------------------------------------------
casey@gauss.llnl.gov (Casey Leedom) (01/12/91)
| From: necka@motcid.UUCP (William J. Necka) | | | From: tnixon@hayes.uucp (Toby Nixon) | | | | | From: bsmith@rose.cis.ohio-state.edu (brentley r smith) | | | | | | How does V.32bis compare to "HST", U.S. Robotics' proprietary protocol? | | | Are the mechanics of the protocols similar? Is the (theoretical) | | | throughput similar? | | | | If you only transmit in one direction, the theoretical throughput of | | V.32bis and HST are identical. ... Of course, the performance of V.32bis | | is vastly superior to HST when transmitting in both directions | | simultaneously, which is required in many high-speed applications. | | Full-duplex modems are much more flexible in terms of the applications | | which can be supported. | | On the contrary, the success of the HST demonstrates that the | majority of applications make little demand in one direction, while | maximizing the other. Toby didn't say that the majority of applications need to transmit in both directions simultaneously. He said that a full duplex connection offered you more flexibility ``in terms of the applications which can be supported [effectively.]'' But you're right, as long as the applications you want to work with don't need it the full duplex channel, they'll be happy with a half duplex channel like that offered by HST or PEP. However 1. Neither HST or PEP are international standards. With the increasing move towards standards, especially in the typically provincial U.S., this is going to become a big problem disadvantage. 2. Half duplex modems are also going to fall on their face with the increasing incidence of home networks with SLIP/PPP links to work, X Terminals like the GraphOn and NCD/XRemote, and other applications which definitely need a full duplex channel. | Because the HST does not have too cancel it's own echo, it can | train/retain is milliseconds instead of seconds. The long retrain problem has been essentially solved with V.32bis. | Granted the V.32 performance can be better in full-duplex | operation; however that was not its intended design [of HST]. Providing | fast file transfers at a reasonable price was. Last I looked the HST (and PEP) modems were fairly expensive compared to the new V.32 modems appearing from just about every modem manufacturer. I expect that V.32bis will be adopted very quickly by the same manufacturers and competition will push the price down well below the HST (and PEP) proprietary modems. Now, I don't really want to paint too rosy a picture because I'm suffering from V.32 connections dropping all the time in my new home. My PEP connections never drop (I have no idea how well HST does with marginal lines.) Thus, PEP is by no means a ``total failure.'' I just wish we had something that was as robust as PEP and had descent full duplex performance. Casey
jjj@blob.hut.fi (Joni Jaakko J{rvenkyl{) (01/13/91)
In article <89275@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes: >| Because the HST does not have too cancel it's own echo, it can >| train/retain is milliseconds instead of seconds. > > The long retrain problem has been essentially solved with V.32bis. And US Robotics' got this nice feature called ALS, which offers the possibility of shifting the speed also upwards, when line conditions get better! With a normal V32bis modem you get only downwards speed shifting, which may reduce the effectivity of data transfer very much. -- jjj@niksula.hut.fi jjj@otax.tky.hut.fi fire me, fire until you die
tnixon@hayes.uucp (01/14/91)
In article <1991Jan12.161258.19986@santra.uucp>, jjj@blob.hut.fi (Joni Jaakko J{rvenkyl{) writes: > In article <89275@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes: >>| Because the HST does not have too cancel it's own echo, it can >>| train/retain is milliseconds instead of seconds. >> >> The long retrain problem has been essentially solved with V.32bis. > > And US Robotics' got this nice feature called ALS, which offers the > possibility of shifting the speed also upwards, when line conditions get > better! With a normal V32bis modem you get only downwards speed shifting, > which may reduce the effectivity of data transfer very much. This is baloney; regurgitated USR public relations crap. V.32bis supports changing dynamically between any of its five rates! Any V.32bis modem can change rates UP OR DOWN. The question is whether or not a given implementation will _initiate_ a speed change, and the _criteria_ upon which it will initiate the change. Because of the large number of applications in which V.32bis modems will be used (e.g., async non-error-control where changing speeds is explicitly not possible, likewise with synchronous applications where the DTE provides the clock), the criteria and initiation decision are left up to the modem and its implementor. All USR has done is make a decision to permit their modems to initiate changes and, apparently, decided on some criteria on which to base this. Every other V.32bis modem manufacturer will make a similar decision! It really irks me to see a company whose Vice President of Engineering (Dale Walsh of USR) sat in on all of the V.32bis discussions and agreed to them, turn around and flat out misrepresent what the standard says, and claim some unique "feature" that, in reality, is not going to be unique at all. -- Toby Nixon, Principal Engineer | Voice +1-404-449-8791 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (01/15/91)
In article <89275@lll-winken.LLNL.GOV>, casey@gauss.llnl.gov (Casey Leedom) writes: > > But you're right, as long as the applications you want to work with > don't need it the full duplex channel, they'll be happy with a half > duplex channel like that offered by HST or PEP. However > > 1. Neither HST or PEP are international standards. With the > increasing move towards standards, especially in the typically > provincial U.S., this is going to become a big problem > disadvantage. This is the arguement that said OSI would replace TCP/IP by 1985. I know because I took the OSI pledge in 1984. I have since developed an opinion about the accuracy any arguement based on such "circular lemming" logic. "Blank will be popular real soon, because everyone will be using it." > 2. Half duplex modems are also going to fall on their face with the > increasing incidence of home networks with SLIP/PPP links to work, > X Terminals like the GraphOn and NCD/XRemote, and other > applications which definitely need a full duplex channel. On the contrary, X terminals would benefit from a good asymmetric splitting of bandwidth. Consider the nature of your typical xterm TCP traffic, in terms of packet sizes and rates, including TCP acks. I do not know what the right split is nor how dynamic it should be. It's "obvious" that an automatic, instantaneous, infinitely variable split between 28.8/0 and 0/28.8 would be far better than 14.4 full duplex. (Yes, it's also obviously impossible to be either instantaneous or infinitely variable.) The troubles we've seen with machines like the NCD over TB's are not related to PEP, but to NCD's less than heavy weight implementation of TCP/IP. For example, no routing, even RIP, causes some hassle, although it no doubt makes the code in the terminal smaller and easier to maintain. That PEP and HST may be fading does not imply asymmetric modem protocols are dead, any more that the fact that the 300/1200 async, private line modem I used in 1970 is long forgotten, along with the fancy graphics terminal and the computer it connected. Vernon Schryver, vjs@sgi.com
ronald@robobar.co.uk (Ronald S H Khoo) (01/17/91)
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes in defence of the TB+: > On the contrary, X terminals would benefit from a good asymmetric splitting > of bandwidth. But PEP doesn't give you split bandwidth, it gives you half duplex with extremely high cost to turn the line around. Now, if you had a link-level protocol that reduced the number of turnrounds by letting whole windows through before letting the other side speak, you might win. SLIP doesn't do this though, and my cursory glance at PPP doesn't show such an option there either (though I'd be glad to be told that I'm wrong). Am I ? Does such a protocol exist ? -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
ronald@robobar.co.uk (Ronald S H Khoo) (01/17/91)
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > casey@gauss.llnl.gov (Casey Leedom) writes: > > 1. Neither HST or PEP are international standards. With the > > increasing move towards standards, especially in the typically > > provincial U.S., this is going to become a big problem > > disadvantage. > This is the arguement that said OSI would replace TCP/IP by 1985. I know > because I took the OSI pledge in 1984. I have since developed an opinion > about the accuracy any arguement based on such "circular lemming" logic. TCP v. OSI affects end<->end interoperability problems, v.32 vs. PEP only affects individual point-to-point links. The scale of the problem just isn't the same. I suppose we shall see what we shall see. Interesting times..... -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
ejm@ejmmips.NOC.Vitalink.COM (Erik J. Murrey) (01/18/91)
In article <1991Jan16.210914.18482@robobar.co.uk>, ronald@robobar.co.uk (Ronald S H Khoo) writes: > vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes in defence of the TB+: > > > On the contrary, X terminals would benefit from a good asymmetric splitting > > of bandwidth. > > But PEP doesn't give you split bandwidth, it gives you half duplex with > extremely high cost to turn the line around. Now, if you had a > link-level protocol that reduced the number of turnrounds by letting > whole windows through before letting the other side speak, you might > win. SLIP doesn't do this though, and my cursory glance at PPP doesn't > show such an option there either (though I'd be glad to be told that I'm > wrong). Am I ? Does such a protocol exist ? > Both SLIP and PPP only look as far as the IP header for clues on delivery. Even this may be considered too much of a bleed into the network layer when a point-to-point data-link is involved. Both Van Jacobson's Compressed SLIP and his extensions to PPP look as far as the TCP header to determine compressability. If SLIP or PPP were to provide TCP window optimization over the data-link, then it would have to really dig into both the TCP header and the TCP options to determine window size/status, etc. While sometimes these optimizations are necessary to give a product an edge in the market, I usually shy away from code that is *too* smart. I tend to think that better optimization of IP over half-duplex links can be done with smarter queuing algorithms coupled with starvation prevention measures. On the local machine, this may actually give the feeling that entire windows are being sent at once, since all the segments may be queued in one shot from the TCP code. --- Erik J. Murrey Vitalink Communications NOC ejm@NOC.Vitalink.COM ...!uunet!NOC.Vitalink.COM!ejm
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (01/18/91)
In article <1991Jan16.210914.18482@robobar.co.uk>, ronald@robobar.co.uk (Ronald S H Khoo) writes: > vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes in defence of the TB+: > > > On the contrary, X terminals would benefit from a good asymmetric splitting > > of bandwidth. > > But PEP doesn't give you split bandwidth, it gives you half duplex with > extremely high cost to turn the line around. ... I was trying to say is that a magical way to automatically and dynamically allocate bandwidth between the two directions would be better than any fixed allocation, including 50/50. Whether this magic would consist of devoting 100% of the bandwidth to one direction for X% of the time and 100% of the bandwidth to the other direction for (100-X-Z)% of the time (ie. what is often called "half duplex") is an separate issue. It may be that at the low speeds and analog phone lines being discussed, no such magic is possible, or that the magic would cost too many bits computed as [sum (wasted bandwidth*wasted time)]. I've not been initiated into the right kinds of wizardry to know. It is obvious that if you must fix the allocation between the two directions (if the system including modems cannot change this allocation as traffic or other conditions warrent) and if your traffic is "general," then 50/50 is the best general purpose answer (e.g. v.32), provided 50% of the total is gives usable performance. It seems obvious that an old fashioned, half-duplex 2400 b/s modem with would support X traffic less badly than a 1200 b/s full duplex modem, despite the long turn-around times of such old hdx modems. At medium and high speed, things tend to be more dynamic. Imagine how slow ethernet would be if the ~10MHz were permanently partitioned into rx and tx allocations for each station. (Common, commercially available, relatively low cost workstations move >1MByte/sec through TCP/IP/ethernet.) Sheesh! I didn't realize I was so mumble-mouthed to be repeatedly misunderstood on such an obvious point. Vernon Schryver, vjs@sgi.com