Conference ricks::dechips

rewrapped to 80 columns
    
             <<< Note 659.0 by MINNY::rahel.zuo.dec.com::dolder >>>
         -< SUN 16-way UE6000 TPC-C (Oracle): 23143 tpmC @ 118$/tpmC >-

SUN just nuked our single-node Oracle TPC-C result using a 16-way (250Mhz/
UltraSparc  II), 5GB Memory equipped UE6000. Using Oracle 7.3.3 they achieve
23143 tpmC @ 118  $/tpmC). With this result they also dangerously approach (75%
of the performance at less  than one third of the price) our 4-node TruCluster
TPC-C which we did using 4x8400 with  32CPUs and 32GB of Memory. Of course one
may argue that we used slow CPUs (5/350) to  achieve our result but keep in mind
that a 5/350 processor still got a higher SPECint95  than a 250 Mhz Ultrasparc
II (10.1 vs. 9.75). Of course this raises a couple of questions  like (SUN will
make sure that customers will ask those) :

* what for should VLM64 be good looking at those results ? * where is Alphas
performance advantage if SUN can achieve 75% of the Alpha result using  half of
the number of processors (i know that this cannot be compared like that but SUN 
will tell so...) * How will Digital look once we put up this benchmark on a
UE10000 using 64 CPUs ?

It's frightening to see SUN taking away all leading benchmarks one of another
from us  (single node TPC-C [Oracle, Sybase, Informix], single node SAP R/3, 
c/s SAP R/3). And  also 300 GB TPC-D we have no answer as of yet. 

-matthias


    

    refer 658.13
    
    This is as much a packaging issue as anything else. Plus a superb
    kludge called Supercache to allow Sun to do a 'sort-of' VLM to get good
    effective database caching.
    
    I'm told that there is some debate around us doing a similar kludge for
    NT on Tlaser, to allow database vendors to benefit without needing to
    explicitly 'exploit' whatever VLM like capabilities we/MS nail onto NT.
    With a large Sybase / SQL / etc number on a 12 way 620 Tlaser, I / we
    can change the game a bit against SUN. Rather than debating the
    engineering elegance of SUN's kludge, can we give it serious
    consideration for NT. No. Just do it.
    
    Re the Unix numbers, I know Shak and crew are pressing the pedal to the
    metal. I hope they have 620 parts soonest too. And look for a huge TPC
    number soon.
    
    AW

    The fundamental problem we have with TPC-C is that the I-stream
    doesn't fit on-chip and we are limited by the speed of the B-cache.
    It doubt that a 622 alone will buy much unless the absolute speed
    of the B-cache is enhanced. The Ultrasparc has a 250 Mhz path
    to it's B-cache, we have a 45 Mhz path.

re.1 Once again i forgot the 80 col issue while typing into the 
Teamlinks Conferencing Interface. Thanks .1


re. 2 & 3
Unfortunately my Mr. Customer couldn't care less if we have 
designed too slow cache bandwidths or if we have not designed
enough headroom into our systems to accommodate more 
than 4 (14 resp.) processors. The only thing my Mr.Customer
sees is (as said in .0) that SUN is taking away from us one 
lead benchmark result after another. 

Alpha's primary competitive differentiator is supposed to be 
leading performance at leading price/performance. Unfortunately
all recent benchmarks start to create a quite different perception
within our customer base. Being in front of customers a considerable 
amount of my working time i see that perception [that DIGITAL lost
its performance advantage] grow more and more.
The only way to turn it around is facts from us, saying that 
theoretically and 'if this and that would be the case' does not help.

Since we're all waiting for 5/625 8400's, let's guess on an Oracle
TPC-C with a 12-CPU/8GB 5/625 system based on SUN's result:

SUN: 
16 CPUS * 9.75 SPECint95 = 23144 tpmC (Oracle 7.3.3)

DIGITAL:
12 CPUS * 19e SPECint95 = 23144 * (12/16) * (19 / 9.75) = 33825 tpmC
This would be nice of course, now what could we do in reality ?


-matthias
-----------------------------------------
Matthias Dolder @ZUO, Digital Switzerland
UNIX Ambassador
Technology Consultant
Mail: dolder@mail.dec.com


ps: I know that we are targetting a 6-digit tpmC later this year.
    However, what i'd need badly over here is a leading 300GB TPC-D
    and a leading SAP R/3 SD user benchmark (ie the 2666e SD users
    we see on different slides i'd need without the 'e', meaning as
    official result)

    
    For the record
    
     512KBytes cache = 250Mhz Rep rate
     1MB - 4MB cache = 125Mhz Rep rate
    
     We could build a 125Mhz 4 Mbyte cache on EV56 using IBM parts on
    the 622 Turbo design, but have opt'd for a slower 8 Mbyte version
    as early data on the 440's and 350's suggested that we got more
    performance in return.
    
    
    						/Dave
    

    .4
    
    no, but understanding quite why and *how* Sun have achieved the numbers
    (and understanding cache schema and packaging is key to this), at least
    we can then prepare (or attempt to) a story when we go selling. I too
    spend most of my time with customers. SUN *is* hard right now, but our
    guys/gals are working very hard. A TPC-D number is being worked on, as
    is a SAP number.
    
    to help you a little with your punter, try this:
     
    1) Compare UE10000 and UE6000 TPC-D for 300GB. Note that with 2.66
    times the CPs, the UE10000 gives just 1.9 the QthD Thruput, and just
    1.7 the QppD Power at a higher $$ per. Hmm.... how do you spell
    'Scaling' ?
    
    2) Examine the (older) 100GB TPC-D number for the 167Mhz UE6000 (again
    with 24 Cps). You can do a direct compare with our 12 way 8400 5/440 single
    node TPC-D here. Getting warmer ? 
    
    3) you *could* sell a 14 way 620Mhz in a month or so. Or a cluster...
    
    [Make sure you don't stumble into a TPC fair use violation with the
    inferences you draw in 1 to 3 above, contact our performance crew, and
    make sure you use carefully crafted words with the customer to avoid
    any problems - get the customer to draw his own 'comparison' if you
    can. In Europe, involve the Strategic Bid Centre - try Marcus Chambers
    @GEO first - maybe even benchmark your customer app - the Bid Centre
    can advise /help ]
    
    re .3 - I understand the speed and size for B-cache might improve for
    the 620 Mhz parts, to help with TPC-C some.
    
    Mr Ambassador, 1),2),3) above is called selling.
    
    Yes, Sun is hard, but we are paid to sell, with whatever help we can
    get from around the place. Sun beat me twice just now, and I beat them
    once since. Recent history (the 'once since' gives me some cheer !)
    
    Our performance crew are working very hard on some large systems - knowing
    them, probably all the hours that God/Allah/Cantona sends. 
    
    
    AW
     
    
    

    .6
    
    will you stop making your replies personal. You aren't the only one to
    have bad days you know. I've had 2 on the trot. Take a day off.
    
    
    [Mattias - you'll have got my mail. Anything I can do to help, let me
    know]
    
    
    AW