🚀 go-pugleaf

(...stuff deleted...)

>>"how fast is a TK70 drive?" (compared to other tape devices).

   Faster than a TK50 slower than a tu81+ or especially a ta78/79

>> 
>>Well, I have an excellent "benchmark" test, the results of which
>>follow.

   Just a thought, I think most benchmarks require that you have a 
fairly "controlled" environment.  In the case you presenet I think
most people's mileage will VARY greately.  ie. You can't control
90 Interactive users.

>> 
>>In short, I must first summarize WHAT i backed up, and what our system
>>configuration is:
>> 
>>Disk to be backed up:    RA81 contaning about 200,000 blocks of data
>>                         and over 15,000 files.  (it's my uucp disk......)
>>
>>How it was backed up:    BACKUP/LOG/IMAGE DISKNAME TAPENAME:SAVESET/SAVE
>>	  	         Job was processed on a standard (prior=3) batch queue.

   Okay, you are using the default block size for backup (unless you have 
IMAGE or LOG defined as a symbol to equate to /image/block=xxxxx).  If you
try 32768 I think you will find that you performance will improve.  Also,
You should be using the /buffers=N (4 or 5 is a good number), especially
with the TK70 (its a streaming tape drive).  You should also remember that
by using /log you are generating more IO's and those IO's don't actually
get issued until BACKUP knows that the data is on the tape.

>>
>>Devices backed up TO:    TA78 at 6250, and a TK70 drive.
>>			 (note:  TA78 is on a HSC50)

   Okay TA78 ~600 KB/sec  TK70 ~250KB/Sec flat out doing dumps from memory.
   VMS 5.1-1 backup performance will be about ~400 KB/sec max.

>>
>>System Configuration:     VAX 6320, 64MB, VMS V5.1-1, about 90 interactive
>>	   		  users were on at the time.
>>

   Well, letsee, 90 interactive users probably running at priority 4.  So,
   should any of them do anything compute intensive in the least then the
   jobs in the priority 3 batch queue will SLLOOOWWW down.  And, if there
   is anything in the batch queue itself which is running the both jobs
   will be competing for computes.  YOUR MILEAGE WILL VARY A GREAT DEAL
   HERE.  Try your benchmark during a quiet time on your system.

>>
>>here's the accounting summary of the TA78 tape backup:
>>
>>  BRODIE       job terminated at 19-SEP-1989 13:53:01.93
>>  Accounting information:
>>  Buffered I/O count:        33573      Peak working set size:   769
>>  Direct I/O count:          63666      Peak page file size:    2703
>>  Page faults:                 633      Mounted volumes:           1
>>  Charged CPU time:     0 00:13:00.24   Elapsed time:     0 00:46:15.17
>>

    Okay, that means you are getting roughly ~38 KB/sec. Yech.  I suspect that
    some of the interactive users WERE running compute-intensive jobs.

>>
>>.... and then here's the TK70 drive.
>>
>>  BRODIE       job terminated at 19-SEP-1989 12:59:05.11
>>  Accounting information:
>>  Buffered I/O count:        32876      Peak working set size:   804
>>  Direct I/O count:          62673      Peak page file size:    2703
>>  Page faults:                 614      Mounted volumes:           1
>>  Charged CPU time:     0 00:12:56.10   Elapsed time:     0 01:46:05.53
>>
>>

    hmmm...~13 KB/sec.  Again not a very pretty number.

>>Working set, page faults, and CPU time are all very close, however,
>>ELAPSED time is a little worse than I expected.   The TA78 took 46 minutes,
>>the TK70 took an HOUR and 46 minutes.   whoa.
>>  

    Well, CPU time should be consistent.  Backup has to work over the
same amount of data in each case.  I think that if you ran your benchmark
when there were no (or very few) interactive users and ran them at priority
4, and used a larger tape record, and had more IO's outstanding that things
would improve.  try this:

$backup/image/buff=5/block=32768/log diskname: tapedrive:foo.bck/save

Ideally you would can the log file, but it is nice to have.  Just make sure that
if you do /log it goes to a file NOT a terminal ('cause it will take forever then).

This information has been brought to you as a public service announcement.
No warranty is made by issuing this information.  Use at your own risk.

>>Kent C. Brodie	Systems Manager at Large - Medical College of WI

I like the system name moocow!!!

--
brad wherry                      uucp  ...!decwrl!starch.enet.dec.com!wherry
                                 inet  wherry@starch.enet.dec.com
                                 tel   508.841.2571 (w)
             Ex ignorantia ad sapientiam; e luce ad tenebras.

                      ***** Disclaimer *****

  These Views are my own, NOT DIGITAL's and should be construed as a position
  by the company either as support or offical decree.  They are provided for