info-vax@ucbvax.ARPA (05/30/85)
From: Jacob Moskowitz <JMSK@MIT-MC.ARPA> We're having a lot of trouble sustaining high speed (200 kbytes/sec) transfers to either an RA-80 or an RA-60. Does anyone have any suggestions about what we might be doing wrong ? The transfer (data acquisition from a Digital Sound Corp A/D converter) never gets beyond 26000 blocks, though the file is contiguous and has much more than that allocated. We're actually running RSX on an 11-34, but I suspect that's not too remote from a VAX, since both use the Unibus. We use QIO's and double buffering. Is there a PDP-11 mailing list ? DSC is no help, having lost all their technically competent people. Thanks for any help any of you can provide.
info-vax@ucbvax.ARPA (05/30/85)
From: ulysses!mhuxr!mhuxt!houxm!hou2d!afb3@BERKELEY I used to achieve approx. 300k bytes/sec on an RM02 (32 sectors per track, 2400 RPM) with abuffer size of 8192-16384 bytes and using FCS block I/O (not QIO's!!!!!). The result is read one buffer (in one revolution), miss a revolution, read one buffer). This assumes that the "real-time" I/O is the only activity on the disk, the file is preallocated and contiguous, and NOWRITECHECK is enabled. These assumptions cause the head arm to be on track/on cylinder after the first I/O, with only track to track seeks as we go. The RM02, however, is an ordinary, vanilla, normal type disk. The RA80/60/81's have a different layout and "automatically" relocate bad sectors. Good for systems, bad for realtime.... The killer is the transparent seeks that might occur. Also, even if the controller does it, writecheck will killyou everytime.... If you are running standalone and with WRITECHECK disabled, you might try different packs in you RA60 or allocate different files on the same disk and try them...(using different LBN's on the disk should cause different bad block mapping by the UDA..) One more thought. If you contend with one (1!!!) other task doing I/O on the disk, your effective thoughput would drop to the 100K+ level. (avg. seek + avg. latency + read/write time)/2..... You get one I/O, he gets one, you get one, he gets one... Sicking isn't it. I played with this nonsense for 5 years on an 11/55 with great success (and alot of fun!!) doing large (2k X 2k) matrix problems. It works like a camp if the controller doesn't out smart you. Al Baldwin AT&T-Bell Labs ...!ihnp4!hou2d!afb3 [These opinions are my own....Who else would want them!!!]
info-vax@ucbvax.ARPA (07/01/85)
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.