All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ward Deng <wdeng@KachinaTech.COM>
To: ultralinux@vger.kernel.org
Subject: Re: Ultra AXmp
Date: Sun, 26 Jul 1998 04:29:46 +0000	[thread overview]
Message-ID: <marc-linux-ultrasparc-90222358531085@msgid-missing> (raw)
In-Reply-To: <marc-linux-ultrasparc-90222358531013@msgid-missing>

> 
> I am also more interested in memory bandwidth than L2
> cache, although at 4MB the cache probably begins to be
> helpful. Some of our tasks will grab 100MB or more of
> main memory and spin through it repeatedly for weeks
> or months at a time, thus rendering the cache largely
> irrelevant. The memory bandwidth in the UPA is a step
> in the right direction for us, although it is still the
> case that several processors all squeezing memory access
> through a single memory port can be a drag (the AXmp has a
> single 144-bit -- 128 bits of data and 16 bits of ECC --
> UPA port for memory; the EDO memory is accessed 576 bits at
> a time, but then it is multiplexed through XB9 crossbars
> into the single UPA port). Multiple memory ports as on
> the gigaplane help, but in the end it seems kind of silly
> spending tens of thousands of dollars to get a machine and
> then to tune your workload to make it work like a cluster;
> I'd still rather have a pile of single or dual processor
> machines; I can afford a lot more processors that way,
> for one thing.  The biggest problem I have here is
> physical space, although I saw a nice 2U chassis at
> Linux Expo (DCG Computers), and the manufacturer is working
> on modifying it for the AXi motherboard. Too bad the
> AXi's memory channel is choked off to Pentium II levels.

[snip]

On my datasheets, AXi (Panther) has 144-bit memory path while Pentium II
is only 64-bit. AX (Photon) has 288-bit full-scale UPA. AXmp (Chrico)
has two UPAs with 576-bit memory path. In our tests, even AXi has much
better scalability than PII.

We experienced the same problem as Bob did. A large-scale computational
chemisty program ran dog-slow once the problem scaled up to practical
level on an Alpha-PC system while it ran blazing fast during development
phase. The reason: system throughput was too bad. HAL system was a big
improvement then until UltraSPARC came out. Most real computing jobs won't
fit in your SRAM cache no matter how big you make it.

This is why we are so interested in UltraSPARC architecture and try to
make it available to Linux users. We first started Pentium Pro and got
very disappointed. Then we found OEM Alpha PC (DEC intended for NT users)
was not a good candidate either. We hope UltraSPARC nodes make into
"Beowulf" clusters soon. Pricewise, I think UltraSPARC is very reasonable
comparing with Intel Xeon. Maybe SME should provide a version similar to
Intel Celeron (joke) just for marketing purpose.

--ward

  parent reply	other threads:[~1998-07-26  4:29 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-07-11 18:36 Ultra AXmp Bob Drzyzgula
1998-07-12  1:56 ` David S. Miller
1998-07-12  2:21 ` Matthew Jacob
1998-07-12  2:29 ` David S. Miller
1998-07-12  5:02 ` Matthew Jacob
1998-07-12 12:54 ` Douglas Eadline
1998-07-12 23:59 ` Bob Drzyzgula
1998-07-13  6:27 ` Qiru Zhou
1998-07-13  6:38 ` David S. Miller
1998-07-13 10:40 ` Bob Drzyzgula
1998-07-13 12:09 ` Xavier Beaudouin
1998-07-13 13:59 ` Robert G. Brown
1998-07-13 14:29 ` Robert HYATT
1998-07-13 14:54 ` Matthew Jacob
1998-07-13 14:56 ` Matthew Jacob
1998-07-13 14:59 ` Matti Aarnio
1998-07-13 15:24 ` Robert HYATT
1998-07-13 15:38 ` Robert HYATT
1998-07-13 16:56 ` Robert G. Brown
1998-07-13 17:04 ` Robert G. Brown
1998-07-13 17:13 ` Lawrence D. Lopez
1998-07-13 17:26 ` Mike
1998-07-14  1:44 ` Shannon
1998-07-14  7:00 ` David S. Miller
1998-07-14 18:07 ` Douglas Eadline
1998-07-14 23:23 ` Bob Drzyzgula
1998-07-15  3:31 ` Dave Wreski
1998-07-15  8:07 ` Ward Deng
1998-07-15 11:14 ` Bob Drzyzgula
1998-07-15 11:27 ` David S. Miller
1998-07-15 15:54 ` Robert G. Brown
1998-07-15 17:11 ` Robert G. Brown
1998-07-15 23:22 ` Luis Ponce de Leao
1998-07-21 23:29 ` Ward Deng
1998-07-25 23:34 ` Ward Deng
1998-07-26  0:02 ` Ward Fenton
1998-07-26  0:45 ` Rich Martin
1998-07-26  3:34 ` Bob Drzyzgula
1998-07-26  4:00 ` Ward Deng
1998-07-26  4:29 ` Ward Deng [this message]
1998-07-26 12:29 ` Bob Drzyzgula
1998-07-26 13:57 ` Douglas Eadline

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-ultrasparc-90222358531085@msgid-missing \
    --to=wdeng@kachinatech.com \
    --cc=ultralinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.