Xref: utzoo comp.unix.ultrix:1192 comp.sys.dec:1501
Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!cbmvax!grr
From: grr@cbmvax.UUCP (George Robbins)
Newsgroups: comp.unix.ultrix,comp.sys.dec
Subject: Re: New DEC announcement, 7/11
Message-ID: <7325@cbmvax.UUCP>
Date: 15 Jul 89 19:51:53 GMT
References: <18553@mimsy.UUCP> <23363@obiwan.mips.COM>
Reply-To: grr@cbmvax.UUCP (George Robbins)
Distribution: na
Organization: Commodore Technology, West Chester, PA
Lines: 58

In article <23363@obiwan.mips.COM> mark@mips.COM (Mark G. Johnson) writes:
> In article <18553@mimsy.UUCP> steve@fnord.umiacs.umd.edu (Steven D. Miller) writes:
> >   Here's the quick summary of what was announced:
> >	3) DECserver 5810/DECserver 5820.  Features:
...
> --------------------------------------------------------------------------
>  
>  When the R3000 processor takes a cache-miss, an entire "cache block"
>  -- (1 to 32 words, boot-configured) -- is fetched from main memory.
> 
>  The CPU/cache can receive them at a rate of one word/cycle (4 bytes/40ns)
>  or a bandwidth of 100 Megabytes/second.
> 
>  Could someone enlighten me?  What's the peak bandwidth of the "XMI bus"?
>  Can it do >= 100 MBytes/sec?  Can it do N * 100MB/s  (for say N=1.3 in
>  a 2-way multiprocessr)?   Thanks.

Well, as I understand it, it's nominally a 100 M-byte/sec bus or as DEC puts
it "a maximum sustained bandwidth of 100 M-byte/sec".  There is support for
block read/write transfers and memory boards are logically multi-word wide
with 2/4/8 way memory interleaving available to boost memory subsystem
thruput.  Real numbers on cycle times, transactions and peak thruput seem
hard to come by.

For the sake of argument, let's assume that the XMI bus can provide the
instantaneous thruput to handle cache load/store operations.  The question
then boils down whether or not there is a large enough on-board cache to
allow effective sharing of the bus.  With the 6200/6300 processors DEC
was willing to put a 256K-byte of cache on each CPU board, which suggests
considerable sensitivity to XMI bus thruput issues.  I think with a cache
this size or larger, the XMI bus should be able to support N-way multi-
processing fairly effectively.

On the other hand, one can call in CISC/RISC arguments and assert that
the XMI bus is designed for a rather CISC'ish processor architecture
and would be swamped by a the memory hungry RISC architecture.  Playing
numerology games suggest that the XMI bus was indended to support around
10 processor/io elements, each good for about 10 MB/sec.  If the RISC
based processor eats 2X or 4X this kind of number, you'd expect to see
some different configuration rules.

Of couse it's hard to tell, DEC loves to alternate balls-to-the-wall high
thruput, wide margin, designs with cost driven, compromise or cripple
everything designs (or unfortunate combinations of the two 8-)...  Lately
though it's seems they've picked up on IBM's "100 incrementally expensive
steps to true performance", so who knows?

I wonder if there is any literature available yet?  The VMS guys here
were talking about new announcements (6400 etc.) in the next couple of
weeks.

Are the Ultrix/RISC guys allowed to come out of the closet again and
tantalize us with some facts?

-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)