Hi All
Below again a posting from a few weeks ago - with the microcode - infos.
With this Microcode i needed 67 minutes to restore 17 GB...
LTO Microcode - Perf Improvement
From: arhoads <arhoads AT PACBELL DOT NET>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 12 Mar 2001 06:10:46 -0800
I'm posting this to the ADSM-L list so that anyone to whom it applies
can gain the benefit ASAP. I get it from an IBM internal/Business
Partner mailing and recieved permission to post it here.
Regards, Steffan
+++++++++++
The latest LTO drive microcode (0CE1) provides a
significant performance improvement for customers doing
certain types of tape operations. This level of code
dramatically improves the overheads associated with
buffer flush (write 0 filemarks) and end of file (write
2 filemarks, backspace 1 filemark).
TSM does a buffer flush after every transaction. The
end of file impact would be greatest for customers
writing a series of files to the LTO tape drive. For
tape applications that intensively use buffer flush or
are writing a series of files we have seen 30% to 50%
elapsed time improvements after installing 0CE1. 0BN1
was the previous LTO drive microcode release.
For 3580, 3581, and 3583 mach types (Customer Setup),
the customer can download 0CE1 from:
ftp://service.boulder.ibm.com/storage/358x
Choose 0CE1.fmr
Instructions for verifying the current LTO drive
microcode release and how to install the new release
can be found in the IBM Ultrium Device Drivers
Installation and Users Guide available from:
ftp://ftp.software.ibm.com/storage/devdrvr/
For 3584s, have the customer request his CE update the
LTO drive microcode.
On Thursday 03 May 2001 17:35, you wrote:
> I would hope/expect to see at least 10 GB/Hr restore speed, especially if
> there was no need to mount a lot of tapes; have you opened PMR with IBM
> and/or Tivoli on this problem?!? Also, are you seeing 20 GB/Hr on backup
> speed?
>
> We just ordered a six drive 3583, along with H80, specifically intended to
> address restore performance (and capacity) issues... so we are very much
> interested and concerned about your experience! Our plan would be to use
> either TSM server 3.7.4 or 4.1.3 (just recently released, with some fixes
> for performance & LTO support) - I am suspicious that you're seeing
> problems associated with the 4.1.2 server.
>
> Thanx,
> Don
>
> Don France
>
> Technical Architect - Unix Engineering/P.A.C.E.
> San Jose, CA
> mailto:dfrance AT pacbell DOT net
> PACE - http://www.pacepros.com
> Bus-Ph: (408) 257-3037
>
>
> -----Original Message-----
> From: John Schneider [mailto:jdschn AT attglobal DOT net]
> Sent: Thursday, May 03, 2001 6:40 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: LTO restore performance - seek problem?
>
> Greetings,
> I have seen many posts on adsm.org about LTO, but none that
> addresses the problem I am seeing. Backup speed seems to be fine, at
> least as far as I can tell. But when I do a restore, I see a strange
> behavior. The restore seems to happen in bursts, where the restore
> pulls back files lickety-split for a awhile, then stops for 15-20
> minutes, then continues. I think that the wait is the seek from one
> spot on the tape to another. We have two tape drives in the IBM 3583
> library, and the problem seems to be happening on both of them. We
> upgraded to the 0CE1 version of the LTO microcode, but it has not
> improved things that I can tell.
> We restored 1.5 GB from our RS/6000 TSM server to a NT client, and
> it took 47762 seconds, or 13 hours. All the data was on one tape, so it
> is not a colocation problem. How long should it take an LTO drive to
> seek? I have done these sort of restores on DLT, and it can usually get
> from any place to any place on a tape within a few minutes. I expected
> LTO to be at least as good. A 13 hour restore is completely
> unacceptable.
> Any input or things to try would be appreciated. By the way, the
> TSM server is an RS/6000 F50 running AIX 4.3.3 ML4, with TSM 4.1.2. It
> is running atape 6.0.4, and atldd 4.1.5.0, which are both the latest, I
> believe. The NT client was TSM 4.1.2. Both are on the same switch on a
> 100MB Ethernet network, so I don't think the network is related in any
> way.
>
> TIA,
> John Schneider
>
> ***********************************************************************
> * John D. Schneider Email: jdschn AT attglobal DOT net * Phone: 636-492-0247
> * Lowery Systems, Inc.
> * 1329 Horan Disclaimer: Opinions expressed here are
> * Fenton, MO 63026 mine and mine alone.
> ***********************************************************************
--
With regards / Mit freundlichen Grüßen
With regards / Mit freundlichen Grüßen
Leopold Hameder
| Heinrich Bauer Produktions KG PSC | email: lhameder AT hbv DOT de |
| Abteilung Server & Concepts | phone: 040 - 3019 - 5675 |
| Burchardstr. 11, 20077 Hamburg | fax: 040 - 3019 - 5668 |
|
