From: wolfgang@code-541 (Lewis E. Wolfgang)
Newsgroups: comp.arch,comp.benchmarks
Subject: Re: Sun 600MP Benchmark Anomaly
Date: 24 Jul 92 00:51:18 GMT
Reply-To: wolfgang@code-541
Organization: NCCOSC, NRaD Division

In article 19190001@hpcss01.cup.hp.com, markw@hpcss01.cup.hp.com (Mark Williams) writes:
>wolfgang wrote:
>> There is a known problem with SunOs 4.1.2 and the MP machines
>> that is fixed with Sun patch 100575-02.  Symptoms included poor
>> performance (worse than a 490) under certain conditions.  One
>> wonders if Workstation Labs had this patch installed.
>
>> We have a 690MP with 4 processors and are of the opinion that
>> it is the best thing since cotton sheets!  It is a win for us
>> as a computational server, nfs server and three segment network
>> router.
>
>Since the patch came out in May and the article was in the June issue,
>it was probably done without the patch.  My own guess is that the patch 
>was done in response to the article, but it's just a guess.

I think the patch was available earlier, but I might be wrong.  Some
Sun people e-mailed me after my post and indicated that they did NOT
have the patch, and also aparently didn't ask for any help from Sun.

>
>But the patch didn't really fix the anomaly.  It helped two processor
>performance, but did not change the fact that 4-processor system ran no
>faster than a two processor system, at least in all the benchmarks I've
>seen.  The two processor systems ran only slightly faster than a system with 
>one processor stopped (20%).  This is pre-Solaris 2.0.  I don't know what
               ^^^^^^^
Hm, how do you "stop" a processor?

>2.0 will do, but I think software might not be the only culprit.  MBus
>may be saturated or the I/O system may be too slow.  It's interesting that
>future Sun Dragon servers do not seem to use MBus, according to published
>reports.
>
>Bottom line:  the 600MP (with SunOS 4 and the May patch) performs poorly as
>an MP system, but it is a fine uniprocessor with better I/O than a workstation.

I recall running benchmarks four times simultaneously (in background) and
having each invocation perform only slightly slower than running it once on
a 490.  Running it once on the 690 yielded better results than a 490.  I wish
I had documented the execution times, but I was doing this only for my own curiosity.
The system is in continuous heavy use right now, when things cool off a bit
I will rerun the programs and document the performance.

At the moment, the system has 5 users and two computationally intensive
programs running all the time.  At the same time it is serving 18 SparcStations
and routing between 3 ethernet segments.  I ran one benchmark that ran in 6.55
seconds on the 690, 7.09 seconds on a lightly loaded 490.  Another large
acoustic modeling program just ran in 27 seconds on the 690, it runs in 28
seconds on the 490.  Looking at the perfmeter, idle times never got below 25%,
indicating that it still had plenty of poop left.  Hm, let me try running the big
one twice in background (simultaneously), back in a moment...  ok, I'm back.  Each
one ran in 36 seconds, versus 28 on the 490.  Moreover, the system was still
responsive, running 4 big jobs in background while serving and routing would really
bog down a 490.  Yup, it is a win for us.

Could it be that you are thinking that one running job will utilize all available
processors simultaneously?  This system is coarse-grained, in that one process
runs on only one processor.  It may be swapped around to different processors, but
is running only on one at any one instant in time.

					Luck
					Lewie
					wolfgang@nosc.mil

					NCCOSC, NRaD Division, Code 541





Newsgroups: comp.arch