On Tuesday 13 December 2011 15:43:13 Josef Weingand wrote:
> Hi,
> you are right that LTO4 drives are slowing down the speed to 40 or 30
> MB/sec. Below this speed the drive will start/stop (shoe shining), however
> this will not impact your performance. Because the LTO drive, at least the
> IBM LTO drive has a 256 MB Buffer. During the start/stop, repositioning,
> show shining the server/client writes the data to the buffer. With an 256
> MB Buffer you can write with 40 MB/sec up to 4 sec to the buffer. The shoe
> shining / repositioning takes less the 4 sec.
Hmm,
Say we are slowing down to 30-40 MB/s writer speed. Then we are using 1-2 sec
for reposititioning + 4 secs to empty the buffer. That means that we are using
20-30% of that 30-40 MB/s for not doing writes. Which again gives us a write
speed of 20-30MB/s when shoeshining. Admittedly higher than the reported 11
MB/s, but still close enough. Adding compression to the equation will probably
make the situation worse.
And anyway this is not good for the drive or the tape.
So. yes the buffer helps, but doesn't get rid of the problem.
Best
Dag
> fredag 09 december 2011 17:51:36 skrev George Sinclair:
> > 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.
>
> This seem to be a typical example of dropping the drive below streaming
> speed.
> The LTO-4 has a native speed of 120 MB/s. The LTO technology can provide
> for
> slower "feeding" speeds than that by slowing down the reels, but only down
> to
> 1/4 of the max. That will give us about 30 MB/s as the minimum ingestion
> speed. Below that the drive starts "shoeshining" heavily and that is a
> killer
> for the performance. Compression on the drive will increase this minumum
> by
> the compression ratio, which again is depending on the compressability of
> the
> data.
> As the number you gave falls exctly into these figures I think this is
> what is
> happening.
> If you have access to the drive you can easily verify by listening to it
> :-)
>
> Best
> Dag
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
|
