NFS vs communications meduim (was slashes, then NFS devices)

[Chris Torek]

>In <11030 at dog.ee.lbl.gov> I wrote:
>>The bandwidth of your standard, boring old Ethernet is 10 Mb/s or 1.2
>>MB/s.

In article <2028 at bacchus.esa.oz.au> david at bacchus.esa.oz.au
(David Burren [Athos]) writes:
>Say what?  If you can get over 1 Mb/s out of an Ethernet I'd like to hear
>about it.

You just did. :-)

Van Jacobson regulary gets around 1 MB/s (8 Mb/s) on Sun-3 (68020) boxes.
4.3BSD-reno (a much less carefully tuned system than Van's) running on a VAX
8250 with a DEUNA, talking to an Encore Multimax running UMax 4.3, receives
data inside FTP at 130 kb/s or just a bit over 1 Mb/s.

(I used `get /vmunix /dev/null' to get this number.  Note that this depends
on the rate at which the remote machine can generate data for you.)

>As a simple test, on a barely-loaded Ethernet (5 Sony workstations, with two
>people running vi) I ftp'ed a >400k file from one machine to another.
>Local SCSI disk to local RAM disk.  No NFS involved.  The transfer rate I
>got was was 94 kbytes/s.

(You may have forgotten to use binary mode.)

>>The bandwidth of your standard, boring old SCSI disk without
>>synchronous mode is around 1.5 MB/s.

>Using the bonnie filesystem-benchmark on our local SCSI disks shows writes
>ranging from 200 kb/s (for char-by-char) to >600 kb/s (block I/O) and reads
>from 150 kb/s (character) to >600 kb/s (block).
>This is with Wren-IV's and M9380S's using asynchronous SCSI.  Note that
>bonnie measures *through-the-filesystem* performance.

Yes, these numbers are fairly typical (you lose half the bus performance
in the file system code: something else that needs tuning: see Larry McVoy's
paper from the last Usenix for one approach).

>>A good TCP implementation, on the other hand, squeezes about 1.1 MB/s
>>out of the Ethernet even when talking to user code ...

>Could you please refer me to such a TCP implementation?
>The figures I've quoted above were on Sony NEWS-1750 workstations, running
>NEWS-OS 3.3a (basically 4.3BSD-Tahoe, I believe).

4.3-tahoe lacks the `header prediction' code that appears in 4.3-reno.
4.3-reno lacks Van's latest changes (though said changes are likely to
be in 4.4BSD, if/when 4.4BSD exists).

Only those who work on NEWS-OS could say for certain which performance
fixes are in it.  Also, much depends on the bus design and the code for
the Ethernet driver.  It is important to avoid data copies; many
existing implementations copy a packet just so they can insert headers,
even though it is easy to arrange for space for those headers `in
advance'.  It is also important to avoid long code paths for typical
cases (e.g., the `header prediction' stuff that went into 4.3-reno,
and the route cacheing stuff; I think the latter has been around longer).
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov