We are going to do some direct-to-tape performance testing, but it could
very well be that we just can't pump data out to the drives fast enough to
keep them spinning with a single-stream.

I've done many tests, to maximize the throughput to an LTO3 tape, you need 
at least 3 streams.

Three streams directly from RAM = 137MB/s, which is the max some companies 
have also gotten in their private testing labs.  One stream, even from RAM 
will only yield 30-50MB/s.

Justin.

On Tue, 19 Sep 2006, Liddle, Stuart wrote:

> The read speeds are obtained from an average of all of the duplications that
> have been done over a 48 hour period.  If I go back 1 week, it turns out to
> be something like 80MB/sec average with peaks of 150MB/sec.
>
> We are going to do some direct-to-tape performance testing, but it could
> very well be that we just can't pump data out to the drives fast enough to
> keep them spinning with a single-stream.
>
> --stuart
>
> -----Original Message-----
> From: Peter DrakeUnderkoffler [mailto:pcd at xinupro.com]
> Sent: Tuesday, September 19, 2006 10:09 AM
> To: Liddle, Stuart
> Cc: Paul Keating; veritas-bu at mailman.eng.auburn.edu
> Subject: Re: [Veritas-bu] LTO3 throughput on Vault/Duplication jobs
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> You then need to test each component individually if you don't know
> where your bottleneck lives.  There are many ways to test tape drive
> throughput
> from a media server.  Simple dd or tar commands and all the way up to
> bpbkar.
> When you quote your read speeds of 130mb/sec, is that during a restore
> process through netbackup?  If so and there is multiplexing, make sure
> your restore test is big enough to get a valid sample size.
>
> Thanks
> Peter
>
> Peter DrakeUnderkoffler
> Xinupro, LLC
> 617-834-2352
>
>
>
> Liddle, Stuart wrote:
>> I think we are licensed per TB on the VTL?.not per drive.
>>
>>
>>
>> Our rationale in doing the multiplexing to the VTL was to increase
>> throughput to the VTL for backups.  We CAN increase the number of
>> virtual drives instead and then do single streams to the VTL and avoid
>> the de-multiplexing during the duplication step.
>>
>>
>>
>> However, we are seeing lightning-fast read speeds off of the VTL
>> regardless of the fact that it is multiplexed (around 130MB/sec).
>>
>>
>>
>> So, I?m still concerned about the speed with which we write out to the
>> physical tapes?..not sure where the bottleneck is?but there definitely
>> is a bottleneck.
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> *From:* veritas-bu-bounces at mailman.eng.auburn.edu
>> [mailto:veritas-bu-bounces at mailman.eng.auburn.edu] *On Behalf Of *Paul
>> Keating
>> *Sent:* Tuesday, September 19, 2006 8:49 AM
>> *To:* veritas-bu at mailman.eng.auburn.edu
>> *Subject:* Re: [Veritas-bu] LTO3 throughput on Vault/Duplication jobs
>>
>>
>>
>> My thought's exactly JR.
>>
>>
>>
>> I'm thinking folks either have VTLs where they are licensing from the
>> vendor on a "per virtual drive" basis, OR, they are licensing Netbackup
>> on a (old) per drive, rather than (new) per TB of usable disk basis, so
>> want to avoid the licensing cost of adding more virtual drives......that
>> was on of my primary criteria in selecting a VTL....I want to be able to
>> create as many virtual drives as I want.
>>
>>
>>
>> I currently have 20 physical drives, and run various multiplex levels
>> for different STUs, depending on the type of backup, in order to
>> maintain sufficient data flow to stream the drives, but when the VTL
>> comes into play, I want MPX=1, so I'll be configuring upwards of 20
>> virtual drives per media server.
>>
>>
>>
>> Paul
>>
>>
>>
>>
>>
>> --
>>
>>     -----Original Message-----
>>     *From:* Dyck, Jonathan [mailto:Jonathan.Dyck at cognos.com]
>>     *Sent:* September 19, 2006 10:09 AM
>>     *To:* Paul Keating; Liddle, Stuart; veritas-bu at mailman.eng.auburn.edu
>>     *Subject:* RE: [Veritas-bu] LTO3 throughput on Vault/Duplication jobs
>>
>>     Agreed.  Coming from an environment where we are "afraid" of
>>     multiplexing everything due to those image's importability (or lack
>>     thereof), the fact that we cannot demux quick enough has us
>>     handcuffed a little.
>>
>>
>>
>>     Just a question, what's the rationale on mpx'ing to your VTL's?
>>
>>
>>
>>     Cheers,
>>
>>     Jon
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Veritas-bu maillist  -  Veritas-bu at mailman.eng.auburn.edu
>> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (FreeBSD)
>
> iD8DBQFFECQ1l+lekZRM55oRAni8AJ91fyyqTD2CrIZLLWRMfeVPu0NVNACdFaHD
> dgliOvTDWXsWlH8eXzhVg3M=
> =RJAg
> -----END PGP SIGNATURE-----
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu at mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>