ncpmont@brahms.amd.com (Mark Montgomery) (12/08/90)
I have been somewhat daunted by the recently explosive growth of info on high(er) speed modems in this group. One question that comes to mind is why isn't some modem manufacturer that already has a handle on V.32, V.42, bis, etc putting PEP into their products? Seems like that would not only be a good marketing boost but also give some competition to Telebit who seems to own the Unix connectivity market. Just a thought, Mark
mju@mudos.ann-arbor.mi.us (Marc Unangst) (12/11/90)
ncpmont@brahms.amd.com (Mark Montgomery) writes: > mind is why isn't some modem manufacturer that already has a handle > on V.32, V.42, bis, etc putting PEP into their products? Seems like > that would not only be a good marketing boost but also give some > competition to Telebit who seems to own the Unix connectivity market. Mostly because Telebit also owns the PEP protocol. They invented it, and they can decided who gets to use it. I believe Telebit is behaving like Microcom, who refused to license the MNP protocols above 5 to other manufacturers, preferring to have all of a small pie than a smaller piece of a big pie. Also, there are superior protocols. Even though PEP holds a noisy line very well, it is mostly half-duplex, and other protocols such as V.32bis will beat it out for raw throughput most of the time. PEP is also not so good for interactive use (see HDX note above). When PEP was invented, it was great -- and it still is great for some applications. But I don't think the sales would be large enough for another company to justify licensing the protocol from Telebit, even if Telebit was willing. -- Marc Unangst | mju@mudos.ann-arbor.mi.us | "Bus error: passengers dumped" ...!umich!leebai!mudos!mju |
dcaulkins@cdp.UUCP (12/11/90)
Telebit's PEP protocol is both proprietary and patented. It is possible that Telebit might license other manufacturers, but I suspect they would not do so unless they saw this as increasing their net revenues. Telebit people read comp.dcom.modems - maybe they will comment. Dave C
gsteckel@vergil.East.Sun.COM (Geoff Steckel - Sun BOS Hardware) (12/12/90)
In article <8sHZT4w163w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >ncpmont@brahms.amd.com (Mark Montgomery) writes: >> mind is why isn't some modem manufacturer that already has a handle >> on V.32, V.42, bis, etc putting PEP into their products? Seems like >> that would not only be a good marketing boost but also give some >> competition to Telebit who seems to own the Unix connectivity market. > >Mostly because Telebit also owns the PEP protocol. They invented it, >and they can decided who gets to use it. Does anybody remember Vadic (now Racal-Vadic) 1200 bps modems? They were the first (and still technically superior to Bell 212) full duplex 1200 bps modems. Vadic refused to license any of the protocols. Bell announced 212, and after a couple of years, released it for general use. Result: Vadic was incompatible with all the other 1200 bps units, and that protocol died as a result. It was a pity at the time, since Bell picked 2 carrier frequencies which were harmonically related and interfered with each other if line distortion was high. Open letter to Telebit: if you think PEP is worth anything, licence it (with or without fee). Otherwise it will be bypassed by a (possibly inferior) but widely available standard. V.32 is coming up fast. Anecdote: until the patents run (ran?) out, Phillips N.V. collects a very small (apocryphally $.05) royalty on all audio cassettes. They also refuse to allow any modification to cassette designs which will cause incompatibility. They will licence to anybody, anywhere, cheaply. Result: Phillips survives immense losses on practically all its other products. Cassettes are the largest selling recorded music medium. geoff steckel (gwes@wjh12.harvard.EDU) (...!husc6!wjh12!omnivore!gws) Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line. This posting is entirely the author's responsibility.
casey@gauss.llnl.gov (Casey Leedom) (12/12/90)
| From: gsteckel@vergil.East.Sun.COM (Geoff Steckel - Sun BOS Hardware) | | >From: mju@mudos.ann-arbor.mi.us (Marc Unangst) | > | >>From: ncpmont@brahms.amd.com (Mark Montgomery) | >> | >> ... why isn't some modem manufacturer that already has a handle | >> on V.32, V.42, bis, etc putting PEP into their products? | > | >Mostly because Telebit also owns the PEP protocol. They invented it, | >and they can decided who gets to use it. | | Open letter to Telebit: if you think PEP is worth anything, license it | (with or without fee). Otherwise it will be bypassed by a (possibly | inferior) but widely available standard. V.32 is coming up fast. Telebit's DAMQAM (Dynamic Adaptive Multicarrier Quadrature Amplitude Modulation) has a couple of definite features over V.32 and possibly even the upcoming V.32bis standard: o Ability to handle line noise and changing line conditions. o Higher raw bandwidth -- in one direction at a time. From what I understand, PEP (Packetized Ensemble Protocol) is simply a special packetizing and error detection/correction protocol designed to live on top of DAMQAM and provide a simulated full duplex interface. The spoofing of various higher level protocols to increase overall throughput rates are a completely separate issue and could be layered on top of any ``error free'' channel. The protocol spoofing is nice, but mostly a because of stupidity in the higher layer protocols -- notably a fixed window size of 1. (From what I understand, SLIP spoofing, when it becomes available, will actually be making up for the half duplex nature of DAMQAM.) Nevertheless, in this world of stupid higher level protocols, the spoofing is a definite advantage. My only complaint is that I should be able to do it over any ``error free'' channel, such as V.32/V.42/V.42bis. PEP is simply a packetization protocol. Who cares? Please feel free to flame me if I'm misstating the extent of PEP's features. But, the real winner is DAMQAM. After struggling with a V.32 connection for the last couple of weeks with the best length of connection being ninety minutes I've changed my mind about telling people to forget ``PEP'' modems and just go with V.32. My only problem is I can't stand using PEP. The echo delays are terrible to behold when I try to use my X terminal and it's just barely passable with a normal terminal. Visual editors are gruesome. It would be really nice if Telebit could come up with a follow on to DAMQAM that was ``TRUE'' full duplex ala the V.32/V.32bis echo cancellation. Really nice. Incredible nice. Can you imagine it? Roughly 18Kbps full duplex and reliable over the worst lines? Layer V.42/V.42bis on top of that and you'd have one mean communications link ... such a modem would also, of course, have to support ``TRUE'' 38.4Kbps ... :-) Oh course, in line with the note that I'm following up, it would have to be licensed very cheaply for such a scheme to become widely used or adopted as a new CCITT standard ... Casey
bob@MorningStar.Com (Bob Sutterfield) (12/13/90)
In article <87673@lll-winken.LLNL.GOV> casey@gauss.llnl.gov (Casey Leedom) writes:
I should be able to do [protocol spoofing] over any ``error free''
channel, such as V.32/V.42/V.42bis.
According to the T2500 firmware version GE7.00 release notes,
Protocol Support in V.32 Mode
All file transfer protocols defined by the S111
register are now supported when a MNP connection is
established in V.32 mode.
No mention (yet?) of spoofing support over a V.42/V.42bis connection.cec@cup.portal.com (Cerafin E Castillo) (12/13/90)
Casey quotes and writes: | Open letter to Telebit: if you think PEP is worth anything, license it | (with or without fee). Otherwise it will be bypassed by a (possibly | inferior) but widely available standard. V.32 is coming up fast. Telebit does license PEP/DAMQAM in an 18 kbps non-LZ compression (No S110) form to Ventel (ie Ventel Pathfinder) and Racal-Milgo (1822S). Various form factors have also been available in the DCA Fastlink, GTE TrailBlazer, etc., mostly OEM-type deals. >Telebit's DAMQAM (Dynamic Adaptive Multicarrier Quadrature Amplitude >Modulation) has a couple of definite features over V.32 and possibly even >the upcoming V.32bis standard: > > o Ability to handle line noise and changing line conditions. > > o Higher raw bandwidth -- in one direction at a time. This is true. the one direction at a time (half-duplex / "adaptive duplex) is a benefit, as well as a problem, especially in interactive work. > The protocol spoofing is nice, but mostly a because of stupidity in the >higher layer protocols -- notably a fixed window size of 1. Correct. In UNIX UUCP ('g' protocol), the window size is usually a fixed size of 3. SCO UNIX and other such O/S UUCPs have adjustable sizings up to 7 for use with slower (<= V.32) modems. PEP forces a window size of 3, then performs the spoof at each end in order to be able to do the PEP/DAMQAM (half-duplex) modulation between the two modems without causing the full duplex 'g' protocol to timeout. Both a necessity and a feature! This comes in handy with UUPC, Waffle, or other such DOS programs with a window size of 1. The spoof will automatically make this software do a 3 window size and effect performance radically (if the serial I/O drivers can hack it! ;-). >(From what I understand, SLIP spoofing, when it becomes available, will >actually be making up for the half duplex nature of DAMQAM.) SLIP spoofing, from what Telebit has told me, will never exist. the Telebit NetBlazer is the current SLIP/CSLIP/PPP solution offered by Telebit. As to protocol spoofing: >My only complaint is that I should be able to do it (protocol spoofing) >over any ``error free'' channel, such as V.32/V.42/V.42bis. You can. The current GF7.00 firmware for T2500/T1500 allows protocol support in V.32 (with or without V.42/V.42bis) between Telebit modems (ONLY!). The New, T1600 modem is also capable of doing this. From my test of this firmware feature, it is not very impressive. Maybe a 10% gain over raw V.32 throughput. > PEP is simply a packetization protocol. Who cares? Please feel free >to flame me if I'm misstating the extent of PEP's features. No problem. PEP is a sales/marketing term for the layman. DAMQAM is the correct modulation method. PEP is just an ECC layer. > But, the real winner is DAMQAM. >After struggling with a V.32 connection for the last couple of weeks... >I've changed my mind about telling people to forget ``PEP'' modems and >just go with V.32. I have to agree. V.32, and for that fact V.32bis or V.32turbo (Rockwell option) all using single carrier technology and echo cancellation/trellis techniques, are only as good as the line you are using them on. While this is true for DAMQAM as well, the multicarrier technology assures that you will find available carriers for your data on any phone line (except a dead one...;-) amongst the 511 carriers it makes avaialble. Furthermore, you will be able to move anywheres from 2,4, or 6 bits of data through these carriers at speeds between 7.3 and 88.26 baud. Of course, those of you who know about the hidden registers (See Telebit Tech Support for documentation...) also know of how to squeeze even more throughput out of a bad line using DAMQAM packetization modification methods. 38.4 kbps is available on the T1600. > My only problem is I can't stand using PEP. The echo delays are >terrible to behold when I try to use my X terminal and it's just barely >passable with a normal terminal. Visual editors are gruesome. I agree. I use V.32 with V.42bis compression in the receive direction when using a Graphon OptimaX 200 X-Windows solution. Since the mouse and typing yielded small bits of data as opposed to the screen redraws coming in from the system, this method worked well, but not always reliably. This was due to the combination of V.32 line problems. PEP was very frustrating to deal with and could not provide this level of intelligence in handling data on a per carrier basis. > It would be really nice if Telebit could come up with a follow on to >DAMQAM that was ``TRUE'' full duplex... >support ``TRUE'' 38.4Kbps ... :-) V.34 Asym seemed to have died in CCITT. This was the proposal for a 28 Kbps PEP with a reverse 300-600 channel. Maybe in light of multicarrier cellular, satellite, microwave, or fax modulation methods, it might be given new life... I hope these personal and technical insights help. As a Telebit modem user I share the same problems and complaints, but have the added benefit of a little more product education thanks to Telebit. =============================================================================== Cerafin E. Castillo || //\\ ||\\ || Network Consultant || //__\\ || \\ || Los Altos Los Altos Networks || // ---\\|| \\|| Networks 340 Second St. #6 ||___// \ | \ | Los Altos, CA 94022 (415) 941-8031 UUCP: {apple,sun,uunet}!portal!cup.portal.com!cec INTERNET: cec@cup.portal.com "...No hay mal que por bien no venga..." ===============================================================================
casey@gauss.llnl.gov (Casey Leedom) (12/13/90)
| From: cec@cup.portal.com (Cerafin E Castillo) | | >| Open letter to Telebit: if you think PEP is worth anything, license it | >| (with or without fee). Otherwise it will be bypassed by a (possibly | >| inferior) but widely available standard. V.32 is coming up fast. | | Telebit does license PEP/DAMQAM in an 18 kbps non-LZ compression (No S110) | form to Ventel (ie Ventel Pathfinder) and Racal-Milgo (1822S). Various | form factors have also been available in the DCA Fastlink, GTE TrailBlazer, | etc., mostly OEM-type deals. Since I expect that V.42bis is probably nearly as good or better than PEP's LZ compression, the lack of compression isn't a problem except that Telebit doesn't support V.42/V.42bis on top of DAMQAM (you'd actually have to have a layer between performing the adaptive-(sic)-duplex, but that's just an implementation issue.) By withholding their LZ compression it sounds like Telebit was just trying to prevent its licensees from being competitive with Telebit's products. This just emphasizes the earlier poster's point. I also agree with another poster who mentions the Phillips Cassette as an example. I'd bet that if Telebit were to cheaply license their technology out for, say, $5 a modem to any and all comers, a CCITT standard would be rapidly forthcoming and Telebit would be amazed at how much money they made without even making product ... | >Telebit's DAMQAM (Dynamic Adaptive Multicarrier Quadrature Amplitude | >Modulation) has a couple of definite features over V.32 and possibly even | >the upcoming V.32bis standard: | > | > o Ability to handle line noise and changing line conditions. | > | > o Higher raw bandwidth -- in one direction at a time. | | This is true. The one direction at a time (half-duplex / adaptive-duplex) | is a benefit, as well as a problem, especially in interactive work. Except that half-duplex/adaptive-duplex is not the reason for DAMQAM's robustness with regard to line problems. Multi-carrier technology is. You all but say this later on, but I think it's important to stress it here. As for the half-duplex nature of DAMQAM ... I mostly count that as a massive headache with higher single direction bandwidth offered as a salve. I used to complain bitterly about the fixed receive/transmit channel allocation (essentially half-duplex) and ask why Telebit hadn't used dynamic channel allocation based on measured receive/transmit loads. Recently I heard a rumor that Telebit was working on a new multi-carrier technology that used echo cancellation on each of the sub-carriers to produce ``TRUE'' full-duplex. I would really love to see this happen. | > The protocol spoofing is nice, but mostly a because of stupidity in the | >higher layer protocols -- notably a fixed window size of 1. | | In UNIX UUCP ('g' protocol), the window size is usually a fixed size of | 3. SCO UNIX and other such O/S UUCPs have adjustable sizings up to 7 for | use with slower (<= V.32) modems. PEP forces a window size of 3, then | performs the spoof at each end in order to be able to do the PEP/DAMQAM | (half-duplex) modulation between the two modems without causing the full | duplex 'g' protocol to timeout. Actually UUCP (really uucico) is 100% half-duplex. It only transmits files in one direction at a time. The big problem with the UUCP 'g' protocol and PEP modems is that the ACK packets are big enough to cause the line to turn around introducing huge delays for each packet. Since the data packets are very small this drops your throughput a lot. The other advantage of spoofing that I mentioned earlier is that it helps keep the data pipeline loaded when protocols using small windows are used on long delay links. | >My only complaint is that I should be able to do it (protocol spoofing) | >over any ``error free'' channel, such as V.32/V.42/V.42bis. | | You can. The current GE7.00 firmware for T2500/T1500 allows protocol | support in V.32 (with or without V.42/V.42bis) between Telebit modems | (ONLY!). The New, T1600 modem is also capable of doing this. From my | test of this firmware feature, it is not very impressive. Maybe a 10% | gain over raw V.32 throughput. My mistake -- I should have read the manual. I would expect it to work only with other Telebits since I don't know of any other modems that implement spoofing of any kind (I expect that the Ventels using licensed Telebit technology may spoof protocols, but even if they do they wouldn't have gotten the new code from Telebit yet.) As for it's impressiveness, which protocols did you try? My bet is that you only tried UUCP 'g' protocol. With a full-duplex data path, the only advantage that spoofing could offer would be to keep the pipeline full. If there's not much delay in the total link, even UUCP 'g's 3 packet window should do okay at that. On the other hand, I'd expect to see a lot of improvement for the 1 packet window protocols for kermit and xmodem. | >(From what I understand, SLIP spoofing, when it becomes available, will | >actually be making up for the half duplex nature of DAMQAM.) | | SLIP spoofing, from what Telebit has told me, will never exist. the | Telebit NetBlazer is the current SLIP/CSLIP/PPP solution offered by | Telebit. I'm really going to have to look at that product. I'm beginning to think that it might be the right thing to use for tele-commuting ... On the other hand, it would still be slave to the underlaying modem technology and I think that my comments above and in my previous posting point out my feelings on this with regard to DAMQAM. | ... Of course, those of you who know about the hidden registers (See | Telebit Tech Support for documentation...) also know of how to squeeze | even more throughput out of a bad line using DAMQAM packetization | modification methods. 38.4 kbps is available on the T1600. But is there any help for the half-duplex nature of DAMQAM. I mean, I'm not just relating third hand hearsay. I'm typing over it right this second and I can't stand it. If the line quality between my new house and my work were better I'd never use DAMQAM. I can only hope that the rumors I've heard are true and that we'll see a new version of DAMQAM coming out of Telebit. And of course, in line with the my previous posting and the posting I was following up at that time, I hope that Telebit promises to license the technology cheaply to anyone who asks in order to promote wide acceptance and CCITT standardization. | > It would be really nice if Telebit could come up with a follow on to | >DAMQAM that was ``TRUE'' full duplex... [[see above]] | >support ``TRUE'' 38.4Kbps ... :-) | | V.34 Asym seemed to have died in CCITT. This was the proposal for a 28 | Kbps PEP with a reverse 300-600 channel. Maybe in light of multicarrier | cellular, satellite, microwave, or fax modulation methods, it might be | given new life... Personally I hope it stays dead (no offense intended.) I would rather see a dynamic channel allocation scheme standardized and much rather see a full-duplex multi-carrier standard. If CCITT were to standardize around a full-duplex multi-carrier technology right now before any company has a product (and therefore a market advantage*) much as they standardized on V.32 before any product existed, I think that it would stimulate product development in the same way the V.32 standard did. * Note that Telebit is going to have a market advantage in *any* multi-carrier technology because of their background in the field. There's really nothing that can or should be done about that. They took the risks of developing and pushing multi-carrier technology before any standard existed. If multi-carrier technology turns out to be The Hot Tip, they deserve a jump on the rest of the pack. However, they don't deserve a monopoly ... (My opinion obviously.) Casey
tempest@walleye.uucp (Kenneth K.F. Lui) (12/14/90)
In article <36853@cup.portal.com> cec@cup.portal.com (Cerafin E Castillo) writes: >I agree. I use V.32 with V.42bis compression in the receive direction >when using a Graphon OptimaX 200 X-Windows solution. Since the mouse Is there an advantage in selecting V.42bis compression in the receive direction rather than for both? I have data compression selected for both sending and receiving on my T2500 because V.42bis isn't supposed to expand files. Does selecting both tax the CPU that much more as to degrade other areas of performance? Ken ______________________________________________________________________________ tempest@ecst.csuchico.edu, tempest@walleye.ecst.csuchico.edu,|Kenneth K.F. Lui| tempest@sutro.sfsu.edu, tempest@wet.UUCP |________________|
tnixon@hayes.uucp (12/14/90)
In article <3592@jaytee.East.Sun.COM>, gsteckel@vergil.East.Sun.COM (Geoff Steckel - Sun BOS Hardware) writes: > Open letter to Telebit: if you think PEP is worth anything, licence > it (with or without fee). Otherwise it will be bypassed by a (possibly > inferior) but widely available standard. V.32 is coming up fast. It's clear that most people are not aware of activities in CCITT Study Group XVII (the international standards committee on modems) and TIA TR-30 (the US national standards committee on modems) related to PEP. I'm an active participant in these and other standards organizations, and maybe I can shed some light on it. Telebit has been trying for at least five years to get the standards community to buy into multicarrier modulation, and have failed. There are many technical reasons: the long propagation delay through a multicarrier system, the half-duplex nature (echo cancellation capability is claimed, but has not been demonstrated even on paper), the complexities of supporting synchronous communications and async comm without buffering and flow control, etc. Telebit's persistence in trying to get multicarrier considered as the modulation standard for "V.asym" (asymmetrical modem standard) stalled, and eventually killed, that project. It turned into "V.17", an application-specific modulation technique for high-speed Group 3 fax, rather than the general-purpose low-cost high-speed modem it was intended to be. Now, the CCITT is working on the "V.fast" standard (full-duplex modulation above 14,400bps), and once again Telebit has proposed multicarrier. The schedule calls for test results of a full-duplex system to be available at the SG XVII meeting in April; the group can't wait any longer than that, or they won't be able to complete work by the end of 1992 (the scheduled completion date for V.fast). The Codex's, General Datacomm's, and Racal-Milgo's of the world won't let this project be stalled the way V.asym was stalled. I sincerely hope that Telebit can demonstrate multicarrier echo cancellation, because I'd like to see multicarrier get fair consideration; but I'm not optimistic. The problem is not that Telebit has been unwilling to license their patents related to multicarrier modulation, or has been keeping it secret. In fact, they've been quite open about how it works (in multitudinous contributions to TIA and CCITT) and actively trying to sell licenses, but have been met with a resounding yawn. A couple of companies licensed the technology, including Ven-Tel and Anderson-Jacobsen, and Intelligent Modem Corporation (Forval) apparently has come up with a different multicarrier scheme (and is supporting multicarrier in SG XVII for V.fast). But most modem companies want their products to serve a broad spectrum of applications, and this means providing true full-duplex modems with low propagation delay. -- 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