Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!elroy.jpl.nasa.gov!aero!trwind!msd
From: msd@trwind.UUCP (Marc S. Dye )
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Revision of PC/IP scorecard
Message-ID: <561@trwind.UUCP>
Date: 2 Aug 89 18:33:56 GMT
References: <89Jul19.080735edt.57368@ugw.utcs.utoronto.ca>
Reply-To: msd@TRW.Com (Marc S. Dye (ayuda))
Organization: ayuda Company,  Camarillo CA
Lines: 22


Might I add the suggestion that the data regarding performance list a
Norton number for the PC processor (host-side for 'smart' implementations).
Also, a footnote indicating the configuration of the PC/IP host used and
that of the peer it was talking to.

ASCII vs. BINARY mode FTP transfer data might also be nice.  There are
some drastic performance differences between these in many implementations.

Bi-directionality is also a possible performance issue.  If you expect
anything but the best value for either direction, that should noted.

Finally, I should like to point out that there are some implementations
around which take much license with the performance statistics their FTP
client interfaces report.  The numbers should really report the total
time it takes the data to actually sink to the destination medium (usu.
RAMdisk for these sorts of tests);  data thrown over the wall to TCP
shouldn't count.  A good way to ameliorate this effect is to require a
LARGE file transfer (> a few Megs).

++msd -- msd@TRW.Com -- Marc S. Dye (ayuda Company)
1393 Stonemeadow Ct.;  Camarillo, CA;  93010;  USA;  (805)987-0433