| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1141.1 | comments | NAMIX::jpt | FIS and Chips | Fri Mar 21 1997 07:37 | 36 |
| > Last point, the customer is not interested (at the moment) by the
>cluster (MC) interconnect stuff, they want "one" Operating system for
>this server, so we cannot say, we scale with MC interconnect.
Ho, ho, ho - hold on !!!!????
Is customer expecting to get "single operating system copy" with
SGI Origin and cc-NUMA/Cellular IRIX? As far as I know, it is _not_
true, as every cc-NUMA node has own operating system copy according
to SGI. See for details:
http://www.sgi.com/Technology/Irix6.4/cellular_irix6.4tr.html
And also, our customer at CERN has got VERY good results using
MC. He got even better latencies on some tests than Cray T3E...
See for details:
http://www.cern.ch/RD11/combench/results.html
Results show that:
- with lower processor numbers 8400 scales better than Origin
- with cc-NUMA/large numbers of processors Origin is better
- MEMORY CHANNEL is good, practical real life latency
customer got was about 3.3�s!
So, you have two choises:
- position MC against cc-NUMA, prepare yourself well for
technical debate
- check out future products with PM's, but be aware
that Windjammer/Flagship/Wildfire are pretty distant future
regards,
-jari
|
| 1141.2 | MC NUMA CC MC NUMA | NETRIX::"[email protected]" | Eric Camilotte | Fri Mar 21 1997 08:23 | 14 |
| Thanks for these explanations, I will look at the URL you
mentionned. My first concern remains the scaling problem in
SPECfp_rate95 with the 440 Mhz and the possible gain with the
6xx Mhz version.
What can I tell to the customer without saying "if you do not
use MC, you will not obtain scaling in pure SMP turbolaser because
we begin to be out of memory bandwith with the higher frequencies
alpha chips".
Thanks for help.
Eric
[Posted by WWW Notes gateway]
|
| 1141.3 | | WIBBIN::NOYCE | Pulling weeds, pickin' stones | Fri Mar 21 1997 08:27 | 3 |
| Doesn't the 6xx MHz processor board have a larger secondary cache? That
should reduce the load on the memory bus somewhat, leading to better
single-processor performance and also better scaling.
|
| 1141.4 | yup, 8mb cache has been shown to help scaling | PERFOM::HENNING | | Fri Mar 21 1997 08:56 | 8 |
| I agree with .3 - for a previous example of this, see what happened
with the AlphaServer 2100 5/375, where its bandwidth shortcomings were
much assisted by its 8mb cache.
See http://www.digital.com/alphaserver/performance/smp_scaling.html
(and feel free to point your customer at it if you think it helpful)
/john
|
| 1141.5 | Need some FUD info! | WOTVAX::HILTON | Save Water, drink beer | Fri Mar 21 1997 10:42 | 6 |
| Do we have any figures that show where a TLaser outpeformed a MPP and/or
a NUMA system?
Cheers,
Greg
|
| 1141.6 | a related question that came by email | PERFOM::HENNING | | Fri Mar 21 1997 10:44 | 8 |
| I've been asked whether there are SPEC estimates for TL/622. Not that
I know of. But perhaps at the single-CPU level TL/622 will not be all
that different from Rawhide/600, for which both PKO and ZKO have been
doing some SPEC testing. If single-CPU is of interest here (which it
may not be for the basenoter...) you could drop a note to Rawhide
product management and ask about early SPEC95 Rawhide/600 results.
/john
|
| 1141.7 | Yes, 622 has larger cache | LANDO::JBENNETT | | Fri Mar 21 1997 10:47 | 6 |
| re .3.
the 622Mhz Turbolasers (to be marketed as 625s) has a 8Mb secondary
cache, twice the current size.
john
|
| 1141.8 | tpc-d contains MPP systems as well (NCR and SP) | NAMIX::jpt | FIS and Chips | Mon Mar 24 1997 01:48 | 6 |
| > Do we have any figures that show where a TLaser outpeformed a MPP and/or
> a NUMA system?
Well, we run a benchmark where 6cpu 8400 with 6GB outperformed
large Unisys Opus (64cpu or so?) by factor of 3 or more (3-12x)
but only official numbers I'm aware of are TPC-D numbers.
|
| 1141.9 | TLSB speed | NETRIX::"[email protected]" | Eric Camilotte | Mon Mar 24 1997 05:48 | 38 |
| Does anyone have some infos about TLSB speed on the 622 Mhz
Turbolaser. It would be nice that along with the 8 mb cache it
is updated.
About reply 1. and the SGI stuff, I looked at the URL given. It
seems that besides he fact that there is a copy of the kernel stack
and data on each node, (so not a single OS) Irix gives :
- a single logical view of the system (for example, processes seem
to be viewed anonymously from any node).
- the scheduler seems to be much more acute than our.
- the page size can be dynamically adjusted, some pages can be
replicated across the nodes (we do it, but in a coarse way with
f90)
- an so on
It seems to me that the system view given by the fisrt release
of Cellular Irix is more sophisticated that the view given by our
current TruCluster release, and I don't want to engage with MC stuff
against Origin 2000 without having competitive infos about this
(important) aspect of administration.
What is not clear on the SGI Web is if the file systems are
distributed across the nodes of the Origin 2000. If it's right, we
are in a bad position with our distributed RAW device (waiting for
CFS).
I am not complaining, I just want to get a clear view of this
stuff. If we can compete in terms of performance but not in terms
of manageability, we have to know it.
I am competing in 2 major accounts against SGI and I need maximum
infos about our 622 Turbolaser and SGI competitor.
Thanks for input.
Eric
[Posted by WWW Notes gateway]
|