HP3000-L Archives

May 2000, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Carl McNamee <[log in to unmask]>
Reply To:
Carl McNamee <[log in to unmask]>
Date:
Mon, 22 May 2000 11:33:03 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (79 lines)
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.

ATOM RSS1 RSS2