----- Original Message ----- From: "Alan Cox" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 03, 2004 12:04 PM Subject: Re: Did some extensive hipersocket testing/benchmarking.... need help interpreting results.
> On Gwe, 2004-05-28 at 20:04, James Tison wrote: > > FTP is a __TERRIBLE__ benchmark. Remember that besides network > > bandwidth, other factors that might introduce latency are things > > like OS scheduling delays/timeslicing on both client and server > > ends, disk I/O delays on both ends, etc; _not_to_mention_ TCP > > SYN/ACK traffic, possible retransmissions, packet fragmentation > > and reassembly, etc. > > I must disagree. Strongly. > > Lets remove the bullshit first > > TCP SYN/ACK - sequene of 3 packets SYN / SYN|ACK / ACK at the start > of the transfer. Irrelevant for larger pakets > > Packet fragmentation/reassembly. Linux uses TCP MTU discovery doesn't > occur. Also there is no router in the middle so doesn't occur. > Irrelevant > > Retransmissions: These are part of the link performance and tell you > about the quality of the network stacks and also the variability of the > link performance and re-ordering. Important real world data. > > The disk to disk aspect is distorting but he's using similar tests for > each case. In many case disk to disk is the right way to test anyway, > its what you actually do in the real world. ttcp can do similar testing > without the disk layer being involved if that matters. > > > think that a typical LAN routing latency of 4-6 ms is a big deal, > > but the more packets that get sent (and ACKed), the more _any_ > > latency will hurt your final net throughput value. We're talking > > about possibly thousands of packets, and nK * X ms = seconds, > > at least. > > For TCP the cwnd will be large for a high latency link. You can play > with buffer sizes here (and my guess is that this may be precisely the > problem IBM's stack has, although you'd need to review traces) > > > The trouble with ICMP based performance testing is that > > 1. Modern stacks will rate limit icmp replies as per RFC recommendations > 2. You are measuring how fast you can stuff data down a pipe not how > fast you can process stream data. That means the benchmark doesn't tell > you a lot other than that you bought gigabit ethernet. > > Generally I don't care how fast my pipe is I care how fast I can move > data over it. > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
