gorpong@ping.chi.il.us (Gordon C. Galligher) (03/04/91)
Please forgive me if this is the wrong newsgroup, and if it is, then just hit 'r' and tell me where the right one is and I will go away. I have been evaluating Hayes Smartmodem 9600 V.42 modems, and have had some interesting results. Going UUCP, the modems connect at 9600, and have their distinctive connect tones, but the best throughput on the line has been 311 characters per second (for a 121 K file). Is there a special UUCP setup that these modems require in order to get speeds comparable of a 9600 modem? I may be wrong, but I was under the impression that 9600 baud means 960 cps. I realize that 960cps is a total dream-world, but I am only getting 1/3 of that, and 2/3 overhead for uucico communication is hardly what I would expect. Next question: Am I correct in thinking that there is no way to get the modem to connect 9600 to anything but another Hayes? How can modem companies get away with this proprietary-ism when so many people are screaming for open systems? We want open systems, but we settle for proprietary connections between them? This is absurd! OK, I did not come here to give speeches, and I apologize for wasting bandwidth. I would, however, appreciate any help, suggestions, whatever, in response to my questions (or even just a pointer to which newsgroup this belongs). Thank you very much for your time. -- Gordon. -- Gordon C. Galligher 9127 Potter Rd. #2E Des Plaines, IL 60016-4881 gorpong@ping.chi.il.us gorpong%ping@uu.psi.com ...!uu.psi.com!ping!gorpong "I know how it works....That's why I don't like it" -- Chip Salzenberg on SCO "UNIX" C2 Security Package
tnixon@hayes.uucp (03/04/91)
In article <1991Mar4.025731.21550@ping.chi.il.us>, gorpong@ping.chi.il.us (Gordon C. Galligher) writes: > I have been evaluating Hayes Smartmodem 9600 V.42 modems, and have had some > interesting results. Going UUCP, the modems connect at 9600, and have their > distinctive connect tones, but the best throughput on the line has been 311 > characters per second (for a 121 K file). Is there a special UUCP setup that > these modems require in order to get speeds comparable of a 9600 modem? I > may be wrong, but I was under the impression that 9600 baud means 960 cps. > I realize that 960cps is a total dream-world, but I am only getting 1/3 of > that, and 2/3 overhead for uucico communication is hardly what I would > expect. Like any other error-control modem, the VSM9600 performs best with a protocol that doesn't stop and wait for acknowledgements after every frame. I'm not familiar enough with UUCP to suggest what settings or alternatives you might have to consider to make it work better. The VSM9600 generally works better than PEP with stop-and-wait protocols because its turnaround time is so much faster, but there will nevertheless be some degradation from optimum. > Next question: Am I correct in thinking that there is no way to get the > modem to connect 9600 to anything but another Hayes? Yes. > How can modem companies > get away with this proprietary-ism when so many people are screaming for > open systems? When the VSM9600 was developed, V.32 modems were selling for $2,500+. People were screaming for _speed_ more than they were screaming for _compatibility_ or _compliance_. Hayes, USRobotics, Microcom, Telebit, Racal-Vadic, and a bunch of other companies responded by (1) continuing to work hard on technology that would bring down the cost of V.32 modems, and (2) introducing, as an interim solution, proprietary, non-standard modulation schemes that could be implemented at a lower cost. These were assumed to be viable for some period of time (a couple of years maybe?) until technology got to the point where standardized schemes could be implemented and sold for an acceptable price (less than the cost of the PC, for example). > We want open systems, but we settle for proprietary connections > between them? Not everybody WANTS open systems! There are many people who specifically choose proprietary, non-standard modems because it limits the number of modems that can connect with their systems, and therefore limits the number of possible security violations. Others like the lower cost of the non-standard schemes, and are willing to give up compatibility for that. But it's a mistake to buy a non-standard product in hope that it will become a widespread standard. One buys non-standard high-speed modems because one has a relatively closed environment with control over both ends of the connection, has an immediate need for high-speed data, and believes that the benefits of the higher speed will pay back the investment in the non-standard modem fast enough that the incompatibility with the standard is not important. Many, many people made these calculations, and bought non-standard high-speed modems as a result. Would I do it today? Probably not, unless I had a significant installed base of a particular type of modem for which I wanted to retain _internal_ compatibility, but even then I'd opt for a modem that provided both the non-standard modulation and V.32 (which most vendors have on the market today). I can't imagine, with the low cost of V.32 modems today, buying a new non-standard high-speed modem that has no installed base at all. -- Toby -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 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
larry@nstar.rn.com (Larry Snyder) (03/04/91)
gorpong@ping.chi.il.us (Gordon C. Galligher) writes: >I have been evaluating Hayes Smartmodem 9600 V.42 modems, and have had some >interesting results. Going UUCP, the modems connect at 9600, and have their >distinctive connect tones, but the best throughput on the line has been 311 >characters per second (for a 121 K file). Is there a special UUCP setup that >these modems require in order to get speeds comparable of a 9600 modem? I >may be wrong, but I was under the impression that 9600 baud means 960 cps. Yes 960 cps means 9600 baud - but doing uucp with these modems in the real world only yields throughput of around 350 cps. Likewise the HST modems which produce transfers in the 1650 cps range using zmodem, but uucp throughput with the HST runs around 350 cps as well. -- Larry Snyder, NSTAR Public Access Unix 219-289-0287 (HST/PEP/V.32/v.42bis) regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}
kevin@msa3b.UUCP (Kevin P. Kleinfelter) (03/04/91)
gorpong@ping.chi.il.us (Gordon C. Galligher) writes: >Please forgive me if this is the wrong newsgroup, and if it is, then >just hit 'r' and tell me where the right one is and I will go away. >I have been evaluating Hayes Smartmodem 9600 V.42 modems, and have had some >interesting results. Going UUCP, the modems connect at 9600, and have their >distinctive connect tones, but the best throughput on the line has been 311 >characters per second (for a 121 K file). Is there a special UUCP setup that >these modems require in order to get speeds comparable of a 9600 modem? I >may be wrong, but I was under the impression that 9600 baud means 960 cps. >I realize that 960cps is a total dream-world, but I am only getting 1/3 of >that, and 2/3 overhead for uucico communication is hardly what I would >expect. If your machine supports RTS/CTS flow control, I recommend setting your 9600 to 19200. This will speed things up. We use Hayes 9600 modems with our in-house protocol, and find them faster than many other modem (strictly on our in-house protocol, which we tweaked). >Next question: Am I correct in thinking that there is no way to get the >modem to connect 9600 to anything but another Hayes? How can modem companies >get away with this proprietary-ism when so many people are screaming for >open systems? We want open systems, but we settle for proprietary connections >between them? This is absurd! ... Not absurd, just unfortunate. Before there was a V.32, we upgraded to 19200 using the Hayes 9600 V-Series. We had several hundred clients purchase these modems. We now have to support those clients. (So we have purchased a bunch of Hayes Ultra modems, to support the old and the new.) Similar logic applies to other manufacturers' proprietary protocols. Then you have things like the Telebit spoofing -- once again, there is no standard for spoofing modems. It takes two of the same manufacturer's modems to get the speedup. If the community demands it, a standard can be created for just about anything, including spoofing over V.32. The nature of innovation is that it usually occurs before standardization. When you want to do something better than the existing standard, you go off and do it, and then try to get your way declared to be a standard. Other people do the same. The standard grows from the combined experience of the innovators. -- Kevin Kleinfelter @ Dun and Bradstreet Software, Inc (404) 239-2347 {emory,gatech}!nanovx!msa3b!kevin Look closely at the return address. It is nanovx and NOT nanovAx.
david@llustig.palo-alto.ca.us (David Schachter) (03/05/91)
In article <3827.27d24b3a@hayes.uucp> tnixon@hayes.uucp writes: >Like any other error-control modem, the VSM9600 performs best with a >protocol that doesn't stop and wait for acknowledgements after every >frame. I'm not familiar enough with UUCP to suggest what settings >or alternatives you might have to consider to make it work better. >The VSM9600 generally works better than PEP with stop-and-wait >protocols because its turnaround time is so much faster, but there >will nevertheless be some degradation from optimum. Toby is being a bit disingenuous here. His "The VSM9600 generally works better than PEP with stop-and-wait protocols" is true for non-spoofed protocols. The original interrogative was why the Hayes modem runs like a dead dog on a hot August day with uucp; for UUCP, PEP beats the Hayes by a country mile because PEP spoofs UUCP, converting into a non-stop-and-wait protocol. <<FLAME WARNING>> Toby's articles generally have a low hype-to-information ratio but this one seemed to be worded Just So. I respect Toby a lot; surely someone cracked his account and faked his article. The Telebit PEP modems with UUCP spoofing have proven themselves over and over and over; even the Energizer bunny rabbit is a Johnny-come-lately compared to them. If you want good UUCP performance over a regular dial-up phone line, you have two choices: buy an non-Telebit modem and complain about lousy UUCP throughput, or buy a Telebit and save money and headaches. If you opt for the first alter- rnative, you can buy an expensive Hayes modem, to support Toby's Usenet news habit and get a modem which works quite well, or you can buy a cheapo modem from a cheapo company and get a modem which may work well enough. You'll curse yourself later, whichever solution you pick, but at least with the cheapo modem you haven't wasted as much money initially. Or you can buy a Telebit, spend a few hours cursing the manual, and never worry about UUCP performance and crummy phone lines again. The Telebit will connect on incredibly bad phone lines and spoof UUCP's send-and-wait protocol to get the data through, quickly and without complaint, over and over and over. No, I don't have stock in 'em; I do have Telebits. Various other parts of the systems I fiddle with die, burn out, fail, go bonkers, eat the big one, and join that great Computer Center in the Sky; my Telebits just keep on working. Now if Hayes would like to get on the wagon instead of trying to tip it over... <<FLAME OFF>> David Schachter voice phone: +1 415 328 7425 internet: david@llustig.palo-alto.ca.us uucp: ...!{decwrl,mips,sgi}!llustig!david -- David Schachter voice phone: +1 415 328 7425 internet: david@llustig.palo-alto.ca.us uucp: ...!{decwrl,mips,sgi}!llustig!david
em@dce.ie (Eamonn McManus) (03/06/91)
gorpong@ping.chi.il.us (Gordon C. Galligher) writes: >I have been evaluating Hayes Smartmodem 9600 V.42 modems, and have had some >interesting results. Going UUCP, the modems connect at 9600, and have their >distinctive connect tones, but the best throughput on the line has been 311 >characters per second (for a 121 K file). ... > "I know how it works....That's why I don't like it" > -- Chip Salzenberg on SCO "UNIX" C2 Security Package It's worth noting that there is a bug in at least some SCO Unix systems (e.g., the one we have) that causes uucico to report a throughput that is half the real figure, in its log files. So if you did not try timing it yourself, do so; you may find that the throughput is really 622 cps which is at least somewhat more reasonable. You should be able to get at least 800 cps on a good connection with otherwise idle machines, though. UUCP is a windowed protocol, so its throughput will be impaired if you are using a modem that only transmits in one direction at a time. I believe the Hayes Smartmodem 9600 has this property. , Eamonn
tnixon@hayes.uucp (03/06/91)
In article <1991Mar5.093318.2146@llustig.palo-alto.ca.us>, david@llustig.palo-alto.ca.us (David Schachter) writes: > In article <3827.27d24b3a@hayes.uucp> tnixon@hayes.uucp writes: > > for UUCP, PEP beats the Hayes by a country mile because > PEP spoofs UUCP, converting into a non-stop-and-wait protocol. PEP doesn't spoof UUCP. Spoofing is not a function of PEP, but it is a higher-layer function of Telebit modems. Now, I know this may be splitting hairs, but my original discussion was regarding the modulation schemes and associated low-level functions themselves, not higher-level functions specialized for particular DTE interfaces. Spoofing could be added to the VSM9600, too, but we prefer (now) to channel people who use stop-and-wait protocols to a full-duplex modem instead. > <<FLAME WARNING>> > Toby's articles generally have a low hype-to-information ratio but this one > seemed to be worded Just So. I respect Toby a lot; surely someone cracked his > account and faked his article. If that's as hot as your flames get, them I'll just bask in the gentle warmth. I appreciate your noticing that I try to keep the hype to a minimum (and usually apologize in advance when I don't!). And the article was written by me, thank you. I'm always careful to word things "Just So", as you put it, to avoid the wrath of Hayes' PR department. > If you want good UUCP performance over a regular dial-up phone line, you have > two choices: buy an non-Telebit modem and complain about lousy UUCP throughput, > or buy a Telebit and save money and headaches. I strongly disagree. A full-duplex modem such as V.32 or V.32bis is going to give you great UUCP performance; I'd even propose that a V.32bis modem might give better performance than PEP. The only benefit of PEP is smaller increments of data rate fallback on bad lines. Other than this, Telebit has not been able to demonstrate objectively in a contribution to a standards committee that multicarrier modulation has any significant benefit over single carrier on the same quality phone line. > Now if Hayes would like to get on the wagon instead of trying to > tip it over... Which wagon are you speaking of, specifically? I think the industry as a whole had a problem until recently with every company supporting a different modulation scheme until V.32 modems could be produced and sold at a price acceptable to owners of small systems. Hayes is now on the V.32 bandwagon, as are Telebit, USR, Microcom, and basically ever other modem company of any significance. What can possibly be gained by Hayes, or any company other than Telebit, trying to build a multicarrier modem, unless it becomes a standard? It just might, but until it does, it would make about as much sense as Hayes building HST modems, or Telebit building V-series ping-pong modems. -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 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
larry@nstar.rn.com (Larry Snyder) (03/06/91)
david@llustig.palo-alto.ca.us (David Schachter) writes: >If you want good UUCP performance over a regular dial-up phone line, you have >two choices: buy an non-Telebit modem and complain about lousy UUCP throughput, >or buy a Telebit and save money and headaches. If you opt for the first alter- >rnative, you can buy an expensive Hayes modem, to support Toby's Usenet news >habit and get a modem which works quite well, or you can buy a cheapo modem >from a cheapo company and get a modem which may work well enough. You'll curse >yourself later, whichever solution you pick, but at least with the cheapo modem >you haven't wasted as much money initially. >Or you can buy a Telebit, spend a few hours cursing the manual, and never worry >about UUCP performance and crummy phone lines again. The Telebit will connect >on incredibly bad phone lines and spoof UUCP's send-and-wait protocol to get >the data through, quickly and without complaint, over and over and over. We have multiple Telebits here on nstar.rn.com, and I agree - they keep on working - and provide excellent throughput - but on the other hand - we also have USR dual standard modems - and they also keep on working HST - HST uucp through is the pits (350 cps at best) - while the V.32 to V.32 uucp runs right at 900 cps. V.32 - V.32 using v.342bis runs around 1400 cps - just as fast as the Telebits - but the Telebits hold noisy lines better (we all know that) - -- Larry Snyder, NSTAR Public Access Unix 219-289-0287 (HST/PEP/V.32/v.42bis) regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}
jeh@dcs.simpact.com (03/09/91)
In article <1991Mar5.093318.2146@llustig.palo-alto.ca.us>, david@llustig.palo-alto.ca.us (David Schachter) writes: > In article <3827.27d24b3a@hayes.uucp> tnixon@hayes.uucp writes: >>Like any other error-control modem, the VSM9600 performs best with a >>protocol that doesn't stop and wait for acknowledgements after every ^^^^^ >>frame. I'm not familiar enough with UUCP to suggest what settings >>or alternatives you might have to consider to make it work better. >>The VSM9600 generally works better than PEP with stop-and-wait >>protocols because its turnaround time is so much faster, but there >>will nevertheless be some degradation from optimum. > > Toby is being a bit disingenuous here. His "The VSM9600 generally works better > than PEP with stop-and-wait protocols" is true for non-spoofed protocols. The > original interrogative was why the Hayes modem runs like a dead dog on a hot > August day with uucp; for UUCP, PEP beats the Hayes by a country mile because > PEP spoofs UUCP, converting into a non-stop-and-wait protocol. Wait a second. Uucp is NOT a stop-and-wait protocol by this definition (note the highlighted word "every" above). A stop-and-wait protocol has a transmit window size of one; standard uucps have a transmit window size of three 64-character packets. If you get the acks back quickly enough, uucp will transmit continuously (within each file, anyway). Now, uucp at 3x64 effectively *becomes* "stop and wait" on high-speed links with long end-to-end delays (even in the absence of turnaround delays), but many uucps can be set to use a window of up to seven 4K packets, which should give enough time for an ACK to come back for the first packet before the seventh is sent even on VERY high speed, long-delay links. --- Jamie Hanrahan, Simpact Associates, San Diego CA uucp protocol guru, VMSnet [DECUS uucp] Working Group, US DECUS VAX Systems SIG Internet: jeh@dcs.simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh
root@zswamp.fidonet.org (Geoffrey Welsh) (03/10/91)
Eamonn McManus (em@dce.ie ) wrote: > "I know how it works....That's why I don't like it" > -- Chip Salzenberg on SCO "UNIX" C2 Security Package >It's worth noting that there is a bug in at least some SCO >Unix systems (e.g., the one we have) that causes uucico to report a >throughput that is half the real figure, in its log files. SCO uucico throughput reports have *always* been suspect in my books. -- 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 The mile is traversed not by a single leap, but by a procession of coherent steps; those who insist on making the trip in a single element will be failing long after you and I have discovered new worlds. - me
tnixon@hayes.uucp (03/11/91)
In article <scour@dce.ie>, em@dce.ie (Eamonn McManus) writes: > UUCP is a windowed protocol, so its throughput will be impaired if you are > using a modem that only transmits in one direction at a time. I believe > the Hayes Smartmodem 9600 has this property. The "Hayes Smartmodem 9600" is a V.32 modem. I'm sure you're referring to the "V-series Smartmodem 9600", which uses a proprietary half-duplex ping-pong modulation scheme. The "V-series ULTRA Smartmodem 9600" (Ultra 96) supports both V.32 and the proprietary scheme. -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 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
garyc@dbase.A-T.COM (Gary Carter) (03/19/91)
In article <3829.27d4d360@hayes.uucp> tnixon@hayes.uucp writes: >> If you want good UUCP performance over a regular dial-up phone line, you have >> two choices: buy an non-Telebit modem and complain about lousy UUCP throughput, >> or buy a Telebit and save money and headaches. > >I strongly disagree. A full-duplex modem such as V.32 or V.32bis is >going to give you great UUCP performance; I'd even propose that a >V.32bis modem might give better performance than PEP. The only >benefit of PEP is smaller increments of data rate fallback on bad >lines. Other than this, Telebit has not been able to demonstrate The only benefit of PEP??? I have some small experience with PEP and V.32. Calling around Silicon Valley using a T2500 and a Microcom QX/V.32, occasionally I can't get a V.32 connection; other times, my V.32 connection will hang up after some length of time. Most of the time, it works great, and is much nicer than PEP for interactive use (such a running a text editor on the remote computer) - except for those unpredictable dropouts. But in my experience PEP NEVER FAILS TO CONNECT, and once connected, PEP NEVER DROPS OUT. It is totally reliable, industrial strength, a year-in year-out proven workhorse. Even for interactive edits, if the job is a small one, I will log in using PEP rather than V.32, in spite of the sluggish turnaround time, because of the absolute certainty that it will just work the first time. And for file transfers, I always use PEP. As for V.32, on the other hand, I simply cannot say the same. It is great, I use it a lot, but 99% just isn't quite the same as 100.0000. PEP may be proprietary, and Telebit may show a lack of "pep" with the standards committees, but that should not color an objective assessment of its virtues. __ garyc@dbase
jeff@markets.amix.com (Jeff Crilly N6ZFX) (04/03/91)
In article <1991Mar18.211318.22290@dbase.A-T.COM> garyc@dbase.UUCP (Gary Carter) writes: > > [Stuff deleted...] > >I have some small experience with PEP and V.32. Calling around Silicon >Valley using a T2500 and a Microcom QX/V.32, occasionally I can't get >a V.32 connection; other times, my V.32 connection will hang up after ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >some length of time. Most of the time, it works great, and is much nicer ^^^^^^^^^^^^^^^^^^^^ >than PEP for interactive use (such a running a text editor on the remote >computer) - except for those unpredictable dropouts. > >But in my experience PEP NEVER FAILS TO CONNECT, and once connected, ^^^^^^^^^^^^^^^^^^^^^^^^^^ >PEP NEVER DROPS OUT. It is totally reliable, industrial strength, a ^^^^^^^^^^^^^^^^^^^^ >year-in year-out proven workhorse. Even for interactive edits, if the >job is a small one, I will log in using PEP rather than V.32, in spite >of the sluggish turnaround time, because of the absolute certainty that >it will just work the first time. And for file transfers, I always use >PEP. We have a handful of USR Dual standards and Telebit T2500s. A few weeks ago we had a power supply go out in a T2500. While it was at the factory I gave a USR dual standard to the guy who was using the 2500 (at his house). He found that the USR would connect, but then hang up after a while. The modem at the other end was a telebit T2500. It was really annoying. During some testing (of yet another problem with the USR) I found that sometimes when the T2500 calls the USR the link will drop after some time. The USR ati7 says the reason was Link Disconnect Received. Anyhow after upgrading the USR to 9/29/89 roms, the problem went away. My point is that there are lots of V.32 mfrs whose modems might have bugs. When you connect V.32, you are not neccessarily connecting to another telebit V.32. (Calling around Silicon Valley, [BBSs I take it?] you are probably getting USRobotics modems at the other end.) Also, I would find it rare if some mfr had this kind of problem with their modems at *both* ends. When you connect PEP, there is always a telebit at the other end. Telebit has the luxury of not having to worry about compatibilty issues with other mfrs modems. The same argument can be made for HST. Jeff Crilly (N6ZFX) AMIX Corporation 2345 Yale Street Palo Alto, CA 94306 jeff@markets.amix.com, {uunet,sun}!markets!jeff, N6ZFX@N6IIU.#NOCAL.CA.USA
jeff@markets.amix.com (Jeff Crilly N6ZFX) (04/03/91)
In article <1991Apr2.193534.5056@markets.amix.com> jeff@markets.amix.com (Jeff Crilly N6ZFX) writes: >Anyhow after >upgrading the USR to 9/29/89 roms, the problem went away. ^^^^^^^ I should've said 2/26/90 roms. 9/29/89 is what was in there previously. Sorry for any inconvience. Jeff Crilly (N6ZFX) AMIX Corporation 2345 Yale Street Palo Alto, CA 94306 jeff@markets.amix.com, {uunet,sun}!markets!jeff, N6ZFX@N6IIU.#NOCAL.CA.USA