On 2011-12-09 14:07, Chiravuri, Sri, GDH Consulting/US wrote:

Excellent point. If this is the case - saving same client/saveset twice
(in parallel) could also bounce the thruput up ?

George

Thx
Sri

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of Brian O'Neill
Sent: Friday, December 09, 2011 1:04 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Drive speed?

The slow speed on the one stream is likely because your client-to-server
data stream is below the minimum threshold of the tape drive to prevent
it from having to write, pause, back up, spin back up to speed, write,
pause, etc. So the total throughput you are seeing is low because of the
time spent not actually writing data to the tape.

The second stream brings your client-to-server data throughput over the
minimum of the drive, so the tape drive doesn't have to stop, rewind,
start again, lather, rinse, repeat.

Both streams should be benefitting - the first stream was penalized by
flow control while the server waited for the tape drive. Now it doesn't
need to.

On 12/9/2011 10:51 AM, George Sinclair wrote:

A basic question here on drive speed, but maybe not a simple answer as

there are undoubtedly numerous variables involved.

Let's say you have an LTO-4 drive (SAS connection to the tape library)

with a single stream (one save set) clocking in around 4-10 MB/sec,
coming in over the network. You then start another backup (also a
single
stream) from the same client to the same drive, and now it jumps up to
70+ MB/sec, and remains at that speed until that second save set
completes, and then quiets down to 4-10 MB/sec again. I've seen this
happen with a number of other streams, too, wherein running just one
of them from that same client, concurrent with the already running
stream, cranks the speed up considerably, until it's done, at which
point the original stream is reported again to be running at the same

slow pace.

We all know that a drive will come closer to performing optimally when

you can keep it streaming, and you can do that by keeping its buffer
full. OK, so having more concurrent streams - up to a point - will
improve drive performance, BUT does it affect the speed at which the
slow stream runs?

In other words, when the reported write speed jumps up to 70+ MB/sec
because you're now sending another stream (possibly one that
compresses well), is the original stream (possibly one that does not
compress so
well) now increasing its write speed as a result? Or is it instead the

case that while the drive is now functioning more optimally, and
writing more data per second, that first (slow) stream is still
clunking along at its original speed, and sending more streams will
not increase the speed of any one of them?

I'm inclined to think that the increase in speed is only affecting the

additional stream(s) and not that original one.

Thanks.

George

To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or via RSS at
http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

--
George Sinclair
Voice: (301) 713-3284 x210

- Any opinions expressed in this message are NOT those of the US Govt. -

To sign off this list, send email to listserv AT listserv.temple DOT edu and type 
"signoff networker" in the body of the email. Please write to networker-request 
AT listserv.temple DOT edu if you have any problems with this list. You can access the 
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER