Path: utzoo!dciem!nrcaer!scs!spl1!laidbak!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!oliveb!pyramid!voder!lynx!m5
From: m5@lynx.UUCP (Mike McNally)
Newsgroups: comp.unix.wizards
Subject: Re: Vax 11/780 performance vs Sun 4/280 performance
Message-ID: <3859@lynx.UUCP>
Date: 3 Jun 88 23:59:15 GMT
Article-I.D.: lynx.3859
References: <14968@brl-adm.ARPA> <601@modular.UUCP> <7331@swan.ulowell.edu> <2282@rpp386.UUCP>
Reply-To: m5@lynx.UUCP (Mike McNally)
Organization: Lynx Real-Time Systems Inc, Campbell CA
Lines: 29
Summary: My $.02

Re: small processes that sleep-wakeup-sleep-wakeup...

I tried this on my Integrated Solutions 68020 thing and got results
similar to those of the Sun; that is, up to about 6 or 7 of them the
system works fine, but after that everything gets real slow (I can't
test it too much because everybody gets mad here when the machine
freezes up).

I tried the same thing under LynxOS, our own BSD-compatible real-time
OS, and didn't notice very much degradation at all.  A major difference
between our machine and the Integrated Solutions is the MMU: even
though our platform is a 68010, our MMU is 16K of static RAM that holds
all the page tables all the time.  Context switch time is thus real
small.  Also, I think it's possible that the mechanism for dealing with
the timeout in select() is different internally under LynxOS as opposed
to Unix.

Of course, under the real-time OS, a high-priority CPU-bound task gets
the whole CPU, no questions asked.  That's a great way of degrading
editor response :-).

As a somewhat related side question, what does the Sun 4/SPARC MMU look
like?  Are lookaside buffer reloads done in software like on the MIPS
R[23]000?  (Is that really true about the R[23]000 anyhow?)

-- 
Mike McNally of Lynx Real-Time Systems

uucp: lynx!m5 (maybe pyramid!voder!lynx!m5 if lynx is unknown)