Re: tape speeds, TSM and pase

This is how I measured my throughput.

The native OS/400 command was a couple of simple SAVOBJ's.  Granted, these 
are huge objects.  A couple of 262GB objects.  (Actually they are old ADSM 
3.x storage pools stored as objects within a library.)  Size of the object 
/ (end time of the SAVOBJ, minus the start time) = GB / hour.  That was 
131GB/hour.

The TSM PASE was a 
03/18/05 16:33:02     ANR2017I Administrator DOWNTIME issued command: 
BACKUP 
                       STGPOOL backuppool lto_3581_week2  (SESSION: 1240)
...
03/18/05 16:35:23     ANR0513I Process 38 opened output volume 06WK2. 
(SESSION: 
                       1240, PROCESS: 38)
...
03/19/05 06:19:26     ANR1214I Backup of primary storage pool BACKUPPOOL 
to copy
                       storage pool LTO_3581_WEEK2 has ended.  Files 
Backed Up: 
                       2656444, Bytes Backed Up: 472898572288, Unreadable 
Files:
                       0, Unreadable Bytes: 0. (SESSION: 1240, PROCESS: 
38)

So, the way I calculate this is:
473gb / ( (24:00 + 06:19) - 16:35)
473gb / 13.75hours
or 34.4GB / hour



Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





Evan Harris <spanner@xxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
03/22/2005 04:30 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: tape speeds, TSM and pase






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
>--

-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.