From: eengelke@sail.uwaterloo.ca (Erick Engelke)
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans.ethernet
Subject: Re: Sun <=> PC Transfer Rate (Summary)
Date: 10 Sep 92 16:45:00 GMT
Organization: University of Waterloo

karl@empirical.com (Karl Auerbach) writes:
> tgl@ssd.kodak.com (Tom Lathrop) writes:
>>I was asked to summarize the responses to my query about optimizing
>>Sun to PC file transfer.
>
>And if you use TCP with the new window extension mechanisms you can get
>much better throughput.  However, I don't know any PC code that uses those 
>yet.

The closest I know of is my own FTP which uses up to 32K transmit window.
I kept the receive window small so that people wouldn't be conjesting 
long haul networks.  I know that seems counter productive, but my own
site is sufferring badly from saturated connections...  

>
>There is also a substantial difference depending on the latency and error 
>rate of the network.  If you are going through routers and over the internet 
>you can see a major difference between NFS and TCP file transfer rates.
>
>But the #1 absolute most important factor is the speed of the disk.
>

My PC FTP runs the disk and network concurrently (on large files) so it 
will typically be very much limited to the slower of the source or sink,
namely the disk.  Many of the commercial PC TCP implementations also 
provide this sort of design with varied results.

>I routinely get 2megabit FTP transfers from a Sun Sparc 2 to a wimpy
>16mhz 386sx box with an 8 bit WD board and packet driver.... as long as the 
>destination is NUL:  (Software is PC/TCP v2.1)
>
>I've gotten as high as 5megabits/second using a 50Mhz 486DX box with a 16 
>bit WD board using the same software and packet driver.

That is about the limit of the current ISA ethernet hardware and packet
drivers.  3Com's new (unreleased) cards should up that by 25% to 50%.
On a different ISA network card we get 850 KB/s, but you really start
hitting the hardware bus limitations.
 
>
>> The CPU is probably not critical,
>
>CPU *is* critical.  One of the big bottlenecks is checksum calculation.
>(I do hope that whoever measured the Sun NFS speed did it with checksums 
>turned on -- Sun workstations run with UDP checksums OFF by default.)
>

Not on a modern system.  Times vary greatly, but my desktop 386-33 can
checksum 24 MB/s, so it's an overhead of about 2%.  Variance due to
network conjestion and clock accuracy far outweigh the effects of 
checksumming when done optimally.  

But you raise the point of whether or not it is implemented efficiently,
that 24 MB/s figure is using 32 bit code.  Optimal 16 bit code is much
slower, and typical (less optimized) 16 bit code is slower still.

>
>>software side, a couple of people said that if a packet driver is used,
>>which one it is makes a big difference.
>
>I've sent over 2500 packets per second through packet drivers.  And that 
>was on a 12mhz 286.  Of course, that was a special test designed to
>load the network.

For SMC cards, the SMC packet driver is much faster than the CRYNWR packet
driver, but not as reliable on fast hardware.  If you want to see how
many packets/s your packet driver can do, ftp to sunee.uwaterloo.ca
and get pub/wattcp/speed.zip.  Please don't use it on a production network,
use a test segment instead.

Erick
-- 
Erick Engelke					  Engineering Computing
						 University of Waterloo
Waterloo TCP Architect		 erick@development.watstar.uwaterloo.ca
Newsgroups: comp.protocols.nfs,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans.ethernet