[17359] in Athena Bugs
Re: attach
daemon@ATHENA.MIT.EDU (John Carr)
Sun Nov 7 09:34:38 1999
Message-Id: <199911071424.JAA302045@m4-035-8.mit.edu>
To: Greg Hudson <ghudson@MIT.EDU>
Cc: bugs@MIT.EDU
In-reply-to: "[17258] in Athena Bugs"
Date: Sun, 07 Nov 1999 09:24:54 -0500
From: John Carr <jfc@MIT.EDU>
You replied to my attach bug report:
>> 1. attach should try TCP with a large transfer size before going to
>> UDP with a small transfer size.
>
>This seems more speculative, and requires actual testing and
>performance analysis on all of our platforms (including Linux, these
>days) before we should make the change. So I don't guarantee that it
>will happen any time soon.
My experience with NFS in a variety of environments (including working
on the Digital UNIX NFS code at Compaq) is that larger transfer sizes
are extremely beneficial unless UDP fragment loss becomes a problem.
I just tested an IRIX client writing to bitbucket during a low-use
period (Sunday 9 AM)
(time dd if=/dev/zero of=/mit/bitbucket/jfc/z bs=64k count=100):
block KB/sec
size UDP TCP
1K 122 110
4K 360 354
8K 596 596
16K 599 950
32K 998
When server and client are on different networks TCP is clearly superior.
As long as it is unacceptable to use fragmented packets for NFS, TCP
gives an order of magnitude higher transfer rate. There is some question
about whether TCP is worthwhile within a LAN. DEC decided to leave UDP
as the default because most customers were believed to use NFS within a
network. But as long as attach doesn't have separate options for local
and remote subnets, going to large blocks and TCP is a win in the local
case.
--John Carr (jfc@mit.edu)
