Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/15/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!info-vax
From: info-vax@ucbvax.ARPA
Newsgroups: fa.info-vax
Subject: Re: High speed data acquisitions to RA disks
Message-ID: <8662@ucbvax.ARPA>
Date: Mon, 1-Jul-85 01:32:13 EDT
Article-I.D.: ucbvax.8662
Posted: Mon Jul  1 01:32:13 1985
Date-Received: Tue, 2-Jul-85 04:43:38 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 21

From: goldstein%star.DEC@decwrl.ARPA  (Andy Goldstein)

Sorry this reply is so late in coming; I only get around to reading
INFO-VAX once in a while.

Jacob Moskowitz's inquiry about getting 200kb performance on an RA60
set off some very old bells. The limit of 26000 blocks is significant.
That's the amount of file space that can be mapped in a Files-11 V1
(the Files-11 supported in RSX) file header. My memory of the RSX file
system is a bit foggy, and potentially out of date, but as I recall,
only one file header's worth of map pointers can be represented in
a file window at a time. Thus, as you cross the 26K boundary, the I/O
request gets sent to the file ACP for a window turn, who must then
take a trip off to read the file header. This obviously puts a big
hole in your throughput at that point.

The only way around this problem is going to be to add additional
buffering depth in your application so that it can absorb the hit.
That's probably a good idea anyway because of the potential bad
block revectoring that the RA60 can do to you, mentioned in a
previous reply.