Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!TWG.COM!ljm
From: ljm@TWG.COM
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Distributed File System speed comparisons(was: PC/TCP speed)
Message-ID: <9011281711.aa22418@Mercury.TWG.COM>
Date: 1 Dec 90 06:20:39 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 36

>...I don't consider
>it likely that NFS (an open protocol with end-to-end data checksumming and a
>general purpose machine being used as a fileserver) will ever be as fast as
>the DOS-specific filesharing schemes (lightweight transports, no end-to-end
>checksum, fileserver with optimized disk layout).
>

I'm not so sure.  First of all, we've found that TCP/IP's sophisticated
window management (allowing delayed acknoledgements), average round trip
time
estimation and exponential backoff retransmission algorithms (allowing
relatively fast initial retransmissions on a direct connection), and
dynamic
MTU estimation (allowing full size packets on direct connections) allows
NetBIOS over TCP/IP to ourperform the 'lightweight' NetBEUI protocol stack
by about 20% in PCMAGLAN benchmarks (using LAN Manager).  This disparity
grows much larger if bulk data transfer is the benchmark (the pipe is
always full and every packet wants to be maximum MTU).

Second, in the NFS case, it isn't as if the processing overhead of either
UDP or IP is going to be all that noticeable.  Moreover, using TCPish
retransmission algorithms and 8K or better read/writes yields very good
NFS client performance.

Third, the new special purpose NFS servers (e.g. Auspex) have load
performance
characteristics to be measured in terms of ethernets rather than hosts. 
And, (yes, I know this borders on the religious) given a *reasonable*
implementation
a stateless file server should yield better overall performance than a
connection oriented server.

enjoy,
leo j mclaughlin iii
The Wollongong Group
ljm@twg.com