From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 4 17:20:09 2005 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9958716A41F; Fri, 4 Nov 2005 17:20:09 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id B823A43D45; Fri, 4 Nov 2005 17:20:08 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from flame.pc (aris.bedc.ondsl.gr [62.103.39.226]) by aiolos.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id jA4HK6RA022039; Fri, 4 Nov 2005 19:20:06 +0200 Received: from flame.pc (flame [127.0.0.1]) by flame.pc (8.13.4/8.13.4) with ESMTP id jA4HJvPg001145; Fri, 4 Nov 2005 19:19:57 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by flame.pc (8.13.4/8.13.4/Submit) id jA4HJvMF001144; Fri, 4 Nov 2005 19:19:57 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 4 Nov 2005 19:19:57 +0200 From: Giorgos Keramidas To: babkin@users.sourceforge.net Message-ID: <20051104171957.GA1120@flame.pc> References: <29995980.1131124468471.JavaMail.root@vms062.mailsrvcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29995980.1131124468471.JavaMail.root@vms062.mailsrvcs.net> X-Mailman-Approved-At: Sat, 05 Nov 2005 17:13:10 +0000 Cc: kamal kc , freebsd , freebsd Subject: Re: Re: allocating 14KB memory per packet compression/decompression results in v X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2005 17:20:09 -0000 On 2005-11-04 11:14, Sergey Babkin wrote: >Giorgos Keramidas wrote: >>On 2005-11-03 22:56, kamal kc wrote: >>> since i am using the adaptive LZW compression scheme it >>> requires construction of string table for >>> compression/decompression. So an ip packet of size 1500 bytes >>> requires a table of size (4KB + 4KB + 2KB = 12KB). >> >> I may be stating the obvious or something totally wrong, but >> couldn't the string table be constructed once instead of each >> time a packet goes down? It is my intuition that this would >> perform much much better than re-doing the work of the string >> table each time a packet goes out. > > No, the table changes as data is compressed. It records the > knowledge about the strings that have already occured in the > data. > > Keeping the table between the packets would improve the > compression but the packets would have to be transmitted > through a reliable medium since to decompress a packet you > would have to decompress all the preceding packets first > (essentially you get a stream compression). Ah, yes, I see now. You're right of course. I was thinking of something resembling a "compressed tunnel" when I wrote the reply, but that doesn't work with IP very well, unless some other sort of encapsulation is at work. > To keep the packets separate, the compression state > must be reset between them. > > But of course resetting the compression state does not > mean that the memory should be deallocated. Very true :)