Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!pt.cs.cmu.edu!andrew.cmu.edu!<UNAUTHENTICATED>+
From: Richard.Draves@CS.CMU.EDU
Newsgroups: comp.os.mach
Subject: Re: Mach performance? [Long]
Message-ID: <QZYJhvu00hYP4Qa1N2@cs.cmu.edu>
Date: 21 Dec 89 22:38:51 GMT
References: <cZYIzoW00jdX4CVWFY@cs.cmu.edu>
Sender: rpd@M.GP.CS.CMU.EDU
Organization: Carnegie Mellon, Pittsburgh, PA
Lines: 20
In-Reply-To: <cZYIzoW00jdX4CVWFY@cs.cmu.edu>

I still don't understand what Sandro's numbers measure, so I won't try
to comment on them.

Excerpts from mail: 21-Dec-89 Re: Mach performance? [Long]
Rick.Rashid@CS.CMU.EDU (1425)

> Actually, Rich is only partly correct.
 
I didn't mention the "short-circuit" path in my brief description of
remote IPC because I don't think it is usable.  It is an experimental
option.  I don't even know if the code would still compile if one turned
on the option.  It certainly isn't in use anywhere.  NeXT tried to put
the short-circuit code into their production system and found it was too
buggy to use; they had to back it out.

I think the short-circuit code was a successful experiment.  The
improved times it produced confirmed that the netmsgserver is a
bottleneck in remote Mach IPC.

Rich