Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!ub!dsinc!bagate!cbmvax!grr
From: grr@cbmvax.commodore.com (George Robbins)
Newsgroups: comp.sys.dec
Subject: Re: DEC 582810/20 performance concerns
Message-ID: <15523@cbmvax.commodore.com>
Date: 1 Nov 90 18:27:18 GMT
References: <1990Nov1.050433.5615@bmers145.bnr.ca>
Reply-To: grr@cbmvax.commodore.com (George Robbins)
Organization: Commodore, West Chester, PA
Lines: 54

In article <1990Nov1.050433.5615@bmers145.bnr.ca> larryd@bmerh140.bnr.ca (Larry Dunkelman) writes:
> After reading a number of postings concerning the performance of the
> 5810/20 I realized I wasn't alone in wondering why these machines seem
> to run slower than the supposedly slower 3100.
...
> I then ran a memory test which involved an enormous amount of memory 
> access (the program built a linked list by scanning the list until the
> end was reached and then adding the list element - 5000 times!).  
> 
> The results of this last test were very suprising.  The 3100 ran the
> benchmark in 29 seconds.  The 5810 took 67 seconds.  These times were
> CPU usage (real time was the same as there was no other system activity).
> 
> DEC acknowledged the problem with the memory on the 5800 series but said
> they were not planning on doing anything about it. I gave DEC my program
> about 4 months ago -- no word since then.

This isn't too surprising, the basic concept seems to be that the CPU board
to XMI memory interface is a major bottleneck in the 5810.  As long as the
cache can effectively handle the system working set, you get the theoretical
1.X times the DS3000.  However, once a large percentage of accesses require
XMI access, performance decreases drastically.

The DS3100 and DS5000 don't really have a "system level Memory Bus" in the
sense of the XMI or BI bus, thus the cache<->memory interface can more closely
match the needs of the CPU.  The DS5400 probably lies somewhere in between.

It is interesting to note that the new 128MB memory boards announced for
the VAX6500 series introduce a new cache support strategy.  It's possible
this could convey some benefit to the DS5800 CPU boards, or more likely
a second generation "5900" CPU board.

DEC could also improve the situation by releasing a new CPU board with
both faster MIPS chips, a larger cache and possibly some kind of local
memory attachment sub-bus, but it's hard to judge their level of
commitment to the DS5800 as a server level product.

Releasing a DS5500 product that has a higher performance level than the
DS5800 (and is much cheaper) strikes me as an admission that either they
are in desperate trouble with DS5800 follow up projects, or have abandoned
the platform in favor of something with lower "overhead" that makes it
possible to be price competitive with Sun, without blowing the captive
VAX/VMS price margins on XMI memory and XMI/BI peripherals...

> I'll save the rest of my experiences with the 5800s (yes, I have two of 
> them -- and have plans to buy two more) and ULTRIX 4.0 for later.

Sure, let us know -- I think I've given up on Ultrix 4.0, at least for
the 5800 and will wait for the 4.1 tapes to show up and age a bit.

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)