earle@poseur.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support) (05/02/91)
The argument that 9600 baud modems are not worth buying over 2400 baud modems because "You can't read that fast" is specious. I have 2 Telebit TrailBlazer Plus modems. At home, I've alternately had my trusty (crusty?) old Wyse 75 terminal, and a borrowed SPARCstation-1+ from work. While trying to use PPP with the SPARCstation, I cursed the fact that I didn't have a V.32 or V.32bis modem. But it's still faster than 2400 baud. To transfer files, if I didn't want to use "rcp" or "ftp", I used UUCP instead and I was damn glad to have PEP and UUCP spoofing available instead of 2400 baud. Now that I'm back to a plain terminal again, there's still a win. No, I can't read faster than 2400 baud. Butif I'm in "rn", I see a full page appear on my screen much faster than at 2400 baud. If I decide I don't want to read it, I can hit "n" or "q" or whatever and get on with it much faster than waiting for a page that I don't want to read come up at 2400 baud. Also, anyone who runs on a BSD system and has a plain terminal with halfway decent capabilities would be insane not to use "screen" to multiplex it. When you have 2 or 3 (or 5) "screen" virtual terminal windows in use, and you switch between them, each time the full screen has to be refreshed. This happens a helluva lot faster with a 19200 baud PEP connection than it does at 2400 baud. Time spent waiting is wasted time. I can't get any useful work done at 1200 baud, it's just too slow. There's enough stutter start-stop in painting a screen's full of text in a 19200 baud PEP connection that I get annoyed sometimes. 2400 baud is useable, but barely tolerable. I equate a 2400 baud modem for dumb terminal interactive use with a PEP link for PPP - it's useable, but it's barely tolerable and eventually it gets on my nerves. After having the PEP modem I'd never be able to go back to a 2400 baud modem. And, if Telebit ever gets off their fannies and delivers a V.32bis successor to the T2500 (so I have a way to trade in my TB+'s), I suspect that after going to those, I will feel the same way about the TB+ as I do about 2400 baud modems. Onward and upward. -- - Greg Earle | "It's going to be Party Time when I Sun Microsystems, Los Angeles | shit out the Balloons" JPL on-site Software Support | earle@poseur.JPL.NASA.GOV | - From a sheet of stamps I saw
peter@ficc.ferranti.com (Peter da Silva) (05/03/91)
In article <6196@mahendo.Jpl.Nasa.Gov> earle@poseur.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support) writes: > The argument that 9600 baud modems are not worth buying over 2400 baud modems > because "You can't read that fast" is specious. They're not worth paying 10 times as much if you're doing interactive work. That's not the same thing. What do you want to use them for? > To transfer files, if I didn't want to use "rcp" or "ftp", I used UUCP > instead and I was damn glad to have PEP and UUCP spoofing available instead > of 2400 baud. Yep. > Now that I'm back to a plain terminal again, there's still a win. No, I can't > read faster than 2400 baud. Butif I'm in "rn", I see a full page appear on > my screen much faster than at 2400 baud. If I decide I don't want to read it, > I can hit "n" or "q" or whatever and get on with it much faster than waiting > for a page that I don't want to read come up at 2400 baud. That's a user interface problem again: rn should flush output and perform the command as soon as you hit that key, the way 'vnews' does it. Or Emacs. > Also, anyone who runs on a BSD system and has a plain terminal with halfway > decent capabilities would be insane not to use "screen" to multiplex it. That's a user-interface problem. You can get a terminal with multiple pages for a lot less than a high pseed modem, and then screen flipping could be made tremendously faster. Don't blame the modem if the programs you use are designed for higher speeds. A faster modem is nice. It's not worth the difference in cost, yet. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
pplacewa@bbn.com (Paul Placeway) (05/12/91)
peter@ficc.ferranti.com (Peter da Silva) writes: < In article <6196@mahendo.Jpl.Nasa.Gov> earle@poseur.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support) writes: < > Now that I'm back to a plain terminal again, there's still a win. No, I can't < > read faster than 2400 baud. Butif I'm in "rn", I see a full page appear on < > my screen much faster than at 2400 baud. If I decide I don't want to read it, < > I can hit "n" or "q" or whatever and get on with it much faster than waiting < > for a page that I don't want to read come up at 2400 baud. < That's a user interface problem again: rn should flush output and perform < the command as soon as you hit that key, the way 'vnews' does it. Or Emacs. Unless you are calling into an Annex, and then going into your host with telnet or rlogin, as I am now. In this case, it doesn't matter that Emacs is smart enough to do the "right thing", because it has allready sent the *entire* screen refresh to the Annex before my typed character reaches it, so it can't flush because it thinks it doesn't have to. Scrolling down several pages in some code is really painful as a result. Yes, this sucks, and *maybe* telnet and rlogin can be told to "forget it" sometimes, if done carefully, but for some dialins there will be a non-flushable buffer in the path, and 2400 will always be painful. < Don't blame the modem if the programs you use are designed for higher speeds. < A faster modem is nice. It's not worth the difference in cost, yet. On this one I have to agree with Peter. CompuCon shouldn't be encouraged because they are using a non-standard protocol (but then so are MicroCom, Hayes, Telebit, and USR), but then again they should be, becuase they are doing a 9600 bps (w/o compression) modem for $169, albeit only for a type of computer that I avoid both at work and at home. Eventually v.32bis will drop in price, just as 300, 1200 and 2400 did. Until then I'll be hacking away at 2400 I guess... --P
rockwell@socrates.umd.edu (Raul Rockwell) (05/13/91)
Paul Placeway: Peter da Silva: < That's a user interface problem again: rn should flush output and < perform the command as soon as you hit that key, the way 'vnews' < does it. Or Emacs. Unless you are calling into an Annex, and then going into your host with telnet or rlogin, as I am now. In this case, it doesn't matter that Emacs is smart enough to do the "right thing", because it has allready sent the *entire* screen refresh to the Annex before my typed character reaches it, so it can't flush because it thinks it doesn't have to. This would largely go away if emacs could be told that the connection is really 2400 baud (or whatever) so that it wouldn't get much more than a second ahead of what you should be able to receive. Raul Rockwell
peter@ficc.ferranti.com (Peter da Silva) (05/13/91)
In article <64136@bbn.BBN.COM> pplacewa@bbn.com (Paul Placeway) writes: > Unless you are calling into an Annex, and then going into your host > with telnet or rlogin, as I am now. In this case, it doesn't matter > that Emacs is smart enough to do the "right thing", because it has > allready sent the *entire* screen refresh to the Annex before my > typed character reaches it, Ok, well that's a fairly unusual situation. I'll give you the point, though. Sometimes it's a hardware problem instead of a software problem that's the hangup. As for CompuCon... internal modems are the devil's work. Using up an IRQ per serial port is nasty nasty nasty. I wish someone would reverse engineer the Trailblazer and get the price down on those babies. It's the most reliable protocol I've found. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
wtm@uhura.neoucom.EDU (Bill Mayhew) (05/14/91)
On a slightly related note, I usually use T1000 and TB+ modems in V.22bis mode as opposed to PEP mode for interactive typing connections. The TB modems with newer firmware use an input buffer low-water mark sensing strategy that allows the modems to switch to shorter packets as the input buffer empties. The short packets are 40 mS long, while the standard packes are 136 mS. This mode switching is noticable when catting a file: you'll see the first few lines dump to your screen at a liesurely pace, followed by a brief pause, then a torrent of output. The problem is that PEP mode is half-duplex, which means that echoing a typed character in interactive mode takes about 80 mS plus change and host / client overheads. This corresponds to only about 12 character per second typing. While the TB has an input buffer, the result is annoyingly choppy display of the characters. Thought a ^L screen repaint in vi takes several seconds longer at 2400 bps, the usability factor with 240 cps bidirectional link makes interactive use limitlessly smoother and more satisfying. V.42 modems seem to exhibit similar choppieness for interactive typing while they consider whether or not to buffer characters for compression. I use an AT sequence in my cu dialer string to make sure V.42 compression is switched off when using a V.32 modem. Now, if manufacturers would only standardize the AT sequence! Bill -- Bill Mayhew NEOUCOM Computer Services Department Rootstown, OH 44272-9995 USA phone: 216-325-2511 wtm@uhura.neoucom.edu ....!uunet!aablue!neoucom!wtm via internet: (140.220.001.001)