🚀 go-pugleaf

In article <9332@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:

>   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.

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 <bill@cs.columbia.edu (Bill Schilit)>,
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