robertb@uw-june (Robert Bedichek) (02/17/89)
I just bought a pair of THE(r) 9600 baud modems and now find that apparently they are unsuitable for interactive use at speeds above 2400 baud! I wonder if any one on the net can shed light on my problem. The problem is that they are half duplex and the modem takes a full second to turn the line around. The result is that response to key strokes is delayed by a full second. I called PC Network, the mail order company that I purchased from, and they said they thought "that's just the way they work" and gave me the number of the manufacturer, Fastcomm. The guy at Fastcomm said "that's just the way they work." I said "so, these modems are not meant for interactive use?", he replied "right." I find it hard to believe that anyone would design a modem like the THE 9600, which is meant to be low cost ($400 apiece) and plug into PC's, and make it not usable for 99 percent of the applications people with PC's put their modems to. I realize that the hardware to do 9600 in both directions at the same time is expensive, but what's expensive about having the line be able to switch directions in, say, 50 milliseconds (assuming a short-haul)? Or having a low speed channel going the other way (I think that the Telebit Trailblaisers have a 75 baud channel going the opposite direction of the high speed channel)? Am I really stuck? PC Network is making noises like I can't return these modems for cash, and perhaps not every for an in-store credit! Can anyone recommend a 9600 baud modem that doesn't have this problem. I'm thinking about getting the USR 9600 HST, which are $225 more per modem, but which at least *work*. Rob "I'm-really-bummed" Bedichek
dmt@mtunb.ATT.COM (Dave Tutelman) (02/18/89)
In article <7298@june.cs.washington.edu> robertb@uw-june (Robert Bedichek) writes: >I just bought a pair of THE(r) 9600 baud modems and now find that >apparently they are unsuitable for interactive use at speeds above 2400 >baud! > >The problem is that they are half duplex and the modem takes a full ^^^^^^^^^^^ >second to turn the line around. That is what half-duplex means; it's that simple. If the modem was advertised as half-duplex, you have only yourself to blame. I recognize that not everyone is a modem techie, BUT you ought to know what the buzzwords mean in the specs, when you buy something. >The result is that response to key strokes is delayed by a full second. I know it's no consolation but "that's just the way they work." >I find it hard to believe that anyone would design a modem like the THE >9600, which is meant to be low cost ($400 apiece) and plug into PC's, >and make it not usable for 99 percent of the applications people with >PC's put their modems to. Half-duplex modems are intended for bulk data transfers, using block sizes large enough so that the line turn-around time for acknowledgment doesn't negate the line speed. If two line turn-arounds take 1 sec (probably a reasonable number, and in agreement with your observation above) then the block size should be well over 9600 bits (1000 bytes). Certainly not efficient for interactive use, as you've noticed :-(, but certainly not useless for PCs. YOU use YOUR modem for interactive communications, but lots of people only use their modem to download stuff from BBSs. This modem is ideal for them. >I realize that the hardware to do 9600 in both directions at the same >time is expensive, There IS a way that's probably cheaper than the modem you bought, but you need TWO lines. That's either two simultaneous phone calls, or a "four-wire private line". Going 9600 bits per second full duplex on an average dial-up connection is a real trick. >but what's expensive about having the line be able >to switch directions in, say, 50 milliseconds (assuming a short-haul)? ...and how does the modem know it's short-haul? And why should that make a difference? The turn-around delay isn't a function of how fast the signal travels; it's how fast the modem can reliably detect and synch to the signal. >Or having a low speed channel going the other way (I think that the >Telebit Trailblaisers have a 75 baud channel going the opposite >direction of the high speed channel)? ...so why didn't you buy a Telebit? Seriously, all these things are feasible but cost money. Someone aiming at a low-end PC-market 9600-baud modem is going to build a feasible equalizer/mod/demod, and spend NOTHING on the frills you suggest. >Am I really stuck? PC Network is making noises like I can't return >these modems for cash, and perhaps not every for an in-store credit! I have no personal experience with PC Network, having been scared away by lots of previous postings on the net. But I'm sure you'll get suggestions from those who have dealt with them. >Can anyone recommend a 9600 baud modem that doesn't have this problem. >I'm thinking about getting the USR 9600 HST, which are $225 more per >modem, but which at least *work*. Is it Half-Duplex or Full-Duplex? If full-duplex, can it work over a single dial-up connection? If Half-duplex, what's its line-turn-around time? Don't buy it without being satisfied with the answers to these questions. >Rob "I'm-really-bummed" Bedichek Rob, I'm sorry that you're bummed, and I'm sorry that I can't sound more sympathetic with your plight. I'm not angry with you, and I DO feel sorry for your predicament. But: - Half-duplex has a meaning, it's an old and well-understood meaning, and you've just discovered what it is. - The modem you bought is not a stupid product, as you intimated. It's just stupid for your intended application. +---------------------------------------------------------------+ | Dave Tutelman | | Physical - AT&T Bell Labs - Lincroft, NJ | | Logical - ...att!mtunb!dmt | | Audible - (201) 576 2442 | +---------------------------------------------------------------+
ddb@ns.UUCP (David Dyer-Bennet) (02/22/89)
In article <7298@june.cs.washington.edu> robertb@uw-june (Robert Bedichek) writes: >Can anyone recommend a 9600 baud modem that doesn't have this problem. >I'm thinking about getting the USR 9600 HST, which are $225 more per >modem, but which at least *work*. The USR HST is the modem of choice for fidonet bbs use at the moment (i.e. most 9600 fidonet systems are using the hst). I've got one and can offer some comments. It's 9600 baud one way with a 450 baud back-channel the other way, and it turns the channels around as needed; with the back channel, a turn-around isn't needed for an "ack" in file transfers, at least. It works fine for terminal connections, obviously. I can't give time for the turnaround, but you don't see turnarounds much in normal use. I've never noticed the delay :-). It also supports 0-300, 1200, and 2400, and it supports MNP up through level 5 as appropriate; having one of these might give you some performance improvements even with systems not equipped for 9600, since mnp level 3 gives a "real" 20% throughput improvement (real meaning not due to data compression; you get it even with .arc files). There's a lot to be said for waiting until the 9600 baud market settles down, but my HST works well and allows a lot of people to connect to me with fast throughput, so I can't complain. The HST and the Telebit seem to be the current market leaders; for usenet you want telebit, for fidonet you want hst. For other things you want to be sure you know what they support before you buy :-). -- David Dyer-Bennet, ddb@ns.network.com or ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb or ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb or Fidonet 1:282/341.0, (612) 721-8967 hst/2400/1200/300
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (02/24/89)
In article <1149@ns.UUCP> ddb@ns.UUCP (David Dyer-Bennet) writes: | so I can't complain. The HST and the Telebit seem to be the current market | leaders; for usenet you want telebit, for fidonet you want hst. For other | things you want to be sure you know what they support before you buy :-). I'm told that the HST comes in a model (HST/ix??) which does uucico 'g' protocol spoofing, and that it's about as fast as the telebit. Could anyone comment on this? -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
karl@ddsw1.MCS.COM ([Karl Denninger]) (02/25/89)
>Response 4 of 4 (1861) by davidsen at steinmetz on Fri 24 Feb 89 5:33 >[William E. Davidsen Jr] > >In article <1149@ns.UUCP> ddb@ns.UUCP (David Dyer-Bennet) writes: > >| so I can't complain. The HST and the Telebit seem to be the current market >| leaders; for usenet you want telebit, for fidonet you want hst. For other >| things you want to be sure you know what they support before you buy :-). > > I'm told that the HST comes in a model (HST/ix??) which does uucico >'g' protocol spoofing, and that it's about as fast as the telebit. Could >anyone comment on this? Sure -- HST/ix is a software AND hardare product. Yes, it's nice -- IFF you have another HST/ix set to talk to on the other end. We were a beta site for the software -- the software _says_ it will work with the Telebits too. The appearance is a lot like Zmodem with some compression layered on top of HDB UUCP; the major difference is that there is a cutesy menu interface to the entire package. The biggest problem you'll have is that there aren't many HST/ix kits out there.... and since it's non-'g' protocol as far as I can tell you're out of luck if the other end doesn't support what you're doing. Without help the HSTs do TERRIBLY on uucp calls, as the back-channel is not big enough to pass the "acks" without turning around the line. --- Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl) Data: [+1 312 566-8912], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality solutions at a fair price"
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (02/27/89)
In article <[1861.5]karl@ddsw1.comp.ibmpc;1> karl@ddsw1.MCS.COM ([Karl Denninger]) writes: >Without help the HSTs do TERRIBLY on uucp calls, as the back-channel is not >big enough to pass the "acks" without turning around the line. > It's too bad that current implementations of uucp have problems with using larger packet sizes. The packet size information is exchanged during the handshake process, but something isn't handled quite right. Maybe some combinations work - HDB/HDB or BSD/BSD. We need a good PD uucp implementation that does it right. A 256 byte packet size would make a big difference for HST modems (the ack would fit in the back channel) and for people using PC Pursuit. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI mailrus!b-tech!zeeff
csg@pyramid.pyramid.com (Carl S. Gutekunst) (02/28/89)
In article <5138@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >The packet size information is exchanged during the handshake process, but >something isn't handled quite right. True. There are hardwired constants in places, and fixed size buffers. >Maybe some combinations work - HDB/HDB or BSD/BSD. Nope. Sometimes you get lucky, but that's about it. >We need a good PD uucp implementation that does it right. Several people have done this in their own UUCP's. Just don't call your new protocol 'g', or you'll break all the existing implementations. The better solution for modems like the HST is a streaming protocol, like 'f' but more robust and less overhead. I keep toying with this idea, as does Rick Adams, but we never get around to an implementation. <csg>
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (03/02/89)
In article <60827@pyramid.pyramid.com> csg@pyramid.UUCP (Carl S. Gutekunst) writes: | Several people have done this in their own UUCP's. Just don't call your new | protocol 'g', or you'll break all the existing implementations. The better | solution for modems like the HST is a streaming protocol, like 'f' but more | robust and less overhead. I keep toying with this idea, as does Rick Adams, | but we never get around to an implementation. One existing protocol which does very well at this is zmodem. Rather than invent a new protocol, perhaps this could be added. It was designed to run of long delay networks, and the back traffic is minimal. Maybe someone could suggest that UNIX international push on AT&T a little and see if a new *standard* protocol could be added to HDB. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
csg@pyramid.pyramid.com (Carl S. Gutekunst) (03/02/89)
>In article <60827@pyramid.pyramid.com> csg@pyramid.UUCP (Carl S. Gutekunst) writes: >The better solution for modems like the HST is a streaming protocol, like >'f' but more robust and less overhead. I keep toying with this idea, as >does Rick Adams, but we never get around to an implementation. In article <13275@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > One existing protocol which does very well at this is zmodem. Rather >than invent a new protocol, perhaps this could be added. This is exacly what Rick and I were originally planning. After some study of the zmodem protocol, however, I've decided against it. The zmodem protocol is strictly for practically error free channels like X.25; error recovery is expensive. It also requires 8-bit transparency. What I want -- and I have the groundwork of a design -- is a streaming protocol that provides fairly cheap error correction, and is thus suitable over a variety of media, including standard non-intelligent modems. The protocol would also have to be extensible, so new features could be added without breaking existing installations. One place it would not work is really trashy dialup lines; but that's what we have 'g' protocol for. :-) <csg>
rkh@mtune.ATT.COM (Robert Halloran) (03/02/89)
In article <13275@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <60827@pyramid.pyramid.com> csg@pyramid.UUCP (Carl S. Gutekunst) writes: > >| Several people have done this in their own UUCP's. Just don't call your new >| protocol 'g', or you'll break all the existing implementations. The better >| solution for modems like the HST is a streaming protocol, like 'f' but more >| robust and less overhead. I keep toying with this idea, as does Rick Adams, >| but we never get around to an implementation. > > One existing protocol which does very well at this is zmodem. Rather >than invent a new protocol, perhaps this could be added. It was designed >to run of long delay networks, and the back traffic is minimal. > > Maybe someone could suggest that UNIX international push on AT&T a >little and see if a new *standard* protocol could be added to HDB. Unfortunately for this line of thought, the impression is that the features being added to SysV are driven by the standards organizations (IEEE POSIX, ANSI C, etc.) and the existing Unix applications market (BSD networking, XENIX binary compatibility for Intel CPU's). The fact that zmodem is a up and coming protocol in the DOS world probably would make no difference to them, since that's not where their interests lie. Bob Halloran ========================================================================= UUCP: att!mtune!rkh Internet: rkh@mtune.ATT.COM USPS: 17 Lakeland Dr, Port Monmouth NJ 07758 DDD: 201-495-6621 eve ET Disclaimer: If you think AT&T would have ME as a spokesman, you're crazed. Quote: "May: In Baton Rouge, the Rev. Jimmy Swaggart, announcing that he has been forgiven by the Lord, returns to his pulpit, where he receives a warm reception from 300 billion locusts." - Dave Barry's 1988 Year-In-Review
randy@chinet.chi.il.us (Randy Suess) (03/03/89)
In article <13240@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > I'm told that the HST comes in a model (HST/ix??) which does uucico >'g' protocol spoofing, and that it's about as fast as the telebit. Could >anyone comment on this? We just had the USR folks over to a local meeting where they donated two if their latest HST modems to CBBS. They have *no* plans on a 'g' protocol spoofer. Their new modem now runs 14,200 baud max. -- Randy Suess randy@chinet.chi.il.us
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (03/03/89)
From a coding point of view, it seems alot easier to fix the problems
with 'g' at larger packet sizes that to create a whole new protocol.
I'd guess that with a days effort, someone could make these modems
with small reverse channels work efficiently. Uucp has some exchange
that indicates what packet sizes an implementation can use - if it
doesn't do it right, I agree, a new protocol letter should be used.
Come on AT&T, fix 'g' larger packet sizes in Sys V.4.
--
Jon Zeeff zeeff@b-tech.ann-arbor.mi.us
Ann Arbor, MI mailrus!b-tech!zeeff
----- Use lint! -----