Path: utzoo!news-server.csri.toronto.edu!rutgers!sun-barr!lll-winken!uunet!mcsun!hp4nl!star.cs.vu.nl!ast From: ast@cs.vu.nl (Andy Tanenbaum) Newsgroups: comp.os.mach Subject: Re: Mach RPC Throughput... Message-ID: <9332@star.cs.vu.nl> Date: 15 Mar 91 20:43:27 GMT References: Sender: news@cs.vu.nl Distribution: comp Organization: Fac. Wiskunde & Informatica, VU, Amsterdam Lines: 39 In article morse@quark.mpr.ca (Daryl Morse) writes: >My question is simple, though its answer likely is not: Why is the >throughput of the Mach RPC so much slower than the other OSes? Are the >respective RPCs different enough that throughput is a meaningless >"apples and oranges" comparision? Has the Mach RPC simply not been >optimized as heavily as that of the other OSes? I am sure Rick can give the definitive answer for Mach, but I can speak for Amoeba, and I think by implication for some of the others. An RPC in Amoeba follows the following path: 1. User process issues an RPC system call and traps to the kernel 2. Kernel mucks about with headers and sends a packet to the dest CPU 3. Dest kernel unmucks the headers and passes the packet to the user 4. User inspects the packet and traps to the kernel to send reply 5. More muck, another packet sent 6. Src machine gets the reply packet and passes it back to the user These 6 steps take 1.1 msec on a Sun 3/60. The protocol used on the Ethernet is a straightforward protocol we have designed. It is not IP. No external servers of any kind are involved. I believe that Mach involves external servers in the process, which of course is fatal for the performance. Thus we are comparing apples to apples. From the user's viewpoint, what is being measured is the time to send a message from itself as client to a remote server over the Ethernet, and get the reply back. Nevertheless, Amoeba processes can speak TCP/IP when desired. There is an external TCP/IP server available. To speak TCP/IP, a client does an RPC with the TCP/IP server and effectively says: "Please send this data as an IP packet to such and such an IP address." This gives full connectivity with the Internet, but also means that the normal (local) case goes much faster. The loss of performance when going through the TCP/IP server is not so important because usually the TCP connections go over a narrow-band wide-area link anyway, so there is no way to get high-performance no matter what. In essence, we have chosen to optimize the local case, and accepted worse performance when one specifically wishes to speak TCP/IP. I believe that Mach has chosen to do things differently. Andy Tanenbaum (ast@cs.vu.nl)