Re: benchmarks ... (was: Re: the purpose of fddi mailing list ...

Ed Arnold <> Thu, 29 November 1990 21:05 UTC

Received: from [] by NRI.NRI.Reston.VA.US id aa13911; 29 Nov 90 16:05 EST
Received: Thu, 29 Nov 90 16:03:36 EST from by (5.59/1.6)
Received: from by ncar.ucar.EDU (5.65/ NCAR Central Post Office 04/10/90) id AA29856; Thu, 29 Nov 90 14:03:32 MST
From: Ed Arnold <>
Received: from by niwot.scd.ucar.EDU (5.61/ NCAR Mail Server 04/10/90) id AA16210; Thu, 29 Nov 90 14:03:29 MST
Date: Thu, 29 Nov 90 14:03:25 MST
Message-Id: <>
Received: by (5.61/ NCAR Mail Client 04/19/90) id AA06591; Thu, 29 Nov 90 14:03:25 MST
Subject: Re: benchmarks ... (was: Re: the purpose of fddi mailing list ...
Status: O

Michael Yip ( wrote:

}As a suggestion, if we can come up with certain benchmarks or series of
}benchmarks, then UNH can perform the testing and let everyone know what
}the AVERAGE performance of the equipments.  If the vendor wishes to make
}the benchmark result for that piece of equipment public, then we can 
}start gathering more and more benchmarks...  Just a thought.
}Is UNH listening?

If they are, I hope they'll:

1) Run the ttcp available from, and SPECIFY exactly
   what arguments they used on each end of the connection (unlike some
   vendors ...).
2) If they want to fool around with running some other version of ttcp
   they hacked up, that futzes with window size, fine ... but do that
   in addition to the above.
3) Give us thruput figures for two machines of the same type.  This
   business of presenting a test with multiple machines of differing
   types receiving data, when not everybody is doing it, makes it
   difficult to compare.
4) Run the equivalent of an rcp between machines, but exclude the
   eternal question of `what kind of disks were you running' by
   copying from memory to memory.
5) Run the tests for both TCP and UDP, and don't play games by
   excluding checksumming of UDP packets.