tnixon@hayes.uucp (03/08/91)
I received notice this morning via AT&T Mail from Dick Brandt, vice chairman of CCITT Study Group XVII, that V.17 and V.32bis were approved and are now formally adopted as CCITT Recommendations. He did not report the actually vote tally, but I assume that it was unanimous. V.17 is the new modulation scheme that provides 12000 and 14400 bps trellis-coded modulation for Group 3 facsimile. CCITT Recommendations T.4 and T.30, which define Group 3 fax, have also been amended to reference V.17 and provide for negotiation of its use (and those amendments have been adopted as well). V.17 also adds trellis-coded modulation at 7200 and 9600; these speeds are also provided in Group 3 fax by V.29 modulation but without trellis coding. V.17 should thus allow these speeds to be used on somewhat worse lines than was previously possible. V.32bis is an extension of CCITT V.32 which adds speeds of 7200, 12000, and 14400bps, full-duplex on two-wire dial-up or leased lines. V.32bis also adds a "rapid rate renegotiation" feature which allows the modems, by mutual agreement, to shift data rates up or down through a simple signalling process that takes about 1/10th of a second; V.32 requires a full retrain, which takes from 5 to 10 seconds, in order to change speeds. -- 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
root@zswamp.fidonet.org (Geoffrey Welsh) (03/10/91)
>From: tnixon@hayes.uucp >I received notice this morning via AT&T Mail from Dick >Brandt, vice chairman of CCITT Study Group XVII, that >V.17 and V.32bis were approved and are now formally >adopted as CCITT Recommendations. Thanks for the note! -- 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
schuster@panix.uucp (Michael Schuster) (03/11/91)
In article <3841.27d78365@hayes.uucp> tnixon@hayes.uucp writes: >I received notice this morning via AT&T Mail from Dick Brandt, vice >chairman of CCITT Study Group XVII, that V.17 and V.32bis were >approved and are now formally adopted as CCITT Recommendations. He >did not report the actually vote tally, but I assume that it was >unanimous. Thanks you for posting the information we've all been waiting for ... and "from the horse's mouth". I can't help but notice that your posting is also notable for the ABSENCE of a Hayes product announcement or shipping date. NOW what is Hayes waiting for? -- Mike Schuster | CIS: 70346,1745 NY Public Access UNIX: ...cmcl2!panix!schuster | MCI Mail, GENIE: The Portal (R) System: schuster@cup.portal.com | MSCHUSTER
evanc@isishq.fidonet.org (Evan Champion) (03/11/91)
root@zswamp.fidonet.org (Geoffrey Welsh) writes: > > >From: tnixon@hayes.uucp > > >I received notice this morning via AT&T Mail from Dick > >Brandt, vice chairman of CCITT Study Group XVII, that > >V.17 and V.32bis were approved and are now formally > >adopted as CCITT Recommendations. > > Thanks for the note! > > > -- > 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 failin > long after you and I have discovered new worlds. - me What is V17? Thanks. Evan Champion evanc@isishq.fidonet.org
tnixon@hayes.uucp (03/11/91)
In article <1991Mar10.190118.10151@panix.uucp>, schuster@panix.uucp (Michael Schuster) writes: > I can't help but notice that your posting is also notable for the > ABSENCE of a Hayes product announcement or shipping date. NOW what is > Hayes waiting for? While I can unilaterally and spontaneously generate standards-related messages without running afoul of Hayes' PR department, I certainly can't do that with product announcements. Besides, if I _had_ included a product announcement, half a dozen other folks would have flamed me, right? :-) -- 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
mo@well.sf.ca.us (Maurice Weitman) (03/11/91)
tnixon@hayes.uucp writes that V.17 and V.32bis were approved
and are now formally adopted as CCITT Recommendations.
So, when will v.32bis hardware hit the streets and who'll have
it? Huh?
--
Maurice Weitman mo@well.sf.ca.us ..!{hplabs,pacbell,apple,ucbvax}!well!mo
| <- this is not a pipe 1634 Walnut Berkeley, CA 94709 (415)549-0280
Quote: "Facts are stupid things." Ronald Wilson Reagan, New Orleans, 1988
Disclaimer: Any errors in spelling, tact or fact are transmission errors.rdippold@maui.qualcomm.com (Ron Dippold) (03/12/91)
In article <23546@well.sf.ca.us> mo@well.sf.ca.us (Maurice Weitman) writes: >tnixon@hayes.uucp writes that V.17 and V.32bis were approved >and are now formally adopted as CCITT Recommendations. > >So, when will v.32bis hardware hit the streets and who'll have >it? Huh? The latest USR Dual Standards already have it, according to all the postings on the USR FidoNet. Apparently USR figured it had a good chance of passing and decided to "be thar fustest with the mostest."
schuster@panix.uucp (Michael Schuster) (03/12/91)
In article <3847.27da9192@hayes.uucp> tnixon@hayes.uucp writes: > >While I can unilaterally and spontaneously generate >standards-related messages without running afoul of Hayes' PR >department, I certainly can't do that with product announcements. >Besides, if I _had_ included a product announcement, half a dozen >other folks would have flamed me, right? :-) We DO appreciate your position. =I= wouldn't have flamed you ... but I can't speak for anyone else :-) It just seems as though Hayes is poised to be the last in the pool again, and the popular belief was that this time they were just waiting for V.32bis to be "official". Randy Cooper says he doesn't know =when= Hayes will be marketing a V.32bis modem. People are beginning to wonder if they have any desire to. -- Mike Schuster | CIS: 70346,1745 NY Public Access UNIX: ...cmcl2!panix!schuster | MCI Mail, GENIE: The Portal (R) System: schuster@cup.portal.com | MSCHUSTER
grr@cbmvax.commodore.com (George Robbins) (03/13/91)
In article <1991Mar11.231226.17795@panix.uucp> schuster@panix.uucp (Michael Schuster) writes: > In article <3847.27da9192@hayes.uucp> tnixon@hayes.uucp writes: > > > >While I can unilaterally and spontaneously generate > >standards-related messages without running afoul of Hayes' PR > >department, I certainly can't do that with product announcements. > >Besides, if I _had_ included a product announcement, half a dozen > >other folks would have flamed me, right? :-) > > > We DO appreciate your position. =I= wouldn't have flamed you ... but > I can't speak for anyone else :-) > > It just seems as though Hayes is poised to be the last in the pool again, > and the popular belief was that this time they were just waiting for V.32bis > to be "official". Randy Cooper says he doesn't know =when= Hayes will be > marketing a V.32bis modem. People are beginning to wonder if they have any > desire to. I think this is pretty silly (even if I did say something similar about Teblebit the other day). All you can really infer is that Hayes doesn't feel that time-to-market is an overriding issue for the success in the V.32bis market. They're probably right, eh? 8-) -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
tnixon@hayes.uucp (03/13/91)
In article <1991Mar11.231226.17795@panix.uucp>, schuster@panix.uucp (Michael Schuster) writes: > It just seems as though Hayes is poised to be the last in the pool again, > and the popular belief was that this time they were just waiting for V.32bis > to be "official". Randy Cooper says he doesn't know =when= Hayes will be > marketing a V.32bis modem. People are beginning to wonder if they have any > desire to. Except for the introduction of the AT command set itself, Hayes has rarely been "first" with anything. Also rarely last, except to the extent that EVERYBODY is last at least temporarily, until somebody else takes over being last. We prefer to try to be "best" rather than "first". Believe me, there is not a higher priority project at Hayes right now than V.32bis. We're just waiting to announce the details. -- 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
jparnas@larouch.uucp (Jacob Parnas) (03/18/91)
In article <3852.27de1c60@hayes.uucp>, tnixon@hayes.uucp writes: |> |> Except for the introduction of the AT command set itself, Hayes has |> rarely been "first" with anything. Also rarely last, except to the |> extent that EVERYBODY is last at least temporarily, until somebody |> else takes over being last. We prefer to try to be "best" rather |> than "first". |> |> ... |> -- |> 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 It seems to me that when a company like US Robotics has a modem that is 50 % faster than Hayes does and has for several months, and the US Robotics can do pretty much everything that the Hayes can, and the US Robotics doesn't really have any major flaws, it is hard to see how Hayes can have the "best" modem. Getting out fast modem standards early is really important to many modem users. Waiting months for Hayes or most other vendors to come out with V.32bis modems, results in months of significantly higher phone bills and significantly lower productivity. I'm not trying to knock Hayes as a whole. They make good modems that are reliable and work as advertised. I was particularly impressed in how well the Hayes V.42bis modem did in the Jan '91 Data Communications Article on high speed modems. Hayes is fortunate to have talented engineers like you designing their modems. The Hayes modem better than anyone in handling line noise in that excellent review. It even did very slightly better than the US Robotics (although the US Robotics V.42bis modem did slightly better in throughput over fairly clean lines). My point is that I think that if Hayes would be doing itself and the modem buying public a big service if it would be more aggressive in trying to get fast modems out the door faster like US Robotics has. Please understand that going with your modem vendor when it lags behind agressive vendors would mean money out of our pockets, higher frustration levels (due to the slower modem) and lower productivity for many months. If you needed to buy a modem now, and tested the US Robotics which seems to work fine in both V.32bis mode and V.32/V.42/V.42bis mode, and Hayes only offers a modem that will run at 2/3 the speed of the US Robotics, and the US Robotics retrains in under 100 ms vs several seconds for the Hayes, which would you buy? ------------------------------------------------------------------------------ | Jacob M. Parnas | DISCLAIMER: The above message is from | | IBM Thomas J. Watson Research Ctr. | me and is not from my employer. IBM | | Arpanet: jparnas@ibm.com | might completely disagree with me. | | Bitnet: jparnas@yktvmx.bitnet \---------------------------------------| | Home: ..!uunet!bywater!acheron!larouch!jparnas | Phone: (914) 945-1635 | ------------------------------------------------------------------------------
logic@wet.UUCP (Henry Kwan) (03/20/91)
In article <1991Mar17.220044.10341@larouch.uucp> jparnas@larouch.uucp (Jacob Parnas) writes:
]
]My point is that I think that if Hayes would be doing itself and the
]modem buying public a big service if it would be more aggressive in
]trying to get fast modems out the door faster like US Robotics has.
]Please understand that going with your modem vendor when it lags behind
]agressive vendors would mean money out of our pockets, higher frustration
]levels (due to the slower modem) and lower productivity for many
]months.
]
] [lots of stuff deleted]
]
All this talk about Hayes being neither the first nor the best is fine and
dandy but I think it ignores a basic premise. Hayes is still dominant in
the modem world. I'm sure Toby can give more concrete figures but from the
surveys I've seen, Hayes has the lion's share of the high-speed dialup modem
market. Both US Robotics and Telebit are small players compared to Hayes.
Hayes must be doing something right if they have a slice of pie that
big compared to everyone else.
--
Henry Kwan | AppleLink: FWB [] CompuServe: 71320,1034
FWB, Inc. | Voice: (415)474-8055 [] FAX: (415)775-2225
2040 Polk St. Ste 215 | Internet: claris!wet!logic@ames.arc.nasa.gov
San Francisco, CA 94109 | UUCP: {claris,hoptoad,lamc,ucsfcca}!wet!logicrob@newsserver.sfu.ca (Rob Carpenter) (03/21/91)
In <1991Mar17.220044.10341@larouch.uucp> jparnas@larouch.uucp (Jacob Parnas) writes: >In article <3852.27de1c60@hayes.uucp>, tnixon@hayes.uucp writes: >|> >|> Except for the introduction of the AT command set itself, Hayes has >|> rarely been "first" with anything. Also rarely last, except to the >|> extent that EVERYBODY is last at least temporarily, until somebody >|> else takes over being last. We prefer to try to be "best" rather >|> than "first". It's nice to see that in this day and age, a company takes pride in its work rather than building products with problems. >It seems to me that when a company like US Robotics has a modem that is >50 % faster than Hayes does and has for several months, and the US >Robotics can do pretty much everything that the Hayes can, and the US >Robotics doesn't really have any major flaws, it is hard to see how >Hayes can have the "best" modem. Well, if you want to run out and buy a modem that will only talk to other modems of the same kind. By all means, buy a USR modem. Yes, I know, Hayes does not, at the moment, have a V.32bis modem. But with time it will be announced. How can Hayes have the best modem? Look at the size of the USR, it's a blinking eyesore. I sure as heck don't want to have a modem the size of an encylopaedia volume on my desk. >Getting out fast modem standards early is really important to many modem >users. Waiting months for Hayes or most other vendors to come out with >V.32bis modems, results in months of significantly higher phone bills >and significantly lower productivity. Getting out fast modem standards? They put this into production BEFORE it was a standard. V.32bis was did not become a "standard" until the beginning of this month. >My point is that I think that if Hayes would be doing itself and the >modem buying public a big service if it would be more aggressive in >trying to get fast modems out the door faster like US Robotics has. Hayes has already learned their lesson about releasing strange and Unusual protocols. Remeber the V-series modems? I think Hayes would like to forget them. >Please understand that going with your modem vendor when it lags behind >agressive vendors would mean money out of our pockets, higher frustration >levels (due to the slower modem) and lower productivity for many >months. I think Higher frustration levels are caused by defective modems. Not by "slow" modem speeds. >If you needed to buy a modem now, and tested the US Robotics which seems >to work fine in both V.32bis mode and V.32/V.42/V.42bis mode, and Hayes >only offers a modem that will run at 2/3 the speed of the US Robotics, >and the US Robotics retrains in under 100 ms vs several seconds for the >Hayes, which would you buy? The retraining speed is due to the protocol, not the modem. Disclaimer: I have no associaton with Hayes, US Robotics, or any other Modem manufacturer. I am, however, a happy owner of a Hayes 9600 Ultra. On a small disclaimer note: I hate "proprietary protocols", which is why I am so anti "USR HST". I'm glad that a high-speed protocol is emerging from the smoke. ================================================================= "Time flies like an arrow. Fruit flies like a banana." "Check your reality dipstick, I think you're a quart low." "If there's nothing wrong with me, there must be something wrong with the universe." ----------------------------------------------------------------- Rob Carpenter Computing Services [Rob,Bob,Boob,Robert,Bobert] Simon Fraser University userdbob@ucs.sfu.ca [Internet] Burnaby, B.C. Canada userdbob@sfu.bitnet [Bitnet] V5A 1S6 =================================================================
luce@aurs01.UUCP (J. Luce) (03/22/91)
In article <2239@wet.UUCP> logic@wet.UUCP (Henry Kwan) writes:
-All this talk about Hayes being neither the first nor the best is fine and
-dandy but I think it ignores a basic premise. Hayes is still dominant in
-the modem world. I'm sure Toby can give more concrete figures but from the
-surveys I've seen, Hayes has the lion's share of the high-speed dialup modem
-market. Both US Robotics and Telebit are small players compared to Hayes.
-Hayes must be doing something right if they have a slice of pie that
-big compared to everyone else.
-
---
-Henry Kwan | AppleLink: FWB [] CompuServe: 71320,1034
-FWB, Inc. | Voice: (415)474-8055 [] FAX: (415)775-2225
-2040 Polk St. Ste 215 | Internet: claris!wet!logic@ames.arc.nasa.gov
-San Francisco, CA 94109 | UUCP: {claris,hoptoad,lamc,ucsfcca}!wet!logic
I think what is *REALLY* the case is the inertia that Hayes has built up
and name recognition as "the" modem mfr. has created the same sort of
"IBM Syndrome" that inhabits the PC world. I mean, it has been proven
time and time again that IBM PCs are *not* the fastest, most reliable,
technologically ahead, etc. PC out there. Yet, they sell a boat load due
to the three letters on the case. With modems it's 5 letters :).
Past laurels can sustain one for a long time unless you do something
disastrous to kill the halo effect. Hayes has not done anything real bad...
nothing real good lately (IMHO) either <grin>, but the image remains.casey@gauss.llnl.gov (Casey Leedom) (03/23/91)
| From: rob@newsserver.sfu.ca (Rob Carpenter) | | [[Lots of US Robotics knocking and Hayes touting. Followed of course | by a disclaimer saying he had no connection to Hayes other than as a | satisfied customer. :-)]] Rob, Do you have particular reasons why you obviously don't like US Robotics? Are they based on some bad experiences with either their products or the company? I'm curious because we're likely to go out and buy a bunch of their Courier V.32bis modems. Specifically: | Well, if you want to run out and buy a modem that will only talk to | other modems of the same kind. By all means, buy a USR modem. But the Hayes that supports Hayes proprietary protocol (sorry, can't remember the name) can only talk to other similar Hayes modems with those high speed protocol. This is a problem with all proprietary protocols that don't see wide licensing. A lot of companies implemented such protocols though because doing V.32 wasn't doable cheaply when it first came out. It took the Rockwell V.32 board and other similar plug in products to make V.32 doable. Or are you referring to V.32bis? | How can Hayes have the best modem? Look at the size of the USR, it's a | blinking eyesore. I sure as heck don't want to have a modem the size of | an encylopaedia volume on my desk. It's about the same size as my Telebit T2500. Uhmmm, in any case, what's the problem? | Getting out fast modem standards? They put this into production BEFORE | it was a standard. V.32bis was did not become a "standard" until the | beginning of this month. Yes, but as we all know, once the standard reached the point it had, there was very little chance that it would be changed. USR promised a ROM upgrade if any were needed to track the final approved V.32bis standard. As it stands, there were no changes (as expected), so they won't have to send out any ROM upgrades for that reason. | Hayes has already learned their lesson about releasing strange and | Unusual protocols. Remeber the V-series modems? I think Hayes would | like to forget them. As have a bunch of the manufacturers, but customers wanted hign speed NOW, so the modem manufacturers gave it to them. It's a suply and demand market. | >Please understand that going with your modem vendor when it lags behind | >agressive vendors would mean money out of our pockets, higher frustration | >levels (due to the slower modem) and lower productivity for many | >months. | | I think Higher frustration levels are caused by defective modems. Not | by "slow" modem speeds. This is definitely an issue. If US Robotics product had been a real dud because they released it as soon as they could get anything floating, it would have done them a great deal of harm. As it is, it seems to be working really well. So far, I'm happy with it. I still want to test it under some even more adverse line conditions though. I'm not knocking Hayes at all. I'm just curious why you dislike US Robotics so much. Casey
rdippold@gdansk.qualcomm.com (Ron Dippold) (03/23/91)
In article <1991Mar21.051827.28579@newsserver.sfu.ca> rob@newsserver.sfu.ca (Rob Carpenter) writes: >In <1991Mar17.220044.10341@larouch.uucp> jparnas@larouch.uucp (Jacob Parnas) writes: > >>In article <3852.27de1c60@hayes.uucp>, tnixon@hayes.uucp writes: >>|> Except for the introduction of the AT command set itself, Hayes has >>|> rarely been "first" with anything. Also rarely last, except to the >>|> extent that EVERYBODY is last at least temporarily, until somebody >>|> else takes over being last. We prefer to try to be "best" rather >>|> than "first". > >It's nice to see that in this day and age, a company takes pride in its >work rather than building products with problems. Except that there are companies who build products that work _and_ get them out fast... >>It seems to me that when a company like US Robotics has a modem that is >>50 % faster than Hayes does and has for several months, and the US >>Robotics can do pretty much everything that the Hayes can, and the US >>Robotics doesn't really have any major flaws, it is hard to see how >>Hayes can have the "best" modem. >Well, if you want to run out and buy a modem that will only talk to >other modems of the same kind. By all means, buy a USR modem. Yeah, if you buy a USR V.32bis modem, you'll only be able to talk to USR modems, modems that support V.32, and modems that support V.32bis once everyone else gets their act together. Thats only a minor, what, 80-90% of the high speed modems out there? >>Getting out fast modem standards early is really important to many modem >>users. Waiting months for Hayes or most other vendors to come out with >>V.32bis modems, results in months of significantly higher phone bills >>and significantly lower productivity. > >Getting out fast modem standards? They put this into production BEFORE >it was a standard. V.32bis was did not become a "standard" until the >beginning of this month. Right, and USR had the foresight to assume that it would become a true standard and start including it in its modems. They took a gamble, and it paid off, and now everyone else is scrambling to catch up. >>My point is that I think that if Hayes would be doing itself and the >>modem buying public a big service if it would be more aggressive in >>trying to get fast modems out the door faster like US Robotics has. > >Hayes has already learned their lesson about releasing strange and >Unusual protocols. Remeber the V-series modems? I think Hayes would >like to forget them. V.32bis hardly qualifies as a strange and unusual protocol. >>Please understand that going with your modem vendor when it lags behind >>agressive vendors would mean money out of our pockets, higher frustration >>levels (due to the slower modem) and lower productivity for many >>months. > >I think Higher frustration levels are caused by defective modems. Not >by "slow" modem speeds. Great. So buy one that isn't defective, like a Hayes, Telebit, or USR. >I have no associaton with Hayes, US Robotics, or any other Modem >manufacturer. I am, however, a happy owner of a Hayes 9600 Ultra. > >I hate "proprietary protocols", which is why I am so anti "USR HST". >I'm glad that a high-speed protocol is emerging from the smoke. Yes, being a hayes owner would explain your hatred for USR... And just a reminder that the standard high-speed protocol is still USR. Looking at a national or local BBS listing shows me that about 9/10 or more of the high speed modems out there are HSTs. V.32 is a way for the rest of the modem makers to attempt to reclaim the 9600+ bps market dominated by US.
jparnas@larouch.uucp (Jacob Parnas) (03/24/91)
In article <1991Mar21.051827.28579@newsserver.sfu.ca>, rob@newsserver.sfu.ca (Rob Carpenter) writes: |> In <1991Mar17.220044.10341@larouch.uucp> jparnas@larouch.uucp (Jacob Parnas) writes: |> >It seems to me that when a company like US Robotics has a modem that is |> >50 % faster than Hayes does and has for several months, and the US |> >Robotics can do pretty much everything that the Hayes can, and the US |> >Robotics doesn't really have any major flaws, it is hard to see how |> >Hayes can have the "best" modem. |> |> Well, if you want to run out and buy a modem that will only talk to |> other modems of the same kind. By all means, buy a USR modem. What modem will the Hayes Ultra talk to that the US Robotics Courier HST won't? To say that a modem that the USR will only talk to other modems of the same kind is absurd. |> How can Hayes have the best modem? Look at the size of the USR, it's a |> blinking eyesore. I sure as heck don't want to have a modem the size of |> an encylopaedia volume on my desk. I don't find the USR to be an eyssore at all. Even if I did, I certainly care a lot more about modem throughput and retrain speed than I do about how it looks. |> |> >Getting out fast modem standards early is really important to many modem |> >users. Waiting months for Hayes or most other vendors to come out with |> >V.32bis modems, results in months of significantly higher phone bills |> >and significantly lower productivity. |> |> Getting out fast modem standards? They put this into production BEFORE |> it was a standard. V.32bis was did not become a "standard" until the |> beginning of this month. And because they got it out real early, I enjoyed much faster speed and lower phone bills for months. Thats important to me and I suspect many other people as well. |> >My point is that I think that if Hayes would be doing itself and the |> >modem buying public a big service if it would be more aggressive in |> >trying to get fast modems out the door faster like US Robotics has. |> |> Hayes has already learned their lesson about releasing strange and |> Unusual protocols. Remeber the V-series modems? I think Hayes would |> like to forget them. But the V-series protocol didn't offer any huge advantage over other modulation schemes. And the V-series protocol wasn't going to be adopted by everyone within a year's time. |> >Please understand that going with your modem vendor when it lags behind |> >agressive vendors would mean money out of our pockets, higher frustration |> >levels (due to the slower modem) and lower productivity for many |> >months. |> |> I think Higher frustration levels are caused by defective modems. Not |> by "slow" modem speeds. What higher frustration level? I hooked up the USR and was running within 15 minutes. Everything worked fine. There were no defective modems. ------------------------------------------------------------------------------ | Jacob M. Parnas | DISCLAIMER: The above message is from | | IBM Thomas J. Watson Research Ctr. | me and is not from my employer. IBM | | Arpanet: jparnas@ibm.com | might completely disagree with me. | | Bitnet: jparnas@yktvmx.bitnet \---------------------------------------| | Home: ..!uunet!bywater!acheron!larouch!jparnas | Phone: (914) 945-1635 | ------------------------------------------------------------------------------
jparnas@larouch.uucp (Jacob Parnas) (03/24/91)
In article <2239@wet.UUCP>, logic@wet.UUCP (Henry Kwan) writes: |> All this talk about Hayes being neither the first nor the best is fine and |> dandy but I think it ignores a basic premise. Hayes is still dominant in |> the modem world. I'm sure Toby can give more concrete figures but from the |> surveys I've seen, Hayes has the lion's share of the high-speed dialup modem |> market. Both US Robotics and Telebit are small players compared to Hayes. |> Hayes must be doing something right if they have a slice of pie that |> big compared to everyone else. |> |> -- |> Henry Kwan | AppleLink: FWB [] CompuServe: 71320,1034 I don't know the breakdown of sales of modem by manufacturer. But I don't think it matters. Just because a vendor is sucessful doesn't mean it has the best modem. I, and my guess is many other modem buyers, select a modem on its speed, features, quality and price, not its success in the marketplace. Sometimes success in the marketplace is because of value, like Telebits used to enjoy in the unix UUCP marketplace. Other times it is because of name recognition or lack of research into all options. ------------------------------------------------------------------------------ | Jacob M. Parnas | DISCLAIMER: The above message is from | | IBM Thomas J. Watson Research Ctr. | me and is not from my employer. IBM | | Arpanet: jparnas@ibm.com | might completely disagree with me. | | Bitnet: jparnas@yktvmx.bitnet \---------------------------------------| | Home: ..!uunet!bywater!acheron!larouch!jparnas | Phone: (914) 945-1635 | ------------------------------------------------------------------------------
larry@nstar.rn.com (Larry Snyder) (03/24/91)
In comp.dcom.modems you write: >What higher frustration level? I hooked up the USR and was running within >15 minutes. Everything worked fine. There were no defective modems. I also am quite happy with my USR modems. The v.32bis modem is used on the SLIP connection over a leased line of 180 miles and we get transfer rates has high as 3.1 kb/sec (ASCII - binaries runs around 1.7kb/sec) and throughput doesn't change much for two transfers at the same time - one going each way :) On dialup we have USR DS modems - and they yield transfers on the average of 1760 cps (downloading binaries from the BBS). Now - UUCP on these modems is another story - in the HST modem at best throughput is 350 cps, while V.32 on non v.42bis and non v.32bis connections runs around 880 cps. -- 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}
root@zswamp.fidonet.org (Geoffrey Welsh) (03/24/91)
Larry Snyder (larry@nstar.rn.com ) wrote: >Now - UUCP on these modems is another story - in the HST >modem at best throughput is 350 cps, while V.32 on non >v.42bis and non v.32bis connections runs around 880 cps. ... which I consider decent throughput for what is essentially a 9600 bps modem, don't you? -- 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
davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) (03/25/91)
root@zswamp.fidonet.org (Geoffrey Welsh) writes: > Larry Snyder (larry@nstar.rn.com ) wrote: > > >Now - UUCP on these modems is another story - in the HST > >modem at best throughput is 350 cps, while V.32 on non > >v.42bis and non v.32bis connections runs around 880 cps. > > ... which I consider decent throughput for what is essentially a 9600 bps > modem, don't you? OK, so you're kidding ... aren't you? --Dave
larry@nstar.rn.com (Larry Snyder) (03/25/91)
root@zswamp.fidonet.org (Geoffrey Welsh) writes: >Larry Snyder (larry@nstar.rn.com ) wrote: > >Now - UUCP on these modems is another story - in the HST > >modem at best throughput is 350 cps, while V.32 on non > >v.42bis and non v.32bis connections runs around 880 cps. > ... which I consider decent throughput for what is essentially a 9600 bps >modem, don't you? Not bad - hopefully v.32bis and v.42bis will bump the throughput up there around 1600 cps -- 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}
larry@nstar.rn.com (Larry Snyder) (03/26/91)
davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) writes: >root@zswamp.fidonet.org (Geoffrey Welsh) writes: >> Larry Snyder (larry@nstar.rn.com ) wrote: >> >> >Now - UUCP on these modems is another story - in the HST >> >modem at best throughput is 350 cps, while V.32 on non >> >v.42bis and non v.32bis connections runs around 880 cps. >> >> ... which I consider decent throughput for what is essentially a 9600 bps >> modem, don't you? >OK, so you're kidding ... aren't you? nope - we're serious -- 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}
davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) (03/26/91)
larry@nstar.rn.com (Larry Snyder) writes: > >> Larry Snyder (larry@nstar.rn.com ) wrote: > >> > >> >Now - UUCP on these modems is another story - in the HST > >> >modem at best throughput is 350 cps, while V.32 on non > >> >v.42bis and non v.32bis connections runs around 880 cps. > >> > >> ... which I consider decent throughput for what is essentially a 9600 bps > >> modem, don't you? > > >OK, so you're kidding ... aren't you? > > nope - we're serious Well, I guess everything has it's place.... I bought a USR DS but couldn't get it to do more than 2400 BPS MNP over a long dirty link (to Tallin, Estonia from Kyoto). --Dave
bisc@zellweger.ch (Thomas K Bischoff) (03/27/91)
Sorry, for asking this, but I get this newsgroup only since yesterday. What is V.32bis and V.17 ? I know V.42, V.32 and MNP and so on. -- Thomas K. Bischoff TEN Informatik AG Net: bisc@zellweger.ch Schaffhauserstr. 1 Phone: xx41-52-235323 CH 8400 Winterthur, Switzerland
root@zswamp.fidonet.org (Geoffrey Welsh) (03/27/91)
Larry Snyder (larry@nstar.rn.com ) wrote: LS>Now - UUCP on these modems is another story - in the HST LS>modem at best throughput is 350 cps, while V.32 on non LS>v.42bis and non v.32bis connections runs around 880 cps. GW> ... which I consider decent throughput for what is essentially a 9600 bps GW>modem, don't you? LS>Not bad - hopefully v.32bis and v.42bis will bump the LS>throughput up there around 1600 cps Not likely, for the same reason that XMODEM won't get much faster over V.32bis than over V.32: dead air doesn't get any faster with increased carrier speed. At 2400 bps, the UUCP-g window (7 packets, each a couple more than 64 bytes) takes nearly two seconds to transmit. It is not only possible but quite likely that the data will have arrived at the other end and an ACK for the first block will have been received in that two seconds, allowing the sender to transmit the next block and carry on continuously in that manner. Now let's look at a V.32bis modem. *I know that this model is flawed in detail, but I believe that the principles hold and that the model is useful in describing why non-streaming protocols don't benefit as much from high speed modems* 14,400 bps synchronous means the potential equivalent of 1800 CPS asynchronous, so the data in the window will be sent in about a quarter of a second. I'd like to speculate on the reasons why, but let's just accept for the time being that the ACK simply isn't going to make it back within a quarter of a second. So... the sender shuts up until the ACK arrives. When that ACK arrives, it will be followed closely by the other six, and the second window of data will be sent almost contiguously. In effect, UUCP-g's seven-packet window degenerates at high baud rate to the point where it is comparable to a non-windowing protocol with 512-byte packets. You can make the carrier as fast as you want, you will increase the throughput marginally and the wasted bandwith significantly. I like to describe the bandwidth vs. throughput rate for non-streaming protocols as a a plot of a logarithm... there is a horizontal asymptote and increasing the baud rate brings throughput closer to it, but you can never quite reach it. Of course, the actual value of the asymptote depands on the protocol and the system using it, so you can't give absolute figures (though that doesn't stop USR from quoting some in its Courier high-speed modem manual!) Comments from my learned correspondents? -- 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
root@zswamp.fidonet.org (Geoffrey Welsh) (03/27/91)
Dave McLane (davidg%aegis.or.jp@kyoto-u.ac.jp ) wrote: >root@zswamp.fidonet.org (Geoffrey Welsh) writes: > Larry Snyder (larry@nstar.rn.com ) wrote: > > >Now - UUCP on these modems is another story - in the HST > >modem at best throughput is 350 cps, while V.32 on non > >v.42bis and non v.32bis connections runs around 880 cps. > > ... which I consider decent throughput for what is essentially a 9600 bps > modem, don't you? >OK, so you're kidding ... aren't you? Should I be? 880 CPS is decent throughput for a non-streaming protocol over a long-haul 9600 bps path with buffering and packetizing delays. Try Kermit, XMODEM-1K (or YMODEM), SEAlink, and others and let me know how they perform. Try them over the HST, over V.32, over a null modem. If and when you're finished, I'd like to compare your result table with my experiences. -- 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
davidg%aegis.or.jp@kyoto-u.ac.jp (Dave McLane) (03/28/91)
root@zswamp.fidonet.org (Geoffrey Welsh) writes: > > >Now - UUCP on these modems is another story - in the HST > > >modem at best throughput is 350 cps, while V.32 on non > > >v.42bis and non v.32bis connections runs around 880 cps. > 880 CPS is decent throughput for a non-streaming protocol over a long-haul > 9600 bps path with buffering and packetizing delays. Try Kermit, XMODEM-1K > (or YMODEM), SEAlink, and others and let me know how they perform. Try them > over the HST, over V.32, over a null modem. If and when you're finished, I'd > like to compare your result table with my experiences. You're right. It is. I have already run enough test to know that.... I guess my (sub-clinical, terminal?) dyslexia was acting in full force that day as I thougt it was saying 350 CPS was reasonable throughput for V.32. On re-reading, I see it was talking about through put in HST mode (an HST-capable modem like the USR DS supports both HST mode and V.32). Sorry for my stupidity.... --Dave
hoepfner@lheavx.gsfc.nasa.gov (PATRICK HOEPFNER) (03/28/91)
>In article <2239@wet.UUCP>, logic@wet.UUCP (Henry Kwan) writes: >|> Hayes is still dominant in the modem world. In the >|> surveys I've seen, Hayes has the lion's share of the high-speed dialup modem >|> market. Both US Robotics and Telebit are small players compared to Hayes. >|> Hayes must be doing something right if they have a slice of pie that >|> big compared to everyone else. What about Microcom. They defined the high speed market long before Hayes got into the high speed area. Where do you think that the letters MNP came from? Microcom Networking Protocol! Who cares who sells more modems. If you were to buy products only because there were a lot sold then there would be NO innovation! Just remember that the National Enquirer sells more papers than the Washington Post and the New York Times combined! Does this make the National Enquirer better!!! (Lotus and Ashton Tate are another example... :)
hoepfner@lheavx.gsfc.nasa.gov (PATRICK HOEPFNER) (03/29/91)
In article <93706@lll-winken.LLNL.GOV>, casey@gauss.llnl.gov (Casey Leedom) writes... > > Do you have particular reasons why you obviously don't like US >Robotics? Are they based on some bad experiences with either their >products or the company? I'm curious because we're likely to go out and >buy a bunch of their Courier V.32bis modems. US Robotics Courier V.32 (and V.32bis) modems add an additional feature while continuing to be fully V.32 (and V.32bis) compliant. This is the ability to negotiate the speed in the transmit and receive directions separately. This is of course only available when two Courier modems are used. This is nice because the noise in one direction and the resulting slowdown doesn't effect the other direction. I have had long distance phone conversations where one person could hear noice that the other couldn't. I assume this was developed because of USR's knowledge of asymmetric communications that their HST modems use. This makes purchasing USR's modems a good choice IMHO.
root@zswamp.fidonet.org (Geoffrey Welsh) (03/30/91)
Dave McLane (davidg%aegis.or.jp@kyoto-u.ac.jp ) wrote:
>Sorry for my stupidity....
Hardly yours, more likely USRobotics'. The asymmetrical design of the HST
was intended to allow one to type at a host over the low-speed channel (I
scan at 2400 bps or higher - especially when VT100 codes are injected - but
can't type as fast as 300 bps) and/or to send ACK packets back to the host
without interrupting the stream of data.
Given that design criteria, it's damned silly that the HST can't carry
UUCP-g at all well. You're right that 350 CPS is ridiculous for a 9600 bps
modem.
--
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. - mesrc@scuzzy.in-berlin.de (Heiko Blume) (04/01/91)
root@zswamp.fidonet.org (Geoffrey Welsh) writes: > Given that design criteria, it's damned silly that the HST can't carry >UUCP-g at all well. You're right that 350 CPS is ridiculous for a 9600 bps >modem. well, it wasn't designed for uucp, so you can't really blame it. however, if you use the f-protocol for uucp you'll get nice throughput. with a HST 14400/V.42bis i get ~1800 cps on average. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 [voice!] public UNIX source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
horke@rhoen (Bernhard Kroenung) (04/02/91)
src@scuzzy.in-berlin.de (Heiko Blume) writes: >however, if you use the f-protocol for uucp you'll get nice throughput. >with a HST 14400/V.42bis i get ~1800 cps on average. Shure ? Did you maybe mean e-protocol ? Did you maybe mean 1600-1700 cps ? Or do you use non-compressed News ? Ciao Bernhard -- Bernhard Kroenung, Bahnhofstr. 8, D-W6408 Ebersburg/Rhoen, Germany +49 6656 386 horke@rhoen.in-berlin.de X.400 : kronung@jlug-gw.uni-giessen.dbp.de Fachhochschule Fulda : e-mail demnaext
root@zswamp.fidonet.org (Geoffrey Welsh) (04/02/91)
In a letter to All, Heiko Blume (src@scuzzy.in-berlin.de ) wrote: >root@zswamp.fidonet.org (Geoffrey Welsh) writes: > Given that design criteria, it's damned silly that the HST can't carry >UUCP-g at all well. You're right that 350 CPS is ridiculous for a 9600 bps >modem. >well, it wasn't designed for uucp, so you can't really blame it. It wasn't designed specifically for UUCP-g, but it definitely was designed for protocols (both windowed and not) which sent ACK packets which were small in comparison to the data packets, and UUCP-g does fall into that broad category, doesn't it? (Or am I displaying ignorance about the size of UUCP-g ACK/NAK packets?) >however, if you use the f-protocol for uucp you'll get nice >throughput. with a HST 14400/V.42bis i get ~1800 cps on average. I think you'll get that from any streaming protocol (YMODEM-G, ZMODEM, UUCP-e, UUCP-f in order of throughput by my wild guess). These protocols will also do well over PEP, V.29, and Hayes' (*non* Ultra) V-Series connections. -- 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
larry@nstar.rn.com (Larry Snyder) (04/02/91)
src@scuzzy.in-berlin.de (Heiko Blume) writes: >well, it wasn't designed for uucp, so you can't really blame it. >however, if you use the f-protocol for uucp you'll get nice throughput. >with a HST 14400/V.42bis i get 1800 cps on average. but what versions of uucico support the "f" protocol? -- 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}
root@gold.sub.org (Christian Seyb) (04/03/91)
In <1991Apr02.132611.23171@nstar.rn.com> larry@nstar.rn.com (Larry Snyder) writes: >but what versions of uucico support the "f" protocol? >-- The one you are using (ISC 2.2.1 I think) does support the f-protocol. The following line is an example out of my /usr/lib/uucp/Systems file: scuzzy Any ACU,f 19200 0306919520 "" \r\r ogin:--ogin: nuucp word: nuucp With an HST modem, you should get app. 1.1k cps with the f-protocol. regards Christian -- Christian Seyb | Internet: cs@gold.de.intel.com uucp login: nuucp Fuchsweg 86 | Mailbox: +49-8106-34593 24h 300-19200 PEP/V.32 8011 Baldham | +49-8106-34692 24h 300-19200 HST -- Wer nach allen Seiten offen ist, kann nicht ganz dicht sein.
rjn@hpfcso.FC.HP.COM (Bob Niland) (04/04/91)
re: >>well, it wasn't designed for uucp, so you can't really blame it. >>however, if you use the f-protocol for uucp you'll get nice throughput. >>with a HST 14400/V.42bis i get 1800 cps on average. > but what versions of uucico support the "f" protocol? HP-UX for example; Series 300, 400, 700, 800 - since about version 6.5 (now at 7.0 with 8.0 imminent). The discontinued Series 200 HP-UX (2.2) and Series 500 (5.2) only have 'g'. Regards, Hewlett-Packard Bob Niland Internet: rjn@FC.HP.COM 3404 East Harmony Road UUCP: [hplabs|hpfcse]!hpfcrjn!rjn Ft Collins CO 80525-9599
grr@cbmvax.commodore.com (George Robbins) (04/07/91)
In article <7151.27F9618A@zswamp.fidonet.org> root@zswamp.fidonet.org (Geoffrey Welsh) writes: > In a letter to All, Heiko Blume (src@scuzzy.in-berlin.de ) wrote: > > >root@zswamp.fidonet.org (Geoffrey Welsh) writes: > > Given that design criteria, it's damned silly that the HST can't carry > >UUCP-g at all well. You're right that 350 CPS is ridiculous for a 9600 bps > >modem. > > >well, it wasn't designed for uucp, so you can't really blame it. > > It wasn't designed specifically for UUCP-g, but it definitely was designed > for protocols (both windowed and not) which sent ACK packets which were small > in comparison to the data packets, and UUCP-g does fall into that broad > category, doesn't it? > > (Or am I displaying ignorance about the size of UUCP-g ACK/NAK packets?) Broad category, yes, numbers no. UUCP requires a ~1:10 back channel ratio, the HST provides a 1:32 ratio. The HST scheme is wonderful for manual input and some windowed/streaming protocols, inadequate for others. USR might have been able squeeze in a 450 or 600 baud back channel while retaining standard high speed modulation, but they didn't and even so it would have fallen short. The fault is largely in the standard Unix "g" protocol implementation, the protocol provides for negotiated packet sizes which would work acceptably with the HST, however the implementation is (9 cases of 10) broken and there is no way to actually specify that you want to use larger packet sizes. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
root@zswamp.fidonet.org (Geoffrey Welsh) (04/09/91)
George Robbins (grr@cbmvax.commodore.com ) wrote: >In article <7151.27F9618A@zswamp.fidonet.org> >root@zswamp.fidonet.org (Geoffrey Welsh) writes: > (Or am I displaying ignorance about the size of UUCP-g ACK/NAK packets?) >Broad category, yes, numbers no. UUCP requires a ~1:10 back >channel ratio, the HST provides a 1:32 ratio. That explains much! >USR might have been able squeeze in a 450 or 600 baud back channel They did. A 450 bps backchannel, with a 1:10 ratio as you describe, should lead to roughly 4500 bps performance... which explains the 380 CPS speed limit on UUCP-g over HST. >The fault is largely in the standard Unix "g" protocol >implementation, the >protocol provides for negotiated packet sizes which would >work acceptably with >the HST, however the implementation is (9 cases of 10) >broken and there is no >way to actually specify that you want to use larger packet >sizes. I've experimented with this and have also found that problem. -- 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