[comp.sys.dec] How to get best Ultrix TK70 back-up performance over Ethernet?

D. Allen [CGL]) (09/19/89)

Consider a vs3100 and a vs3200 on an Ethernet, both running Ultrix 3.0,
soon to be Ultrix 3.1 (UWS 2.1).  The vs3200 has the TK70 tape drive.  I
tried the following to back up 119 Mb from an rz55 on the vs3100 to the
TK70 on the vs3200:

    vs3100# rdump 0f vs3200:/dev/rmt0h /dev/rrz1c

      - estimated 8 HOURS to write 119 Mb to the TK70

    vs3100# dump 0f - /dev/rrz1c | rsh vs3200 exec dd bs=20k of=/dev/rmt0h

      - estimated 22 MINUTES to write 119 Mb to the TK70

Surely there must be a way to get rdump to do better than 8 HOURS for
100 Mb?  Enlighten me.  I would have thought rdump and rmt would be
able to pick the fastest way without my help; I must be very wrong.
-- 
-IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu
 129.97.128.64    Computer Graphics Lab/University of Waterloo/Ontario/Canada

envbvs@epb2.lbl.gov (Brian V. Smith) (09/20/89)

In article <11523@watcgl.waterloo.edu>, idallen@watcgl.waterloo.edu
(Ian! D. Allen [CGL]) writes:
 
< Consider a vs3100 and a vs3200 on an Ethernet, both running Ultrix 3.0,
< soon to be Ultrix 3.1 (UWS 2.1).  The vs3200 has the TK70 tape drive.  I
< tried the following to back up 119 Mb from an rz55 on the vs3100 to the
< TK70 on the vs3200:
< 
<     vs3100# rdump 0f vs3200:/dev/rmt0h /dev/rrz1c
< 
<       - estimated 8 HOURS to write 119 Mb to the TK70
< 
<     vs3100# dump 0f - /dev/rrz1c | rsh vs3200 exec dd bs=20k of=/dev/rmt0h
< 
<       - estimated 22 MINUTES to write 119 Mb to the TK70
< 
< Surely there must be a way to get rdump to do better than 8 HOURS for
< 100 Mb?  Enlighten me.  I would have thought rdump and rmt would be
< able to pick the fastest way without my help; I must be very wrong.

The problem is that rdump doesn't use multiple buffer write to the tape,
so the TK50/70 doesn't have a chance at streaming.

dd and tar do use the multiple buffer scheme, so until DEC changes
rdump to do this I would never consider using it.

_____________________________________
Brian V. Smith    (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.