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 [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
