OK....we have MPX=6 for the VTL, so it looks like we would be getting about
maybe 21MB/sec according to what you are saying.....right?

 

  _____  

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 10:38 AM
To: veritas-bu at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] LTO3 throughput on Vault/Duplication jobs

 

 

Stuart, 

 

Yeah, you're right, you're reading off of the VTL at 130MB/s, but if you're
reading from a multiplexed (virtual)tape, and your MPX=10, and you're
DEmultiplexing during the dupe, then only 1/10th, or 10% , or ~13MB/s of
that data is relevant to the image you're writing to tape, so your
throughput to the tape would be ~ 13MB/s

 

Make sense?

 

In essense, if you have MPX=10 on your VTL, you need to read the data from
VTL 10 times faster than you're writing to tape.

 

if you "preserve multiplexing" or if you use MPX=1 (off), then your VTL read
and tape write should be symmetrical.

 

with VTL and "virtual" drives, you can create 10 virtual drives and set
MPX=1, or create 1 virtual drive with MPX=10, and get the same overall
performance....without the duplication hassle.

 

 

Paul

-- 

-----Original Message-----
From: Liddle, Stuart [mailto:liddles at amgen.com] 
Sent: September 19, 2006 12:27 PM
To: Paul Keating; veritas-bu at mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] LTO3 throughput on Vault/Duplication jobs

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20060919/315c4c9d/attachment.html