Date: Fri, 10 Nov 1995 12:58:33 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jgreco@brasil.moneng.mei.com (Joe Greco) Cc: terry@lambert.org, imb@scgt.oz.au, geoff@schwing.ginsu.com, hackers@FreeBSD.ORG Subject: Re: I/O woes. Message-ID: <199511101958.MAA04221@phaeton.artisoft.com> In-Reply-To: <199511101921.NAA24579@brasil.moneng.mei.com> from "Joe Greco" at Nov 10, 95 01:21:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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: Well, back when I started, you had to punch your bits out of paper tape, throw them in a box, and *drive* them to the machine. 8-). > 1) you cannot get ANY sort of compression out of the modem, and are > therefore limited to your default speed. I'd call this your "committed data rate". Actually, I first started hating flow control when DEC introduced the VT3xx series of terminals using a soft-coded state machine. Without flow control, the damn things could barely keep up with 9600 baud. But you could set the port speed all the way op there. DEC was using flow control so that they could lie to me about the actual data rate their terminal could support. I've always been a fan of host compression. Modem based compression schemes make the modem<->computer interface the speed bottleneck. If I can get 2:1 compression on my host, I can pump twice as much data through as my port rate allows instead of being limited by my port rate and having the modem pump twice as much as the phone line allows. Mostly modem compression serves to piss people off. When MNP first came out, people like Multitech were lowballing the Microcom modems by forcing the in band flow control on if MNP was enabled so they could cheap out on the buffer RAM needed to support MNP and make their modems cost less. Royal pain in the ass if you tried to transfer binary data. Apple saw this bottleneck, and even today, the compression and encapsulation is built into the protocol stack in the host instead of the modem for their remote access product. > 2) you cannot use error correction, because error correction will > potentially introduce delays and cause the modem to buffer data. Actually, I'm more concerned about pool size for pool retention under compression. The compression is what really bloats this. I have no real problem with out of band flow control (well, except that most UNIX systems implement it incorrectly -- I can still hang serial ports under SunOS 4.1.3_u2 using it) as long as the pool is relatively small and therefore innocuous. This is actually sufficient for error correction -- assuming you don't put that on the host too (suprise! Just like PostScript in the host reducing printer cost, compression and error correction in the host reduce modem cost!). Actually, for a sliding window protocol, as long as there is enough RAM in the modem to cover the entire window, flow control can be handled in the protocol implementation in the host with no problems. > 3) well, I think 1 and 2 are bad enough. 8-). > 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. I actually refer to those as "the good old days". 8-). I think you are missing out on some now overlooked techniques, such as Mike Ballard's (remember Telebit?) protocol spoofing, etc.. Just because a lot of bad things have now become standards doesn't mean that they are good or that we shouldn't work to change them whenever an opportunity presents itself. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511101958.MAA04221>