>
> reply to Robert Jarry-
>
> >I recently installed ADSM/6000 v2 on a RS/6K 590 with 256MB of memory and
> >one LAGO Datawheel (2 8mm 8500c tape drives inside). I configured ADSM for
> >backup only, no storage migration or archive.  I ran a full backup of one
> >800MB filesystem  which is on the server to get some idea of what the best
> >backup rate might be. It's taking almost 2 hours to backup only 800MB. I
> >currently am taking the installed defaults except for TCPBuffsize and
> >TCPWinsize, which I reset to the max values of 32 and 2048 respectively.
> >The transfer rate to the server is between 7000 kb/s and 8000kb/s.
>
> Have you defined a DASD storage pool as the first area that you backup to ???
> If you go directly to tape, your backup will be limited by the speed of your
> tape drives.  It is strongly recommended that  you have a "first level" dasd
> storage pool defined- usually large enough to hold at least one nights worth
> of Incremental backups (not the first full backup).  Then define that DASD
> pool to migrate (on a threshold value) to your tape pool.  This way, you are
> using the DASD pool to "buffer" your backups.
>

It's not necessarily tape speed that is your problem.  Even with some of the
older 8mm tape drives which are capable of 500 KB/sec transfer rate you should
get near 2 GB/hour throughput to tape.  The problem is with the way that
ADSM writes data in small packages.  8mm tape drives are built for streaming
data to tape, ADSM provides more of a start-stop-start data flow.  8mm
drives are notoriously bad at this.  They use helical scan technology, which
is similar to your home VCR.  Picture hitting your play and stop button each
time you send a packet of data, you know how long it takes on your VCR to
get a picture on the TV each time you hit play, the 8mm tape drive is doing
a similar task.

In your case Susan is probably right you may need to define a disk storage
pool as your first pool to go to.  However ADSM is slow on it's own and
we have not seen anything much over 2 GB/hour in 'effective transfer
rate' and that's with file sizes averaging 100+ KB.  'Effective transfer
rate' is much slower as average file size decreases.  I say 'effective
transfer rate' because I measure ADSM performance the way you do, total
number of bytes moved during the session divided by total time of the session.

A variable you may try setting (in dsm.sys on the client) is TXNBYTELIMIT.
Try raising it to the maximum 25600.  This sets the upper limit on how many
KB can be processed per transaction.  With this set you can do 25.6 MB a pop.
I don't remember what the default is.

Rich Campbell
System Software Analyst
Texas Instruments