Conference ulysse::rdb_vms_competition

    Whether or not we run TP1 as well as Debit/Credit, Tandem already
    has. Their results are the proof you seek of the confusion of TP1.
    The Tandem Debit/Credit result was 208 TPS, 90% 2-sec, on a 32
    processor VLX. The TP1 result (Tandem said they emulated the Sybase
    TP1) was 240 TPS, 90% 2-sec, on a 16 processor VLX. By my math,
    that makes the TP1 results 2.3 times as high as Debit/Credit.
    
    As far as proof of the "easiness" of TP1, that comparison may suffice.
    
    ---- Michael Booth

    There are no TP1 standards, therefore you cannot compare ANY of
    the existing TP1 benchmarks among TP1 database vendors. So even
    if
    Digital published a TP1 benchmark, what would we compare it to?
    
    .1 is correct.  TP1 is less than half the difficulty of ET1 (eg
    debit-credit).  That's because debit-cerdit is an End-To-End
    transaction that simulates the full terminal to database and return
    process that 'real world' transdactions go through.  TP1 measures
    relational database throughput.  The database vendors don't
    supply/can't control the TP monitor and communications part of the
    sales, so they ignore it by bastardizing ET1 into TP1.
    
    Our marketing strategy around benchmarks is to drag the industry
    out of the slime pit of uncomparable tests and into the spotlight
    of open, standard tests.  That's why we were the charter member
    of the Debit Credit Council (set up to define and monitor the benchmark
    and results reporting).
    
    If we need 'very fast' benchmarks, we have our customers to turn
    to as well as other internal tests.  One phone company customer
    is doing over 300 tps on a VAXcluster (which begs the question every
    sales person should as, "just what kind of transaction are we talking
    abou?").  We can do 3-digit tps rates with Rdb 3.0, but the benchmarks
    get more and more lightweight (and less and less meaningfull to
    most customers) as the tps rates go up.  So that's why we are putting
    our stake in the ground around debit-credit. For now.

I want to second Peter's comments.

Over the 6 month period prior to announcement we waffled a LOT on how to
present performance.  The database group was interested in publishing
what we call "batch DebitCredit", which is a TP1-like implementation of
the basic debit-credit implementation.  The reason was obvious, the
absolute numbers are much higher (about 2:1) over the full DebitCredit
numbers.  We also considered 90% 2 Second numbers ala Tandem.  In the
end, we decided that our strict DebitCredit numbers were so good, why
bother sliding around in the mud that others had made.

    I agree with everything you (Mike, Peter, and Hal) said.  I too
    think TP1 is nothing more than a "dirty" number game that the DB 
    vendors play.  However, we can do what Tandem did.  Run them both
    and publish debit/credit.  Yeah, I also feel good about the ACMS/RDB
    tps numbers, but I am in the New York Financial District where Oracle
    is pushing their 40+ tps and Sybase is bragging about their N tps.

    I guess all I am asking for is some more help from the benchmarking
    group for selling RDB.  Let me tell you, it is tough doing business
    in New York and we need all the help we can get.  Are there anybody
    else in the field who feel the same way?

    Thomas

    Re .-1
    
    There's me. TPS figures are like MIPS these days, they don't mean
    much. I agree with everything .1,.2,and .3 said, and I think we
    should try and haul the business out of the mire. Until that's done
    however, we've still got to win sales, or we won't be in a position
    to haul anything out of anything. While ORACLE and TANDEM fix the
    figures, then we should too. Not to oversell the product, but just
    to be used in precisely the way .0 specifies - 
    
    "yes, we can do 4 thousand TPS on a MicroVAX II as well, but _that's
    not what you should be looking at_"
       
    If we can't say that, customers simply assume we've got something
    to hide, and all our good intentions and good products get ignored.
    It's a bit like nuclear weapons; we don't want them, and we don't
    want to use them, but if we don't have them we're very vulnerable
    to those that do and are prepared to use them (that's not an 
    invitation to a discussion on world politics, just an analogy to 
    illustrate the point).
                                                       
    That's the way I feel about it, anyway.            
       
    PDB