Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!cs.uoregon.edu!ns.uoregon.edu!milton!uw-beaver!ubc-cs!mprgate.mpr.ca!newshost!morse From: morse@quark.mpr.ca (Daryl Morse) Newsgroups: comp.os.mach Subject: Re: Mach RPC Throughput... Message-ID: Date: 18 Mar 91 19:04:12 GMT References: <9332@star.cs.vu.nl> Sender: news@mprgate.mpr.ca Distribution: comp Organization: MPR Teltech Ltd., Burnaby, BC, Canada. Lines: 80 In-Reply-To: ast@cs.vu.nl's message of 15 Mar 91 20:43:27 GMT In article <9332@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > 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. A number of people both posted, and replied directly, that the MACH RPC runs over UDP/IP. In that light, the comparison was most certainly one of "apples to oranges", but not for the reason given below. Unless I am mistaken, that point was not very clearly indicated in either of the comparisions. It would have been helpful if it was. > 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 According to one posted reply , the difference is a result of the different transport, rather than the fact that an external server is utilized (ie. the transport, not the architecture of Mach). > 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. Perhaps you can post some results of Amoeba RPC throughput over TCP/IP, so we can see an "apples to apples" comparision? That would likely be a more "fair" comparision. > Andy Tanenbaum (ast@cs.vu.nl) I would also like to see an "oranges to oranges" comparision, namely one where the Mach RPC runs over a less-expensive transport, as in the "nrmal (local) case" for Amoeba. One respondent, who asked to be identified only as a "highly placed source" hinted that such a comparision might soon be possible: >However, you might be interested to hear that X-kernel is being >integrated into Mach as a basic, core system component. The new "Mach >network message server" will actually be the X-kernel, ported to Mach. >So, once this is running, I would assume that Mach will run at >X-kernel speeds. Your are correct. I am interested. Perhaps someone is willing to offer some tangible comments on that?? -- Daryl Morse | Voice : (604) 293-5476 MPR Teltech Ltd. | Fax : (604) 293-5787 8999 Nelson Way, Burnaby, BC | E-Mail: morse@quark.mpr.ca Canada, V5A 4B5 | quark.mpr.ca!morse@uunet.uu.net