From owner-freebsd-net Fri Feb 2 7: 9:10 2001 Delivered-To: freebsd-net@freebsd.org Received: from measurement-factory.com (unknown [206.168.0.5]) by hub.freebsd.org (Postfix) with ESMTP id BBE9037B503 for ; Fri, 2 Feb 2001 07:08:52 -0800 (PST) Received: from localhost (rousskov@localhost) by measurement-factory.com (8.9.3/8.9.3) with ESMTP id IAA94276; Fri, 2 Feb 2001 08:08:20 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Date: Fri, 2 Feb 2001 08:08:20 -0700 (MST) From: Alex Rousskov To: Yu-Shun Wang Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPComp question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 2 Feb 2001, Yu-Shun Wang wrote: > What you pointed out below is true. But I am more > interested in the relative performance since the number > I measured were under exactly the same setup and traffic > condition. I believe it is a common pitfall to assume that same conditions allow for relative comparisons even when the measurement tool or methodology is "broken". The relative results may amaze you, but I would not trust them. :) > I am just curious why IPComp was _relatively_ > (and signigicantly) slower than most of the encryption > algorithm. If by "slower" you mean "yields lower throughput" under netperf, then keep in mind that your test probably did not measure throughput correctly. Here is an example. Let's assume that algorithm A delays every packet by 1msec and algorithm B delays every packet by 2msec. For simplicity, let's also assume that packet sizes do not change. Under correct testing conditions, both algorithms should yield the same throughput (X Mbits/sec). With netperf's TCP_STREAM, the throughput of A will be times 2 higher than the throughput of B! > So I guess bandwidth is probably not the best > pointer since what I end up comparing was really the > implementations of different encryption/compression > algorithms which are CPU-bound in this case. I would suggest to define exactly what you want to compare first (i.e., decide what your primary metrics are; why you are running these tests) and only then design the test and choose an appropriate benchmark. Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message