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

[Larry McVoy]

In article <11074 at dog.ee.lbl.gov> JEMilburn at lbl.gov (John Milburn) writes:
>In the referenced article torek at elf.ee.lbl.gov (Chris Torek) writes:
>
>>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.)
>
>There are commercial implementations using Van's alogrithms.  Using an
>hp9000s400 (HP/UX 7.03) connected to a locally connected sun4 (SunOS
>4.1), and using the same method, "get /vmunix /dev/null", I get a
>binary transfer rate of 501 Kbyte/sec or .5 MByte/s.  The hp is using
>header prediction, dynamic window sizing, and Phil Karn's clamped
>retransmission algorithm.

The clustering changes give you a bit better performance (both
ends are sun 4/60's on a local net, the end w/ /h/XXX has
clustering changes.  The reason it doesn't get faster the second
time is that snafu has only 8MB of memory, so much of the file
is reread from disk.)  The interesting thing to note is that the
disk bandwidth (~1.2MB/sec) and the ethernet are closely
matched.  What happens when we consider FDDI and ISDN, the fast
and slow futures of networking?

220 snafu FTP server (SunOS 4.1.1) ready.
ftp> bin
200 Type set to I.
ftp> get /h/XXX /dev/null
200 PORT command successful.
150 Binary data connection for /h/XXX (129.144.50.10,1494) (8388608 bytes).
8388608 bytes received in 11 seconds (7.4e+02 Kbytes/s)
ftp> get /h/XXX /dev/null
8388608 bytes received in 11 seconds (7.6e+02 Kbytes/s)
ftp> quit
script done on Mon Mar 18 19:53:19 1991
---
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm at sun.com