Date: Fri, 2 Feb 2001 08:08:20 -0700 (MST) From: Alex Rousskov <rousskov@measurement-factory.com> To: Yu-Shun Wang <yushunwa@isi.edu> Cc: freebsd-net@FreeBSD.ORG Subject: Re: IPComp question Message-ID: <Pine.BSF.4.10.10102020753170.93740-100000@measurement-factory.com> In-Reply-To: <Pine.BSF.4.31.0102020009250.931-100000@amc.isi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10102020753170.93740-100000>