From owner-freebsd-net  Thu Feb  1 16:51:48 2001
Delivered-To: freebsd-net@freebsd.org
Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97])
	by hub.freebsd.org (Postfix) with ESMTP id BAD2837B4EC
	for <freebsd-net@freebsd.org>; Thu,  1 Feb 2001 16:51:30 -0800 (PST)
Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1])
	by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id JAA22231;
	Fri, 2 Feb 2001 09:51:22 +0900 (JST)
To: Yu-Shun Wang <yushunwa@isi.edu>
Cc: freebsd-net@freebsd.org
In-reply-to: yushunwa's message of Thu, 01 Feb 2001 15:48:37 PST.
      <Pine.BSF.4.31.0102011540120.1012-100000@amc.isi.edu>
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: Re: IPComp question 
From: itojun@iijlab.net
Date: Fri, 02 Feb 2001 09:51:22 +0900
Message-ID: <22229.981075082@coconut.itojun.org>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


>	Another (sort of) related question: I've got the bandwidth
>	measurements for different algorthms using netperf. I was
>	really surprised that IPComp did so bad. Any ideas?

	thanks for measurements, it's good to see.
 
	i guess couple of reasons here.
	- because we compress short packets with IPComp, we cannot make a good
	  use of compression history/dictionary.  we always initialize
	  everything on every packet, and it can consume cpu time.
	- zlib buffer management - it has ring buffer management on both
	  in/output ends, because we will see data stream with different sizes.
	- zlib memory management - heavy use of malloc?

itojun


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message