[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference wonder::turbolaser

Title:TurboLaser Notesfile - AlphaServer 8200 and 8400 systems
Notice:Welcome to WONDER::TURBOLASER in it's new homeshortly
Moderator:LANDO::DROBNER
Created:Tue Dec 20 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1218
Total number of notes:4645

1141.0. "Scaling vs Origin 2000" by NETRIX::"camilotte@tlse16.too.DEC.COM" (Camilotte Eric) Fri Mar 21 1997 09:29

    We are going to benchmark against SGI Origin 2000 for a custumer
request, that already got 10 turbolaser class machines (no cluster, "just
SMP).
    The (anxious) questions of the customer concerns the SPECfp_rate95
published on the 8400 440 Mhz that :
     1 - Are under the Origin 2000 marks
     2 - are not scaling on the turbolaser, and with 12 CPU's, the fp
         results are worst than the int results (1118 / 1358).

     The customer is very aware of the cc-NUMA stuff and ask us to
explain the "poor" results of the turbolaser comparing to the brand
new Origin 2000.
     They now doubt, after more than 2 years of very good Turbolaser
experience than we will able to follow the scaling of NUNA machines.
     Of course, the customer benchmarks will tell (we won everytime
until now, but against Power Challenge machines, not Origin 2000).
     I know that SPECfp 95 is also memory bandwith oriented and the
obvious answer is that we run out of bandwith with the 440 Mhz (for
the SPECfp_rate95).
     We propose an upgrade to 6xx Mhz, but the customezr doubt it will
boost the scaling as well, considering the 440 results beside the 350
Mhz results.
     Does the TLSB with the 6xx will run at the same speed than with
the 350 and 44O ?
     In this case, I expect that the scaling will be worst. If it's
not the same speed for the TLSB, what will be the speed, what ratios
can we expect ? (we have to engage on it).
     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.
     What kind of answer can I give to the customer aside "we are now
going to run out of memory bandwith, and with EV6, it will be worst...).
     
     PS. The customer also wants that we give a technical and financial
         answer for doubling the actual max perfs (int and fp) of the
         8400 440 (SGI can do this with the Origin 2000).

     Any help (turbolaser explanations about poor scaling, the 6xxx
stuff, and SGI Origin 2000 weak points) will be appreciated.

     Eric    
[Posted by WWW Notes gateway]
T.RTitleUserPersonal
Name		DateLines
1141.1commentsNAMIX::jptFIS and ChipsFri Mar 21 1997 10:3736
1141.2MC NUMA CC MC NUMANETRIX::"Camilotte@tlse16.too.DEC.COM"Eric CamilotteFri Mar 21 1997 11:2314
     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.3WIBBIN::NOYCEPulling weeds, pickin' stonesFri Mar 21 1997 11:273
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.4yup, 8mb cache has been shown to help scalingPERFOM::HENNINGFri Mar 21 1997 11:568
    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.5Need some FUD info!WOTVAX::HILTONSave Water, drink beerFri Mar 21 1997 13:426
    Do we have any figures that show where a TLaser outpeformed a MPP and/or
    a NUMA system?
    
    Cheers,
    
    Greg
1141.6a related question that came by emailPERFOM::HENNINGFri Mar 21 1997 13:448
    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.7Yes, 622 has larger cacheLANDO::JBENNETTFri Mar 21 1997 13:476
    re .3.
    
    the 622Mhz Turbolasers (to be marketed as 625s) has a 8Mb secondary
    cache, twice the current size.
    
    john
1141.8tpc-d contains MPP systems as well (NCR and SP)NAMIX::jptFIS and ChipsMon Mar 24 1997 04:486
>    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.9TLSB speedNETRIX::"Camilotte@tlse16.too.DEC.COM"Eric CamilotteMon Mar 24 1997 08:4838
    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]