Carl,

Even with TurboStore you should be able to get better performance.  But
you've got to keep the DLT moving and data flowing to it at all times.

This generally means that the DLT should be on its own FWSCSI adapter,
and if possible on a different bus converter than the bulk of your disk
drives.

Don't expect to get fast online backups with a 957, if you have other
batch processing going on at the same time. By todays standards a 957
has a very limited (amazing isn't it) CPU bandwidth, it could actually
become a bottleneck slowing your backup.  I've seen online backups at
night almost consume once CPU by themselves... and all the disk lights
thrashing as the data is moved to tape.

If the bulk of your disk drives are 2MB-5MB/second drives, you can't
expect to keep the DLT running at 10-15MB/s.  The hold SE-SCSI drives
typically are 5MB/s or less.

Carl McNamee wrote:
>
> Guess I should have stated that all the results I quoted were from Turbo
> Store.  Third party products will be another animal entirely.
>
> Thanks for squaring that up.
>
> Carl
>
> -----Original Message-----
> From: [log in to unmask] [mailto:[log in to unmask]]
> Sent: Monday, May 22, 2000 11:20 AM
> To: [log in to unmask]; [log in to unmask]
> Subject: Re[2]: DLT Questions
>
> Carl writes:
>
> >My experience has been, on systems ranging from a 930/020 to a 997/800,
> that
> >MPE cannot take full advantage of any tape device faster than a DLT4000.
> >There is some limitation within MPE/hardware that bottlenecks the i/o at
> >around 5 Meg per second.  You can test this theory on your system by doing
> a
> >backup to $NULL and then checking the through put portion of the statistics
> >listed at the end of the backup.
>
> <semi plug alert>
>
> I need to clarify this a bit ... MPE is capable of better performance, but
> that
> is based upon a number of factors such as configuration, mix of devices on
> the
> SCSI bus, number of bus converters, etc. The problem you're seeing is most
> likely not an MPE problem per se:
>
> Here is a store to $NULL of a 51gb file using Backup+. This system is a
> 989/200:
>
> >:file z=$null
> >:listf large01.prodgp01.abstesta,11
> ACCOUNT=  ABSTESTA    GROUP=  PRODGP01
>
> Name     Access FCode RecSiz Type            EOF    File Limit Disk Usage
> Exts
> --------  ERWS  ----- ------ ----- ------------- ------------- --------KB
> -----
>
> LARGE01                  256 FB        210000000     210000000   52500000
> *****
> >store large01.prodgp01.abstesta;*z
> Building intermediate scratch files ...
> Selecting files for store ...
> 1 files scanned ...
> 1 files - 210000000 sectors (50.07 gigabyte(s)) of disc space to store
> Optimizing selected file information for faster backup ...
> Storing selected files ...
> Store is 100% complete
> ..
>   total amount of disk space stored: 210000000 sectors (50.07 gigabyte(s))
>         total number of tape errors: 0 + 0 errors in store directory
>        total number of tape retries: 0 + 0 retries in store directory
> This store took 18 minutes, 10 seconds
>
> Note this took 18 minutes as a store to $NULL. That indicates an aggregate
> throughput of more than 5MB second, so the problem isn't MPE.
>
> We can store the same file to a DLT8000 in two hours. Also note that our
> configuration is not optimized for performance ... we have a number of 36gb
> disks used for our test environment and this doesn't allow the benefits
> of overlapped IO that would happen when using a larger number of smaller
> disks.
>
> BTW - we did a performance test recently that can be independently
> confirmed where we were able to achieve a throughput of over 1gb
> per minute to a single DLT8000. That machine was a 997/12 way with
> 30+ spindles of 4gb each, spread over two bus converters. The DLT8000
> was the only device on it's SCSI channel.
>
> As always, YMMV.