From owner-freebsd-hackers Fri Nov 10 11:24:47 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id LAA07921 for hackers-outgoing; Fri, 10 Nov 1995 11:24:47 -0800 Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.20.4]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id LAA07916 for ; Fri, 10 Nov 1995 11:24:44 -0800 Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id NAA24579; Fri, 10 Nov 1995 13:21:28 -0600 From: Joe Greco Message-Id: <199511101921.NAA24579@brasil.moneng.mei.com> Subject: Re: I/O woes. To: terry@lambert.org (Terry Lambert) Date: Fri, 10 Nov 1995 13:21:28 -0600 (CST) Cc: imb@scgt.oz.au, geoff@schwing.ginsu.com, hackers@FreeBSD.ORG In-Reply-To: <199511101833.LAA03954@phaeton.artisoft.com> from "Terry Lambert" at Nov 10, 95 11:33:54 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > > 1) you should ALWAYS use hardware flow control unless you have a REALLY good > > > reason not to. REALLY good, as in, the device you are talking to doesn't > > > support it. > > > > That's the ONLY reason not to. > > What if you wanted to type ^C and have the output actually abort > (as requested via a real time event) instead of waiting until the > flow controlled buffers in the intermediate path drain before > actually stopping? Unless you have a slow modem, this isn't going to be a Real Big Issue for most people. Even with a 2K on-board buffer, a 14.4K modem will appear to respond to a ^C in about a second. As someone who used to do a lot of "playing" in this area, when 300 and 1200 baud modems were new and cool, I will state that it's a real pain in the rump for a number of reasons: 1) you cannot get ANY sort of compression out of the modem, and are therefore limited to your default speed. 2) you cannot use error correction, because error correction will potentially introduce delays and cause the modem to buffer data. 3) well, I think 1 and 2 are bad enough. Now, of course, you can make special cases until you're blue in the face. I can too. But: for the average user, running interactive logins, UUCP, SLIP/PPP, or file transfers over a 9600-baud-or-faster link, you're really going to want to use hardware handshaking and allow the modem to do compression and error correction. For the average user running at 1200 baud on a laptop (i.e. me at home), there is a minor amount of suffering through a few seconds of buffered data if you really want it to stop. You gotta do it this way for most apps. Else we might as well go back to the days of dumb modems that did nothing but modulate and demodulate. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847