🚀 go-pugleaf

In article <MORSE.91Mar14091659@quark.mpr.ca> 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)