Re: Multiprocessing: Oracle 7 & Solaris 2.3

smith117_at_delphi.com wrote:
: <jaakola_at_cc.helsinki.fi> writes:
:
: >So Solaris isn't a "good SMP implementation"? Why? What's missing?
: >
: >Specifically, I mean is Sequent or Pyramid better in running Oracle RDBMS
: >7.0 and applications (no client/server)?
:
: A potential I/O bottleneck that I have observed is the marriage of I/O
: expansion to CPU expansion on the MBUS modules.
The high end Suns (and our box: ss1000, sc2000, cs6400) don't use MBUS, they go with xdbus.

:
: This leads to too many I/O controllers trying to master the system
: bus, which can seriously impact system performance.
It's pretty hard for an S-bus disk controller to master a 1.6 GB/s XDBUS setup. It may take a few cycles every once in a while, but there is more...
:
: Compare this with say the high end DEC system, which has a single
: I/O port controller accessing the CPU/Memory bus. This controller is
: always guaranteed first dibs on the bus bandwidth, and half the overall
: data bandwidth per second. Since all I/O expansion is done below this
: master port controller, data split across multiple buses and slots is
: all accessible through a single high speed system bus access.
Actually there is a SBUS to XDBUS port chip on each system board that ends up creating nearly the exact balance you say is so good. That chip runs keeps the potential IO bandwidth to 1/2 the overal system bandwidth in a fully stuffed high end xdbus system.
:
: It is my understanding that the high end Sparc architecture cannot
: do this. Access to data distributed across multiple I/O controllers
: leads to multiple interrupts on the system bus, limiting the maximum
: I/O data rate.
Your definition of interrupt must be different from mine. I consider an interupt to be something that the CPU will take a context switch or trap on. And no normal computer bus does this to access main store. That would be a little absurd, unless the interupt handler runs out of ROM or something else that's not part of the main store. Probaly what you've heard is that XDBus is 'packet' or some such. That's not that different from traditional bus except that they've split the "read" operation into two: request/deliver.

I have observed very high IO data rates on an XDBus architecture. But not without lots of very careful tuning to spread the IOs evenly among spindles.

My take is that the xdbus's peak speeds are enormous compared to lots of SCSI controllers and disks.

: Hope this helps clarify things.
:
: Dan

-- 

Robert C Larson
rcl_at_oregon.cray.com <| Don't try to reply if it says rcl_at_walter.cray.com