deraadt@cpsc.ucalgary.ca (deraadt) (01/15/91)
In article <5257@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > >(This "ledge" at 8 processes is a feature of SUNOS, and appears on all > >Sun hardware). > > I suspect it's more a feature of the Sun MMU which has, on many > machines, 8 contexts, one of which is used by the kernel and the other 7 > of which are used for user-mode processes; if the job to which you're > switching contexts has a context in the MMU, you can switch address spaces > setting the context register, but otherwise, you have to find a free > context or steal one from another process and load up translations for > that process into that context. This is correct. > Some Sun hardware has more than 16 contexts, and some doesn't have > contexts at all - the Sun-3/80 and Sun-3/4xx have 68030s and use the 3/80 and 3/4xx have 030 in them, but the Sun MMU is used. The motorola MMU is never enabled. The 386i uses the Intel MMU though. > on-chip MMU, not a Sun MMU, and the Sun386i uses the on-chip MMU as well. All Sun4 hardware has at least 16. Sun4/4x0 have 64. > Have you seen this "knee" on Suns without a Sun MMU, and on machines > with a Sun MMU but more than 8 contexts, have you seen the knee at 8 or > so jobs? If not, I suspect it's MMU-related, not SunOS-related > ("SunOS", not "SUNOS", please; in Sun's name, "Sun" isn't an acronym). It is mmu related, but his knee should be higher. I saw the original posting, and was shocked to see that it did not mention which Sun had been tested. A lowely little 4/110 and a 4/490 certainly cannot be classed as giving the same performance. <tdr. -- SunOS 4.0.3: /usr/include/vm/as.h, Line 44 | Theo de Raadt Is it a typo? Should the '_' be an 's'?? :-) | deraadt@cpsc.ucalgary.ca
guy@auspex.auspex.com (Guy Harris) (01/16/91)
>(This "ledge" at 8 processes is a feature of SUNOS, and appears on all >Sun hardware). I suspect it's more a feature of the Sun MMU which has, on many machines, 8 contexts, one of which is used by the kernel and the other 7 of which are used for user-mode processes; if the job to which you're switching contexts has a context in the MMU, you can switch address spaces setting the context register, but otherwise, you have to find a free context or steal one from another process and load up translations for that process into that context. Some Sun hardware has more than 16 contexts, and some doesn't have contexts at all - the Sun-3/80 and Sun-3/4xx have 68030s and use the on-chip MMU, not a Sun MMU, and the Sun386i uses the on-chip MMU as well. Have you seen this "knee" on Suns without a Sun MMU, and on machines with a Sun MMU but more than 8 contexts, have you seen the knee at 8 or so jobs? If not, I suspect it's MMU-related, not SunOS-related ("SunOS", not "SUNOS", please; in Sun's name, "Sun" isn't an acronym).
brandis@inf.ethz.ch (Marc Brandis) (01/16/91)
In article <5257@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >("SunOS", not "SUNOS", please; in Sun's name, "Sun" isn't an acronym). Are you sure that Sun is not an acronym? I remember having heard that SUN comes from "Stanford University Network", a project from which the very first Sun machines were derived. Sorry about posting this here, but it just showed up in this group. Marc-Michael Brandis Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology) CH-8092 Zurich, Switzerland email: brandis@inf.ethz.ch
cleary@husc8.harvard.edu (Kenneth Cleary) (01/16/91)
In article <5257@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >("SunOS", not "SUNOS", please; in Sun's name, "Sun" isn't an acronym). I'm sorry. I know I shouldn't nit-pick, but... :-) I will nit-pick a nit-picker :-) If you read _Sunburst:_The_Ascent_of_Sun_Microsystems_ (by Hall & Barry) I think you'll find that while no one will explicitly admit it, there is a feeling that S.U.N. stands for Stanford University Network, which is what Andy Bechtolsheim built his computer for.
guy@auspex.auspex.com (Guy Harris) (01/17/91)
>3/80 and 3/4xx have 030 in them, but the Sun MMU is used. The motorola >MMU is never enabled. Wrong. The 68030-based Suns do not *HAVE* a Sun MMU on board, except perhaps for the "I/O MMU", which shadows the 68030 MMU in order to fake DVMA. Take a look at "/usr/include/sun3x/vm_hat.h" sometime.... >All Sun4 hardware has at least 16. Sun4/4x0 have 64. Yes, but note that the SS1 has only 8 (it's Sun-4c hardware, not Sun-4 hardware).
henry@zoo.toronto.edu (Henry Spencer) (01/17/91)
In article <21588@neptune.inf.ethz.ch> brandis@inf.ethz.ch (Marc Brandis) writes: >>("SunOS", not "SUNOS", please; in Sun's name, "Sun" isn't an acronym). > >Are you sure that Sun is not an acronym? I remember having heard that SUN >comes from "Stanford University Network", a project from which the very first >Sun machines were derived. "SUN" and "Sun" are not the same thing. "SUN" stood for Stanford University Network, yes... but "Sun" is short for "Sun Microsystems Inc". While I'm sure the similarity is not accidental :-), given that Sun Microsystems was formed basically to commercialize the SUN hardware, the company's name is not an acronym. -- If the Space Shuttle was the answer, | Henry Spencer at U of Toronto Zoology what was the question? | henry@zoo.toronto.edu utzoo!henry
richard@aiai.ed.ac.uk (Richard Tobin) (01/17/91)
I've several times heard about the "knee" in the performance of Suns as
the number of concurrent processes increases, so I wrote a simple
benchmark.
It forks n processes, which then write to each other in a circle of
pipes. Note that all but one process is blocked waiting for input
at any time.
Here are some results. The program is at the end.
Sun 3/75:
The knee is noticeable. Switching rate is about constant for up to 7
processes, then it starts to decline.
2 : 897 switches / second
3 : 862 switches / second
4 : 860 switches / second
5 : 856 switches / second
6 : 851 switches / second
7 : 860 switches / second
8 : 686 switches / second
9 : 650 switches / second
10 : 641 switches / second
11 : 621 switches / second
12 : 621 switches / second
13 : 589 switches / second
14 : 597 switches / second
Sun 3/260:
Similar but more severe.
2 : 1626 switches / second
3 : 1648 switches / second
4 : 1587 switches / second
5 : 1543 switches / second
6 : 1474 switches / second
7 : 1431 switches / second
8 : 876 switches / second
9 : 608 switches / second
10 : 632 switches / second
11 : 618 switches / second
12 : 598 switches / second
13 : 560 switches / second
14 : 577 switches / second
Sparcstation 1:
Rather variable, gets very slow above 8 processes.
2 : 1971 switches / second
3 : 1944 switches / second
4 : 1944 switches / second
5 : 1092 switches / second
6 : 1892 switches / second
7 : 1184 switches / second
8 : 835 switches / second
9 : 416 switches / second
10 : 396 switches / second
11 : 396 switches / second
12 : 379 switches / second
13 : 359 switches / second
Sun 4/470:
No obvious knee.
2 : 4228 switches / second
4 : 4537 switches / second
6 : 4370 switches / second
8 : 4215 switches / second
10 : 4134 switches / second
12 : 3807 switches / second
14 : 4020 switches / second
16 : 4013 switches / second
18 : 3998 switches / second
20 : 3922 switches / second
22 : 3465 switches / second
24 : 3737 switches / second
26 : 3541 switches / second
28 : 3448 switches / second
30 : 3644 switches / second
32 : 3598 switches / second
34 : 3563 switches / second
36 : 3500 switches / second
-- Richard
/* see how fast we can switch between processes */
#include <stdio.h>
#include <sys/time.h>
int master = 1;
int from, to;
main(argc, argv)
int argc;
char **argv;
{
int one_to_two[2], n_to_1[2];
int iter, procs, reads = 0, pid;
static char buf[] = "x";
struct timeval tp1, tp2;
procs = atoi(argv[1]);
iter = argc > 2 ? atoi(argv[2]) : 100;
pipe(one_to_two);
pipe(n_to_1);
from = n_to_1[0];
to = one_to_two[1];
make_child(procs-1, one_to_two, n_to_1[1], n_to_1[0]);
pid = getpid();
if(master)
write(to, buf, 1);
gettimeofday(&tp1, (struct timezone *)0);
while(1)
{
switch(read(from, buf, 1))
{
case -1:
perror("read");
exit(1);
case 0:
#ifdef DEBUG
printf("process %d exiting after %d reads\n", pid, reads);
#endif
if(master)
{
double sec;
gettimeofday(&tp2, (struct timezone *)0);
sec = (tp2.tv_sec - tp1.tv_sec) +
(tp2.tv_usec - tp1.tv_usec) / 1e6;
printf("%d switches / second\n", (int)(procs*iter/sec + 0.5));
}
exit(0);
case 1:
reads++;
#ifdef DEBUG
printf("process %d read %c\n", pid, buf[0]);
#endif
if(master && reads == iter)
close(to);
else
write(to, buf, 1);
}
}
}
make_child(n, parentpipe, lastwriter, closeme)
int n, parentpipe[2], lastwriter, closeme;
{
if(fork() == 0)
{
/* child */
master = 0;
close(parentpipe[1]);
close(closeme);
from = parentpipe[0];
if(n == 1)
/* This is the last process */
to = lastwriter;
else
{
int p[2];
pipe(p);
to = p[1];
make_child(n-1, p, lastwriter, from);
}
}
else
{
close(parentpipe[0]);
close(lastwriter);
}
}
--
Richard Tobin, JANET: R.Tobin@uk.ac.ed
AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobindatran2 (01/17/91)
I just tried Richard Tobin's little context switch benchmark on my NeXT 68040 which was relatively quiessant with 46 active pids consuming 2% of cpu as a base. The NeXT seems to be pretty stable as far as context switches go. 3 : 1460 switches / second 4 : 1460 switches / second 5 : 1448 switches / second 6 : 1393 switches / second 7 : 1404 switches / second 8 : 1393 switches / second 9 : 1362 switches / second 10 : 1341 switches / second 11 : 1333 switches / second 12 : 1327 switches / second 13 : 1335 switches / second 14 : 1325 switches / second 15 : 1307 switches / second 16 : 1321 switches / second 17 : 1313 switches / second 18 : 1310 switches / second 19 : 1309 switches / second 20 : 1317 switches / second 24 : 1276 switches / second 28 : 1289 switches / second 32 : 1280 switches / second 36 : 1280 switches / second Steve. -- #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====# # Steve Boker # "Badgers, we don't have no stinking badgers" # # datran2!smb@csn.org # -from Treasure of the Sierra Madre Zoo # #====#====#====#====#====#====#====#====#====#====#====#====#====#====#====#
tomw@binkley.Eng.Sun.COM (Tom Westberg) (01/17/91)
In article <1991Jan16.231017.2530@csn.org!datran2> smb@csn.org!datran2 writes: > >I just tried Richard Tobin's little context switch benchmark on my >NeXT 68040 >3 : 1460 switches / second . . >36 : 1280 switches / second And I just tried it on my SPARCstation2 (4/75) running a few window systems, but not much else: 2: 4243 switches / second 3: 4140 switches / second 4: 4022 switches / second 5: 4088 switches / second 6: 4048 switches / second 7: 3881 switches / second 8: 3755 switches / second 9: 3615 switches / second 10: 3612 switches / second 11: 3653 switches / second 12: 3568 switches / second 13: 3548 switches / second 14: 3523 switches / second 15: 3381 switches / second 16: 1966 switches / second 17: 1908 switches / second 18: 1929 switches / second As you can see, it falls off bigtime at 16. SunOS reserves one of the contexts (number zero) exclusively for DVMA, which is why it doesn't fall off at 17. Tom Westberg tomw@eng.sun.com
mash@mips.COM (John Mashey) (01/18/91)
In article <3956@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >I've several times heard about the "knee" in the performance of Suns as >the number of concurrent processes increases, so I wrote a simple >benchmark. >Sun 4/470: > >No obvious knee. >36 : 3500 switches / second As I recall, the 4[79]0s have 64 contexts, hence knee at 64. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
amir@smsc.sony.com (Amir 806) (01/19/91)
One word of warning. One has to be careful in using the benchmark as the
speed of context switches. It uses pipes which have been implemented with
varying degrees of efficiencies on different versions of Unix.
It is however, an excellent test of the of the number of contexts
a system can handle with best efficiency (as the author intended).
--
Amir H. Majidimehr
Operating Systems Group
Sony Microsystems
amir@sony.com | ...!{uunet,mips}!sonyusa!amirroot@lingua.cltr.uq.OZ.AU (Hulk Hogan) (01/22/91)
CCHD@lure.latrobe.edu.au (Huw Davies - La Trobe University Computer Centre) writes: >In article <3964@skye.ed.ac.uk>, richard@aiai.ed.ac.uk (Richard Tobin) writes: >> In article <3956@skye.ed.ac.uk> I wrote: >>>It forks n processes, which then write to each other in a circle of pipes. >>>Here are some results. >> Here are some more: >Here are (somewhat exhaustive results for a RS/6000-540 with 64Mb of >memory and no significant users). [...] >Procs: 1 - 306 switches / second >Procs: 2 - 2671 switches / second >Procs: 3 - 2391 switches / second >Procs: 4 - 1961 switches / second >Procs: 5 - 1939 switches / second [...] >Procs: 20 - 1964 switches / second [...] >Procs: 30 - 1947 switches / second [...] >Procs: 80 - 1795 switches / second [...] >Procs: 98 - 1742 switches / second >Procs: 99 - 27145 switches / second >Procs: 100 - 26898 switches / second >Procs: 101 - 27345 switches / second [...] Wow! Richard should sell his benchmark program to IBM or Intel! :-) Here's the results on a pretty idle Solbourne 5/601 in multiuser mode (33MHz SPARC, 16MB RAM, SunOS 4.0.3, Compiled with -O). The shell script I used is included for completeness after the results. There doesn't appear to be a knee that I can see. -------------------- cut here -------------------- Context Switch "knee" test. Machine: lingua. Architecture: sun4 Series5 Date: Tue Jan 22 08:43:55 EST 1991 Uptime: 8:43am up 22 mins, 1 user, load average: 1.24, 1.16, 0.80 N Output of knee N. 2 2857 switches / second 3 2308 switches / second 4 2222 switches / second 5 1852 switches / second 6 1875 switches / second 7 1667 switches / second 8 1778 switches / second 9 1698 switches / second 10 1667 switches / second 11 1507 switches / second 12 1818 switches / second 13 1970 switches / second 14 1867 switches / second 15 1667 switches / second 16 1839 switches / second 17 1868 switches / second 18 1782 switches / second 19 1520 switches / second 20 1653 switches / second 22 1618 switches / second 24 1509 switches / second 26 1793 switches / second 28 1795 switches / second 30 1657 switches / second 32 1975 switches / second 34 1659 switches / second 36 1706 switches / second 40 1762 switches / second 50 1534 switches / second 60 1579 switches / second 61 1690 switches / second 62 1562 switches / second 63 1507 switches / second 64 1693 switches / second 65 1693 switches / second 66 1692 switches / second 70 1493 switches / second 80 1572 switches / second Date: Tue Jan 22 08:45:09 EST 1991 Uptime: 8:45am up 23 mins, 1 user, load average: 15.20, 5.65, 2.72 -------------------- cut here -------------------- The shell script I used to run the benchmark was... -------------------- cut here -------------------- #!/bin/sh # run the knee benchmark cc -O -o knee knee.c echo "Context Switch \"knee\" test. Machine: `hostname`. Architecture: `arch` `arch -k`" > results echo "Date: `date`" >> results echo "Uptime: `uptime`" >> results echo >> results echo "N Output of knee N" for i in 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 22 24 26 28 30 32 34 36 40 50 60 61 62 63 64 65 66 70 80 do /bin/echo -n "$i " >> results knee $i >> results done echo >> results echo "Date: `date`" >> results echo "Uptime: `uptime`" >> results -------------------- cut here -------------------- /\ndy -- Andrew M. Jones, Systems Programmer, Internet: andy@lingua.cltr.uq.oz.au Centre for Lang. Teaching & Research, Phone (Australia): (07) 365 6915 University of Queensland, St. Lucia, Phone (World): +61 7 365 6915 Brisbane, Qld. AUSTRALIA 4072 Fax: +61 7 365 7077 "No matter what hits the fan, it's never distributed evenly....."
richard@aiai.ed.ac.uk (Richard Tobin) (01/22/91)
In article <4972@lure.latrobe.edu.au> CCHD@lure.latrobe.edu.au (Huw Davies - La Trobe University Computer Centre) writes: >PS I doubt the answers for > 100 processes.... The code was hacked up on the spot and lacks any checks for pipe() and fork() failing. Once the process or file table fills up, results will be nonsense. >Procs: 1 - 306 switches / second The one process case is of course meaningless, and the code doesn't check for it. As has been pointed out, the program is as much a test of piping as of switching between processes. Remember that its purpose was to find a knee in the results, not make absolute measurements. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
amos@SHUM.HUJI.AC.IL (amos shapir) (01/22/91)
Since this argument started with the RS6000, here are the results: 2: 1406 switches / second 3: 1668 switches / second 4: 1532 switches / second 5: 1345 switches / second 6: 1423 switches / second 7: 1398 switches / second 8: 1398 switches / second 9: 1439 switches / second 10: 1394 switches / second 11: 1441 switches / second 12: 1185 switches / second 13: 1384 switches / second 14: 1297 switches / second 15: 1385 switches / second 16: 1349 switches / second 17: 1311 switches / second 18: 1251 switches / second 19: 1243 switches / second 20: 1271 switches / second I don't know if anyone has done it yet, we seem to have been cut off news since the war broke out (but mail still works fine). -- Amos Shapir amos@shum.huji.ac.il The Hebrew Univ. of Jerusalem, Dept. of Comp. Science. Tel. +972 2 584385 GEO: 35 14 E / 31 46 N city
moliver@shadow (Mike Oliver) (01/23/91)
In article <3964@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: > >Jim Reid sent me results from a 4-processor Sequent symmetry. The results >show a remarkably slow decline (or perhaps, the Sun ones are rather fast). I suspect that the Sun decay is rather fast, but that's an understandable feature of the memory management philosophy on a machine built for a small number of users. Doesn't seem to have hurt their sales much :-) >Perhaps this is due to the multiple processors. More likely due to the behaviour of the cache and MM subsystem. > [Symmetry results elided.] Figures for a single-CPU Pyramid MIServer (running a multi-CPU kernel, so there's some semaphore overhead in here) and for a 4-CPU MIServer, are: # processes single CPU 4 CPU 2: 2000 2000 switches / second 4: 1846 1846 switches / second 6: 1895 1800 switches / second 8: 1846 1846 switches / second 10: 1818 1818 switches / second 20: 1765 1765 switches / second 30: 1731 1748 switches / second 40: 1667 1752 switches / second 50: 1631 1714 switches / second 60: 1579 1706 switches / second 70: 1597 1641 switches / second 80: 1584 1673 switches / second 90: 1561 1657 switches / second 100: 1600 1681 switches / second 120: 1545 1655 switches / second 140: 1530 1606 switches / second 160: 1569 1624 switches / second 180: 1506 1607 switches / second 200: 1540 1594 switches / second These are on "idle" (not dedicated, but not much else going on) machines in multi-user mode, using the default number of 100 messages through the ring of pipes in Richard Tobin's benchmark. Sending 2000 messages around the ring to establish a steady state improves these figures uniformly by about 200, or between 10 and 13 per cent. Cheers, Mike. moliver@pyramid.com {allegra,decwrl,hplabs,munnari,sun,utai,uunet}!pyramid!moliver
pcg@cs.aber.ac.uk (Piercarlo Grandi) (01/23/91)
On 21 Jan 91 09:06:18 GMT, magnus@rhi.hi.is (Magnus Gislason) said: In article <2653@krafla.rhi.hi.is> magnus@rhi.hi.is (Magnus Gislason) writes: magnus> In <6123@exodus.Eng.Sun.COM> tomw@binkley.Eng.Sun.COM (Tom magnus> Westberg) writes: tomw> And I just tried it on my SPARCstation2 (4/75) running a few tomw> window systems, but not much else: tomw> 2: 4243 switches / second tomw> [ ... ] tomw> . tomw> 15: 3381 switches / second tomw> 16: 1966 switches / second tomw> [ ... ] magnus> And for the IBM RS 6000/320. magnus> 2: 1722 switches / second magnus> [ ... ] magnus> 25: 1192 switches / second magnus> The IBM RS 6000 doesn't seem to be very fast at context magnus> switching in comparison with other machines. Frankly, this benchmark is about the *shape* of the context switch curve (given some specific sequences of schedules), which is largely a function of the MMU architecture. The context switch *performance* instead is a critical function of how badly botched is the scheduler, usually, and the MMU architecture has a minimal influence. Above we see that context switches cost (on implementations that can do 20-30 million native instructions per second) from a few thousand to over a dozen thousand instructions, which is well over the few dozen or few hundred it takes to save and reload CPU, FPU and MMU contexts. So be warned: in the above you are largely comparing the schedulers, not the MMUs, if you look at switch *rates*. Under most Unix kernel implementations the scheduler is invoked on every context switch, to determine which process should run next. This in itself is incredibly inane, even worse, the traditional implementation of Unix kernel signaling means that unless special care has been taken (and very few take care) the entire process table has to be scanned linearly by the scheduler as soon as it is invoked just to discover which processes are runnable. The combined effect is that the scheduler overhead is of the order of *twenty* times the cost of the context switch. In the original PDP-11 Unix Kernel implementation both design choices made some good sense; very few processes around, most strongly IO bound (shells, editors, ...), a few strongly CPU bound (nroff, chess, compiles, ...), process table not larger than a handful of dozen entries. Also, the Unix designers said they had gone for simplicity over efficiency. On contemporary machines the same tradeoffs no longer make sense at all, just like expansions swaps or caching entire page tables. Now let's context switch back to AIX/6000: its kernel implementation has no relationship whatever with that of traditional Unix, supposedly. I would be very suprised if it had to do a process table scan on every reschedule or on every wakeup(). It must have some other bogosity. It is amusing to note that it is not difficult to reduce to insignificance rescheduling overheads: like in MUSS one can split the scheduler into a short term scheduler that manages a runnable set of a fixed number of processes (say 16 or 32), using some simple rule like strict priority of FIFO, and a medium term scheduler that determines which process should be in the runnable set. This means that policy calculations have to be made only by the medium term scheduler and invoking the short term scheduler will cost little more than the hardware switching overhead. Once you are on this path, a multithreaded, multiprocess kernel suddendly becomes a distinct possibility. Now back to our regularly scheduled :-) register/optimizer/pager/MMU debates. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
moliver@shadow (Mike Oliver) (01/23/91)
In article <3987@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >In article <4972@lure.latrobe.edu.au> CCHD@lure.latrobe.edu.au (Huw Davies - La Trobe University Computer Centre) writes: >>PS I doubt the answers for > 100 processes.... > >The code was hacked up on the spot and lacks any checks for pipe() and >fork() failing. Once the process or file table fills up, results will >be nonsense. This is true; before I put error checking into my copy I was getting upwards of 100 million switches per second with large numbers of processes. I was impressed :-) >-- Richard Mike. moliver@pyramid.com {allegra,decwrl,hplabs,munnari,sun,utai,uunet}!pyramid!moliver