From owner-freebsd-net Fri Feb 2 0:21:20 2001 Delivered-To: freebsd-net@freebsd.org Received: from amc.isi.edu (amc.isi.edu [128.9.160.102]) by hub.freebsd.org (Postfix) with ESMTP id B465537B491 for ; Fri, 2 Feb 2001 00:21:02 -0800 (PST) Received: from localhost (yushunwa@localhost) by amc.isi.edu (8.11.1/8.11.1) with ESMTP id f128KUH00943; Fri, 2 Feb 2001 00:20:31 -0800 (PST) (envelope-from yushunwa@amc.isi.edu) Date: Fri, 2 Feb 2001 00:20:30 -0800 (PST) From: Yu-Shun Wang To: Alex Rousskov Cc: 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 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