Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!cornell!rochester!pt.cs.cmu.edu!ZOG.CS.CMU.EDU!tgl From: tgl@ZOG.CS.CMU.EDU (Tom Lane) Newsgroups: comp.dcom.modems Subject: Re: Merits of compression (was Re: hayes 9600 vs. trailblazer) Message-ID: <1473@pt.cs.cmu.edu> Date: 20 Apr 88 14:22:40 GMT References: <8804110136.AA16978@ucbvax.Berkeley.EDU> <15612@onfcanim.UUCP> <405@dragos.UUCP> Sender: netnews@pt.cs.cmu.edu Organization: Carnegie-Mellon University, CS/RI Lines: 36 Summary: Turning LZW on/off is harder than it looks. In article <405@dragos.UUCP>, work@dragos.UUCP (Dragos Ruiu) writes: > It is very simple to keep track of your on the fly compression rate with > LZW. I would assume that as soon as it sees negative compression for X > packets, the 'Blazer would shut off compression for a while or send the > next packet in plain text, only resuming the compression when a packet > that gives a positive compression ratio hits. One of the few bad features of LZW is that it is very hard to turn it on and off "on the fly" like this. The problem is that the compression and decompression symbol tables must be kept in sync, or decompression will be impossible. Compressing a chunk of text nearly always gives rise to new entries in the table, so you cannot easily compress a packet and then decide not to send it in compressed form. (The decompressor must be run against the compressed packet in order to update its own table.) There are ways around this if you have oodles of memory and computing power (remembering and undoing the table changes, for instance), but I doubt that Telebit's little 68000 is twiddling its thumbs much... A simple way of doing it would be to flush both tables whenever you decided that compression should be temporarily disabled. You then couldn't turn compression back on until you had seen some number N of packets that showed adequate compression *starting from an empty table*. I suspect that this would hurt your overall results badly, but I don't have any data to prove it. Anybody know of any actual research that's been done along this line? > It might also be interesting to hear how Telebit > chose to implement LZW, i.e. when they flush their code table and if they > use variable length bit-strings when compression is turned on. I'd be interested to hear that too. -- tom lane Internet: tgl@zog.cs.cmu.edu UUCP: !zog.cs.cmu.edu!tgl BITNET: tgl%zog.cs.cmu.edu@cmuccvma