Date: Fri, 2 Feb 2001 00:20:30 -0800 (PST) From: Yu-Shun Wang <yushunwa@isi.edu> To: Alex Rousskov <rousskov@measurement-factory.com> Cc: <freebsd-net@FreeBSD.ORG> Subject: Re: IPComp question Message-ID: <Pine.BSF.4.31.0102020009250.931-100000@amc.isi.edu> In-Reply-To: <Pine.BSF.4.10.10102011720230.46715-100000@measurement-factory.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, 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 am just curious why IPComp was _relatively_ (and signigicantly) slower than most of the encryption algorithm. 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. regards, yushun. > AFAIK, netperf TCP_STREAM test (and may be others) is extremely > susceptible to network delays. For example, for a fast Ethernet > connection with, say, 30msec packet delay, netperf may show less than > 10Mbits/sec bandwidth instead of the usual 90+Mbits/sec. Clearly, > bandwidth and response times are orthogonal measurements, but netperf > design ties them together. > > Depending on your test environment and purposes, netperf throughput > results may be very misleading. > > $0.02, > > 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.31.0102020009250.931-100000>