Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!rochester!pt!spice.cs.cmu.edu!rfr
From: rfr@spice.cs.cmu.edu (Rick Rashid)
Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc
Subject: Re: Mach, the new standard?
Message-ID: <1257@spice.cs.cmu.edu>
Date: Mon, 10-Aug-87 15:36:21 EDT
Article-I.D.: spice.1257
Posted: Mon Aug 10 15:36:21 1987
Date-Received: Wed, 12-Aug-87 01:45:58 EDT
References: <1665@ncr-sd.SanDiego.NCR.COM> <8381@utzoo.UUCP> <797@Pescadero.ARPA>
Organization: Carnegie-Mellon University, CS/RI
Lines: 76
Keywords: Mach
Summary: How to get Mach information
Xref: mnetor comp.arch:1783 comp.unix.wizards:3634 comp.os.misc:84

A number of people sent me mail asking me to post an "official" CMU
response to the recent messages about Mach on unix-wizards.  So....


Information about Mach can be obtained by either sending computer mail to
mach@wb1.cs.cmu.edu or by sending US mail to Richard Rashid, 
Dept. of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213.  

We are distributing Mach free of any charge for either commercial or
academic use.  Anyone wishing to receive either VAX or RT PC tapes should
request a license agreement when contacting us at the above addresses.
The VAX tape is structured as an add-on to a generic Berkeley 4.3 
environment.  The RT PC tape is a full system with all necessary software
intended as a strict replacement for anything you may have run on your RT.
Proof of a 4.3 license is required before we can send a tape.  Please keep
in mind that our distribution is primarily intended for systems people who
want to keep abreast of our work or port Mach to their own environments.
We do not yet provide an "end-user" distribution and have very limited
resources to help with problems.

In addition to the VAX and RT versions of Mach, we run Mach on SUNs, 16 CPU
Encore MultiMaxes and on a 26 CPU Sequent Balance here at CMU.  As time goes
on we intend to increase the number of machines we include in our tape
distribution and move away from the notion of an "add-on" tape to a 
complete distribution tape for each machine type.  (The "add-on"
philosophy was the root of the Stanford problem that Tony Mason mentioned
since they had did not have a 4.3 system to add onto.)

With regard to the various netnews messages about Mach posted recently,
interested people should check out the Summer USENIX proceedings.  There
are two articles in it which center on the thread and shared
memory/mapped file mechanisms Mach provides.  There will also be a paper
on Mach VM and multiprocessor support in the October ACM Conference
on Architectural Support for Programming Languages and Operating Systems
(ASPLOS II) and a paper on Mach's external paging facilities in the
November Symposium on Operating System Principles (SOSP 11).

As for benchmarks, the I/O benchmark discussed earlier is really just
a read/write system call performance tester since it does virtually
no disk I/O.  Small differences in system call costs such as those
which may be imposed by tests for remote file systems will
influence the numbers more readily than I/O related system issues.
The papers I mentioned above go into the issue of Mach performance
vs actual I/O costs in some detail.  Just as a point of comparison,
I measured the iocall program on a SUN 160 with a local disk
under Mach and SunOS 3.2. Both support remote file systems and pay some 
penalty for that support.  The results were:

SunOS:	1.7 user	37.2 system	:39 elapsed
Mach:	1.7 user	35.4 system	:38 elapsed

The cost of compiling the program (i.e. cc -O iocall.c -o iocall) was:

SunOS:	1.1 user	1.3 system	:08 elapsed	34% 104+44 io
Mach:	1.1 user	0.9 system	:03 elapsed	55%  13+35 io

There were no other active users in either test case.  

There is no magic to the Mach numbers.  If you performed the test 
immediately after bootup, you would probably get numbers closer to those
of SUN 3.2 both for I/O and for elapsed time. 
The difference in Mach is that it does a much better job
of using the physical memory of the machine to cache disk data and can
save on I/O operations when data has been previous referenced (such as
the text and initialized data of the compiler).  This is particularly
useful when the amount of physical memory is large, the CPU is fast and
the I/O devices are (relatively) slow.  In addition to improving I/O
performance, Mach integrates VM and IPC to allow large (even gigabyte)
messages to be sent between processes using VM techniques.

As was mentioned in a previous netnews note, various companies have picked up
on the kind of VM-I/O integration found in Mach.  Rob Gingell gave a
good presentation on the work SUN is doing in this area at USENIX.
His paper can also be found in the summer USENIX proceedings.  

-Rick