Mark, as usual, makes an excellent point.  My premise for testing to $NULL is
that it shows what the upper limit is on extracting the data from the disks.
 The entire backup equation is made up of many variables, some of which Mark
just explained.  My point is you should not expect to be able to write to a
very fast tape device (DLT7000) at its design speed, if you cannot get the data
from the disk drives to match that "need for data" of that tape device.  This
is when multiple streams become important.  Multiple streams to multiple
devices or multiple streams to one device.

Kind regards,

Denys. . .

Denys Beauchemin
HICOMP
(800) 323-8863  (281) 288-7438         Fax: (281) 355-6879
denys at hicomp.com                             www.hicomp.com


-----Original Message-----
From:   [log in to unmask] [SMTP:[log in to unmask]]
Sent:   Saturday, 15 January, 2000 9:41 AM
To:     [log in to unmask]
Subject:        Re: testing of backup performance

Denys wrote:

>Your tests are very interesting.  They only show one side of the equation
>however.  You should try to do the same test but send the backup to $NULL.
>There are three/four components to a backup.  If the backup is to a local
>device, the three components are: the disk subsystem, the software and the
>backup device.  If the backup is to a remote device, the fourth component is
>the network itself.

To which Neil responded:

>A quick test to $NULL reveals that the system is capable of pushing out the
>data at 3589 K/S, so we have the potential to half our backup time, if only
>DDS4 or DLT/x was infinitely faster than DDS3...


While sometimes stores to $NULL are interesting, and answer part of the
equation, let's not forget that putting that infinitely faster DDS4 or
DLT on a loaded channel will have the opposite effect of what's intended.

In Neil's example, his system has the ability to PULL data from the disks
at 3589 K/S, but now writing that data back out to the target device must
be figured into the equation. Is that target device on its own channel
or does it share a channel? Is there CPU bandwidth available for software
compression (if that's to be used)? What queue is the backup process
running in as compared to other activity on the machine? Etc.

I've seen cases recently where adding a faster drive did not speed up the
backup because of I/O or CPU limitations. The becomes significant when
one considers that the 18 and 36 GB disk drives, while bigger, aren't
really faster, all things being equal.