>    We are installing a new TSM server on a pSeries 650 using TSM
>5.1.6.5, and a 3584 Tape Library with a L32 and D32 frames with 15 LTO
>Gen 1 Tape drives.  The 650 has 4 2Gb/sec FC ports; two go one McData
>Spherion 4500 switch, and to go to another.  Half the tape drives are go
>to one Spherion switch, and half to the other.  We have them zoned so
>that each FC adapter can only see 3 or 4 drives.
>    Our problem is that we can't get the LTO performance where it
>belongs.  A typical backup from the 650 itself using shared memory (or
>not) only gets 5-6 MB/Sec.  About the same for a Giga-bit network AIX
>client with no other load.
>    Even a "MOVE DATA" tape-to-tape maxes out at 8 MB/sec.   In this
>test, we made sure the two tape drives involved were on different FC
>adapters, on different Spherion switches, and the 650 was otherwise
>idle, so there should have been no contention anywhere.  It took 45
>minutes to copy 21GB.  Not very good.
>    The 3584 firmware is v3060, the 3580 firmware is v3481, both the
>latest.  The 650, the 6228 (FC adapter) microcodes are also the latest.
> The problem seems to be the same for all the drives.  We have bumped up
>the dsmserv.opt options to appropriately high levels according to the
>Performance Guide.  We think we have not overlooked anything there.

Your posting doesn't make note of it, but we had an extensive List discussion of
LTO performance at the end of last week.  Your "typical backup" rates look like
those in the chart on page 12 of
ftp://ftp.software.ibm.com/software/tivoli/whitepapers/wp-tsm-lto.pdf .  You
don't specify what server options you boosted, but observe what the paper has to
say about TXN* options.  I would, however, expect your in-server operations to
proceed faster.  You don't say if you performed essential pre-TSM-usage
benchmark tests, outside of TSM, to gather baseline numbers before using the
drives under TSM in validating their performance thusly first: I would do that.
You may have path serialization issues.

  Richard Sims, BU