Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!agate!eos!ames!mailrus!tut.cis.ohio-state.edu!husc6!bbn!rochester!pt.cs.cmu.edu!ZOG.CS.CMU.EDU!tgl From: tgl@ZOG.CS.CMU.EDU (Tom Lane) Newsgroups: comp.dcom.modems Subject: Merits of compression (was Re: hayes 9600 vs. trailblazer) Message-ID: <1441@pt.cs.cmu.edu> Date: 16 Apr 88 19:15:05 GMT References: <8804110136.AA16978@ucbvax.Berkeley.EDU> <15612@onfcanim.UUCP> <4435@hoptoad.uucp> Sender: netnews@pt.cs.cmu.edu Organization: Carnegie-Mellon University, CS/RI Lines: 49 Summary: Yes, serial drivers are slow and compression is fast. In article <4435@hoptoad.uucp>, gnu@hoptoad.uucp (John Gilmore) writes: > It's sad but true that the bottleneck in sending ASCII data between > systems through a Telebit modem is getting to be the 19200 max speed on > the serial cable. Telebit really should support 38,400 baud. Actually, the bottleneck is getting to be the computer system's serial data transfer rate; see below. I seriously doubt that many Unix systems could sustain a 38kbps transfer through a serial port, especially if you wanted to get any other work done at the same time. > Jerry Aguirre mentioned that compressing data on the host burns less > CPU cycles too; this would be because running "compress" over say 500K > of data is cheaper than squirting 188K (the data saved) out the serial > port. The inner loop of compress must be a *lot* smaller than the > inner loop of the serial drivers on his system, though this might not > be true on all systems. The way I understand it, the problem is that the serial drivers don't *have* an inner loop; they're interrupt-per-character, and the context swap into the kernel, for each byte, is what kills you. Since most serial interfaces can't do DMA or buffer a reasonable number of input characters, there isn't any good way to improve on the situation. The basis of the problem is that both the serial interface hardware and the drivers were designed around the assumption of a terminal at the other end. The better ones can go pretty fast in the output direction, but high-speed input just wasn't thought of. So the bottleneck for news transfer is usually the receiving system, not the sender. Incidentally, LZW compression *is* pretty damn quick, and decompression is even quicker. It was designed for hardware implementation at megahertz throughput rates, with not a lot of hardware except the table memories. Welch's original article talks about implementing it in a hard disk controller, with on-the-fly compression at disk I/O transfer rates... I doubt that compress is going to be the bottleneck any time soon, particularly at the receiving end. Note that this implies that compression in the modem isn't a win; in fact, it's a major loss if the modem tries to compress already-compressed data. (At least, it is if both are using the same compression method. In the case of LZW, you are likely to see as much as 50% expansion if you try compressing compressed data.) -- tom lane Internet: tgl@zog.cs.cmu.edu UUCP: !zog.cs.cmu.edu!tgl BITNET: tgl%zog.cs.cmu.edu@cmuccvma