bpw@csadfa.oz.au (Brendan Williams) (04/13/88)
After such a criptic subject heading, all I am after is any information comparing the overheads of TCP and UDP. My honours year project is looking at InterProcess Communication for Distributed Operating Systems, and how to minimize the overheads (on an Ethernet 10M) while allowing the network to talk to UNIX (running on a Pyramid 90X) and allow for reliable (in some cases) communication. Any further advice / information would be helpful. You may reply by e-mail, or via the net if you feel the information would be of some use elsewhere. THANK YOU. ---- Mr. Brendan Williams, Phone ISD: +61 62 688154 Fax: +61 62 470702 Dept. Computer Science, Telex: ADFADM AA62030 University College, UNSW, ACSNET/CSNET: bpw@csadfa.oz Aust. Defence Force Academy, UUCP: ...!uunet!munnari!csadfa.oz!bpw Canberra. ACT 2600. ARPA: bpw%csadfa.oz@uunet.uu.net AUSTRALIA JANET: bpw@oz.csadfa Other Gateways: see CACM 29(10) Oct. 1986 Any opinion shown is soley my own.
gillies@uiucdcsp.cs.uiuc.edu (Gillies) (04/15/88)
Here are some interesting papers to read: 1. "Implementing Remote Procedure Calls", ACM TOCS (1984, I believe). Investigates the limits of tuning a datagram-type protocol for implementing remote procedure calls on 3Mbps Ethernet / Dorado computer. The authors use some very hardware and protocol-specific tricks. 2. "Gaining Efficiency through Appropriate Choices in Network Protocol Design and Implementation", ACM TOCS (1986 -- not sure about entire title). This paper talks about how to get high performance without modifying the protocol, your ethernet hardware, or specializing your O/S. It is the opposite of paper (1). 3. It's very hard to compare the overheads of TCP and UDP, because the protocol designs are almost NEVER the bottleneck (it's usually the O/S implementation or ethernet hardware). Most modern operating systems (e.g. UNIX) are horribly bad places to implement an efficient protocol. If you don't believe me, you should hear the talk: "Why Computer Networks DontGoFast!" by D.D. Clark, M.I.T. Lab for C.S. They have developed a TCP implementation capable of sustaining 1.1 megabits/sec of on a PC-AT. Currently, the implementation spends 60% of its time nursing the inefficient 3COM ethernet board, and would go faster with better hardware. One exception to the "Don't blame the protocols" rule is satellite communication: The MIT group has developed new protocol called NetBlt to deal with its latency problems: It has been clocked at 1.3-1.4 Mbps on a PC-AT.
rsalz@bbn.com (Rich Salz) (04/16/88)
If you rummage through a set of TCP-IP archives, you'll find a note that Van Jacobson of LBL and Mike Karels of UCB have got a TCP for 4.3BSD that runs at about 8megabips, while only consuming a real small fraction of the CPU cycles. You don't need netblt, off-board or other tricks to get a mechanism good enough for IPC; you just need to do some hard engineering. /rich $alz -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.