Alex Rousskov wrote:
> On Mon, 5 Feb 2001, Rick Jones wrote:
> > > Netperf ties response time and throughput and, hence, cannot show
> > > meaningful throughput measurements in environments with packet delays.
> > Huh? Are you refering to the synchronous nature of the netperf TCP_RR
> > test? If so, then it was _inteneded_ to show the delay and was not
> > intended as a throughput measurement.
> I was actually talking about the [default] TCP_STREAM test.
> I had no intention to somehow pummel the test or the netperf tool
> itself! I was just pointing out that the default TCP_STREAM test will
> not show real raw throughput on a link with packet delays.
Netperf TCP_STREAM test with no other parms will take the system's
defaults for socket buffer and thus window sizes. It might be more
accurate to state then that the system's default values are inapropriate
for situations with large delays :)
> If there are more appropriate netperf tests/parameters that should be
> used in an environment with delays, please let me know! The defaults
> were sufficient for our limited tests, but we are always happy to
> improve the methodology.
Well, since one of the limits to the throughput of a TCP connection is
the window size divided by the round-trip-time, adding -S and -s parms
that are the desired bandwidth*RTT would probably be in order :)
-- ftp://ftp.cup.hp.com/dist/networking/misc/rachel/ these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but please do NOT do BOTH... my email address is raj in the cup.hp.com domain...
This archive was generated by hypermail 2b29 : Tue Jul 10 2001 - 12:00:17 MDT