Re: tape speeds, TSM and pase

[Evan Harris <spanner@xxxxxxxxxx>]

Rob

I'm just starting a project to go down this road so it is interesting that 
you posted the performance figures - I had been wondering whether this was 
any better these days.

TSM has always been much, much slower in terms of tape speed than native 
AS/400 tape functions at least in my experience so what you are seeing does 
not surprise me in the least. One of the arguments to defend this I always 
used to hear was that it didn't matter because you were always going to be 
doing incrementals anyway so the data volumes would be much smaller after 
the first save. This theory really fell apart on a development box where 
there were new copies of data and new libraries created all the time but I 
could probably accept that this is not typical. One of the system I was 
managing also had a monster file that used to change every day and loads of 
files written to the IFS which were required so even the production 
incrementals were highly volatile and caused some issues.

Fortunately I will not be running the server on the iSeries (I don't think 
I ever want to have to do that again) so the PASE limitation is not likely 
to bite me at least as far as the server API's go, but I am wondering what 
the performance will be like throwing the data across the network to (I 
think) a 3583  attached to a pSeries.

Just so I have something to compare against later on, how did you got about 
measuring the throughput ?

Regards
Evan Harris

> 3582 runs 131GB/hour native
> 3582 runs 33GB/hour TSM underneath PASE
> PMR with IBM says that it is because PASE API's to talk to tape drive are
> limited to size chunks and really kills the speed.  Repeat, it's a PASE
> issue and not a TSM issue.
> 3581-H17 runs 32GB/hour TSM underneath PASE.
> Therefore the better hardware of the 3582 gets you little to no speed
> improvement when using TSM underneath PASE.  Just higher tape volume.
> This was NOT the normal grandfather... stuff of moving stuff from disk to
> tape that TSM does.  This was a TSM backup of the entire disk pool to the
> tape pool to move it offsite.  Therefore that grandfather logic was not
> part of the equation.
>
> TSM command used:
> backup stg backuppool lto_3581_week1
>
> IBM says it's a limitation of PASE and have no intention of 'beefing' up
> the api's to pipe data to the tape drive any faster.  Workaround:  Dump
> OS/400 and try a Linux or Unix partition.
>
> Will running TSM on a Linux partition on my i5 get me any faster response
> from LTO2 and/or LTO3 tape drives than running TSM underneath PASE?
>
> TSM 5.2.2
> OS/400=V5R3M0
>
> Rob Berendt
> --