Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!topaz.rutgers.edu!ron
From: ron@topaz.rutgers.edu (Ron Natalie)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.misc
Subject: Re: Higher speed LANs ?
Message-ID: <12961@topaz.rutgers.edu>
Date: Fri, 26-Jun-87 16:21:23 EDT
Article-I.D.: topaz.12961
Posted: Fri Jun 26 16:21:23 1987
Date-Received: Sat, 27-Jun-87 10:06:02 EDT
References: <541@houxa.UUCP> <8202@utzoo.UUCP>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 22
Xref: mnetor comp.dcom.lans:589 comp.protocols.tcp-ip:459 comp.protocols.misc:102

I think you are wrong to indicate that the sole reason for the slow
effective throughputs is protocols.  The two major problems in UNIX
to day (for either networking or disk access) is IMPLEMENTATION rather
than protocol design problems.  First, there is too much memory to
memory copying in UNIX.  Studies show that much of the disk throughput
is lost through this and the implemenation of IP on UNIX is even worse.
Code is copied from memory to memory three times in UNIX.  None of this
is the fault of the protocol design.

Also bringing up TCP/IP for disk to disk through put is not really relevent.
TCP is designed for streams not disk sectors.  Notice that the datagram
protocols in the DOD suite (e.g. UDP) are used for most of the remote
disk/file system approaches.

As I already pointed out, many computer's I/O systems are where the bottleneck
is currently, especially on micros.  They can't achieve anything near
a megabyte/sec throughput on their interfaces.  This more than anything
else is what is the current bottleneck.  New protocols are inevitable,
especially for higher performance applications, but I don't think we've
run out of performance in the IP protocol suite yet.

-Ron