Conference wonder::turbolaser

    Do we havbe any 'official' or unofficial white papers I can pass onto
    my customer?
    
    I'm in a competitive situation, down to just Digital and Sequent.
    Sequent are pushing NUMA.
    
    Has anyone done any papers or presentations they gave to customers?
    
    Thanks,
    
    Greg

I have a customer who has been told by SGI that the new Origin 2000
is an industry standard implementation of NUMA by SGI.

Their homepage doesn't seem to reflect this, but the specs are impressive.

Any Thoughts?

Steve

    Yes, the Origin series is a NUMA machine.  They call it distributed
    shared memory. Interestingly, if you do a search on NUMA there, it
    takes you to the Origin overviews, even though the term does not seem
    to appear on the pages discovered.
    
    Of course, for reasons which should be obvious, we shouldn't be going
    around saying NUMA can't work ;-)
    
    I'm not sure that the phrase "Industry Standard NUMA" has any meaning,
    unless you are talking about Intel's SHV boardset (DG & others...)
    
    FJP

    If SGI really claimed "Industry Standard NUMA", I think you should urge
    the customer to question this.  
    
    Chuck

    One thing I'm struggling with.
    
    I'm competing against Sequent who are bidding a 64 processor Numa
    'box'.
    
    This I believe is made up of various quad boards with the memory
    interlinked.
    
    The customer has a concern with us using a cluster, and Oracle
    Parallel Server, however what would happen in the NUMA world when
    either a quad board, or the interconnec failed? Would Sequent not need
    to bid OPS to counter this potential problem?
    
    Thanks,
    
    Greg

    
>    The customer has a concern with us using a cluster, and Oracle
>    Parallel Server, 

Why?

>                     however what would happen in the NUMA world when
>    either a quad board, or the interconnec failed?

Sequent implements NUMA using a uni-directional ring interconnect. If you
lose a single interconnect node, you lose everything. Furthermore, if a
failing quad board holds an updated piece of memory, owned by another quad
board or owns a piece of memory that's needed by another quad board, the
entire system is toast.

>                                                     Would Sequent not need
>    to bid OPS to counter this potential problem?
 
?   

Numa is not a cluster...if a customer wants availability, they
want to cluster in some form.  For performance, I would push with
the customer as to where is the performance #'s for NUMA beyond it
has 64 cpus?  

A lot of vendors do an audit with 6, 10 or 20 cpus, and then say
64 must be good....don't believe it.

    To reiterate, if you want high-availability, you need to implement a
    cluster.
    
    Sequent will also be able to cluster either their old SE kit or the new
    CC-NUMA kit.
    
    Is Sequent claiming that their 64 CPU CC-NUMA system will exceed the
    performance of a single 8400?  Based on what?  Was there a customer
    Benchmark?  

    >> Numa is not a cluster...if a customer wants availability, they
    >> want to cluster in some form.
       
    
    In this weeks PC week Sequent are stated as saying their NUMA machine
    gives 99.99% availability, doesn't say how though!
    
    

    These are the concerns BT have about OPS, any comments:
    
    Realworld is a BT written benchmark that is very heavy read/write.
    
    With RealWorld when ran on a cluster using Oracle Parallel Server,
    using TCP/IP (not a Digital cluster), bog standard interconnect. With 2
    nodes, as updates or benchmark was run using both nodes, got negative
    scalability. Investigate, discovered pinging was the problem ie DLM
    pings the data block from one node to the requesting node.
                                                                           
    Then BT changed Realworld so it was data dependent access on each node,
    ie customers a-d updated on node 1 e-g on node 2 etc, ie partitioned
    the data, however the datablocks stopped being pinged, it was the index
    header block that was being passed back and forwards.
    
    Ie do an insert/delete you change the index leaf in Oracle which
    eventually changes the index header block which becomes the contention
    point. Although its not causing a bandwidth problem, it becomes a
    latency issue.
    
    Will memory channel address this?
    
    
    "pinging" will still happen but will be faster, will it saturate the
    bus
    
    
    BT do not wish to partition their data.
    
    There is a architectural limitation in OPS when it comes to OLTP
    applications. If you are not able (or not willing) to partition your
    data and update it, potentially any node in the cluster can update any
    block of data. The Oracle OPS implementation does not have any concept
    of how distributed raw devices and the distributed lock manager are
    implemented and therefore does not 'know' that something like a memory
    channel even exists.
    
    If one node updates a block in its SGA and a second node in the cluster
    tries to update the same block a so called 'block ping' needs to
    happen: the block gets flushed out to disk from node 1 and is re-read
    on node 2 before it is updated. Now potentially if the application
    updates some small tables in nearly every transaction these few
    datablocks travel between disk and memory constantly. This is a serious
    bottleneck and can only be resolved by database design and data
    partitioning.