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.