Xref: utzoo comp.realtime:7 comp.os.vms:14123
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!vrdxhq!daitc!daitc.daitc.mil
From: jkrueger@daitc.daitc.mil (Jonathan Krueger)
Newsgroups: comp.realtime,comp.os.vms
Subject: Re: Streaming tape drives
Message-ID: <508@daitc.daitc.mil>
Date: 6 May 89 19:54:35 GMT
References: <4374@ttidca.TTI.COM>
Sender: jkrueger@daitc.daitc.mil
Reply-To: jkrueger@daitc.daitc.mil (Jonathan Krueger)
Followup-To: comp.realtime
Organization: DTIC Special Projects Office (DTIC-SPO), Alexandria VA
Lines: 46

>In article <4374@ttidca.TTI.COM>, kevin@ttidca (Kevin Carothers) writes:
>...The best we did was maybe 35Kwords/Sec.
>The tape drive never went into "streaming" mode, and  we all just 
>kind of gave up.

>Does anyone out there know if this is even possible? We tried every
>conceivable buffering size, I/O mode, double-buffering schemes, etc.
>RSX is very (ok, somewhat) similar to VMS in philosophy (ie; DCL), and 
>the PDP and VAX have similar Command/Status/DMA register structure, so it 
>seems like *someone* in the VAX/realtime world would have come across this 
>problem before.

Based on a mild familiarity with a similar problem (getting TU80's to
stream under VMS on an 11/750) I'd say the problem is seeks, due to
directory lookups, possibly updating the date of last backup for each
file, and possible filesystem fragmentation on disk.  An excellent
DECUS presentation of several years back detailsed "the 10 laws of the
current state", several of which pertained to the need to avoid
unnecessary, inefficient, or badly timed I/O.  More generally,
realtime systems tend to require contiguous files to avoid seeks.  VMS
and RSX support contiguous files, but not contiguous filesystems, and
there's still the need to shuffle for directory lookups and possible
backup datestamping.  Some of this can be overlapped with tape writes
by buffering, but even an occasional wait loses the stream mode for a
while, causing more lost throughput than the wait itself.  And
ironically, the more successful you are at keeping the data flowing,
the more often you'll hit a necessary seek.

A brute force solution is a faster processor and asynchronous I/O;
thus the 750 could keep the TU80 in slow stream mode under standalone
backup.  When the 750 was timesharing, you couldn't do this, and the
TU80 in start-stop mode was pitifully slow.  Both the 750 and TU80
were reasonable devices, but they were badly mistuned for each other
for this application.  Another brute force solution was disk-to-disk
backups, then copying the save set to tape.  The save set was one
file, mostly contiguous, with no directory lookups or datestamps to
cut.  The cost of keeping an extra disk around for this purpose
outweighed any savings from buying the TU80.  Moral: a balanced
configuration has adequate memory, bus bandwidth, and disk capacity
for its processor, but also includes adequate backup capacity,
storage, i/o bandwidth, and acceptable degradation of system resources
during backup operations.  Also, realtime systems have learned some
lessons that may be applied to mundane needs of ordinary systems.

-- Jon
--