jqj@cornell.UUCP (J Q Johnson) (09/26/85)
People using a terminal emulator on home computer with a modem soon find that 1200b or 2400b isn't all that fast. In principal, effective data rates for typical interactive terminal sessions could be improved by at least a factor of 2 or 3 using data compression techniques. Does anyone have software for such host=>terminal data compression? Easy static techniques exist for 20% to 50% improvements; can we do better? Note that in addition to being self-synchronizing or reliable (to cope with modem transmission failures) any such technique must not be too costly to either encode or decode. Note also that various vendors have quite efficent proprietary implementations. My particular environment is a 4.xBSD host and an ATT 3b2 (sys V) or IBM PC (running DOS or Xenix) client, talking at 1200b asynch 7 bit with XON/XOFF. Ideally I'd like public domain code that supports at least one of these environments. Failing that, pointers to algorithms or publicly available implementations for other environments would also be appreciated. Given sufficient feedback, I will of course summarize. cornell!jqj UUCP jqj@cornell.arpa Internet
nazgul@apollo.uucp (Kee Hinckley) (10/02/85)
It is my belief that some of the new 4800 baud modems under development do this internally (that is, they are actually 2400 baud + data compression). It would be interesting if that technology trickled down to the 1200 baud modems, but of course you'll have to buy a new modem... -kee ...decvax!wanginst!apollo!nazgul
jqj@cornell.UUCP (J Q Johnson) (10/03/85)
In article <294a86e4.8e4@apollo.uucp> nazgul@apollo.uucp (Kee Hinckley) writes: >It is my belief that some of the new 4800 baud modems under development >do this internally (that is, they are actually 2400 baud + data >compression). It would be interesting if that technology trickled >down to the 1200 baud modems, but of course you'll have to buy a >new modem... No, you'll have to buy at least *2* new modems, and probably n > k where k is the number of modems in your modem pool on the host. Switching to a new modem protocol can be very expensive! One solution is an outboard data compression box that you can add on, but box+modem is probably still a lot more expensive than an integrated solution. The advantage of doing it in software, at least on the client end, is that you already have this overpowerd PC sitting there waiting to be used. Presumably, the PC can also be a lot smarter about its compression algorithm than could an inexpensive modem.
lauren@vortex.UUCP (Lauren Weinstein) (10/04/85)
I was involved in work in this area some years ago. In practice, don't expect more than about 30-40% compresson on typical text--this goes WAY down if you try to run display editors over such circuits due to the large number of control characters that greatly disrupt the "text" aspects of the compression. There are a variety of synchronization problems to deal with, and for best results the host must have the compresson code buried WITHIN the tty driver itself. --Lauren--
steved@athena.UUCP (Steve Dum) (10/08/85)
>>I was involved in work in this area some years ago. In practice, don't >>expect more than about 30-40% compresson on typical text--this goes >> ... >>--Lauren-- I know of one company now selling compression boxes that go on each end of the data line before the modem that are managing compression rations of 2.5 to one for typical text. Here typical means things like c program source, man pages or prose. I haven't seen any data for what their algorithm might do for edit sessions. However if the edit session is highly interactive most of the time is due to turnaround rather than baud rate. I believe they sell a z80 based black box for under $1000. Its from Adaptive Computer Technology 408-279-3993.
lauren@vortex.UUCP (10/09/85)
The very best compression systems in general use (like "compress") still achieve less than 50% compression for typical text. Of course, if you select the text carefully for your statistics, you can seem to do much better. Display editors and other programs that fiddle with cursor addressing sequences and such can really screw up compression program effectiveness, by the way. --Lauren--