On Friday, Jul 9, 2004, at 11:11 Australia/Sydney, asr AT UFL DOT EDU wrote:

==> In article
<B4FE6832-D13B-11D8-BD90-000502638BD0 AT stix.homeunix DOT net>, Paul Ripke
<stix AT STIX.HOMEUNIX DOT NET> writes:

With any disk and controller technology that supports command queuing
(SCSI2
command tagged queuing, SATA Native Command Queuing (NCQ)), you are
better
off with about 3 volumes per spindle for random I/O.  TSM serialises
I/O per
volume, meaning only one I/O in flight to each volume at any one time.

Hmm. This is the first I've heard about NCQ; any pointers to which
devices and
which firmware levels do this?  I've got some rather old 9G SSA which
might
not do the trick.

NCQ for SATA is brand new - there's probably only a handful of drives
on the market supporting this. For SCSI, FCAL, SSA it's been around
for quite a while. At least for SCSI, probably the mid-eighties.

I believe SSA has supported command queuing from day one. Under AIX,
just
check the queue_depth hdisk attribute:
       lsattr -El hdiskx -a queue_depth
This attribute should only exist If the device supports queuing, and
represents the OS imposed limit on simultaneous outstanding IOs to the
device. It's a really good idea to tune this parameter for high-end
and middle-market disk farms (ESS, HDS, EMC, FASt...) running random
IO loads.

But I'll fiddle with it on my new 36Gs; if I can get acceptable
performance
out of them this way, I'll be exstatic.

This is backed up by tests I've run, and is recommended by one of the
IBM
TSM support guys here in Australia.

Cheers,
--
Paul Ripke
Unix/OpenVMS/TSM/DBA
I love deadlines. I like the whooshing sound they make as they fly by.
-- Douglas Adams