[Info-vax] OS implementation languages

[Bob Gezelter]

On Friday, September 1, 2023 at 5:45:41 PM UTC-4, Johnny Billquist wrote:
> On 2023-08-31 21:12, Bob Gezelter wrote: 
> 
> > Johnny, 
> > 
> > You are correct that much of the I/O plumbing is highly similar in RSX and VMS, and for that matter WNT. A case of common authorship.
> Yeah... :-)
> > To understand the issues fully, one has to think not just linearly, but also carefully consider the timeline and other time-related issues. There are many conceptual traps.
> True.
> > However, file I/O has an explicit serialization: virtual to logical block mapping. The original I/O packet is reused iteratively to process the potentially discontiguous logical blocks required. This imposes a serialization that is not conducive to performance. There is an extended description and analysis in my dissertation/monograph; a somewhat abbreviated version of which is in the previously referenced IEEE conference paper.
> In RSX atleast, this isn't neccesarily true. Both with FCS and RMS, they 
> offer the capability of read-ahead in a completely transparent way for 
> the application. And they do this by issuing multiple QIO in parallel, 
> so there are multiple I/O packets in flight. 
> But the mapping between virtual and logical blocks are happening in 
> F11ACP, which is a chokepoint. But because of this, for an open file, 
> the mapping from virtual to logical blocks can actually happen in the 
> kernel without involving the ACP, when the mapping is already in memory. 
> So the first read will stall until the mapping have been read in, and 
> then continue finding the translation and issuing the read of the proper 
> logical block. The next I/O that comes right on the heels of the first 
> one (as well as the third) will hopefully do the translation without any 
> I/O involved, and the read for the correct logical block will be queued 
> up to the driver before anything have been completed. And then the 
> driver immediately places the requests on the queue of the controller, 
> who then can both work on doing them in the optimal order, and the 
> completion is going to happen in some random order. However, as soon as 
> the read for the first virtual block is completed, FCS (or RMS) will 
> return operation to the program that is reading the file. Meanwhile in 
> the background, while the program is operating, the other I/Os will also 
> eventually complete, so by the time the program's reading progress to 
> those blocks, they are already in memory. And in the background, FCS (or 
> RMS) will already have issued additional reads for more blocks while the 
> program was doing its work. 
> 
> But this is RSX. Details on how much of this also is done in VMS I don't 
> know.
> > If one looks for correlations of logical block requests, the most common correlations are requests to the same file on the same access stream. Ibid. Sequential reuse of the same IO packet prevents optimization within a request stream. 
> > 
> > Hardware reordering can only reorder requests that are simultaneously outstanding. Ibid. 
> > 
> > The RSX design was obligatory due to the then lack of system pool. Then, even individual IO Packets were precious. Correctness beats efficiency. For more than two decades, increases in memory capacity and non-paged pool expansion has rendered the memory minimization design goal quaintly anachronistic.
> Well. Like I said above, RSX actually is somewhat eager to do this. 
> Especially on 11M+, which do have a bit more resources available. In 
> plain 11M, you didn't see this done as much, since resources were more 
> scarce.
> > The preceding is all in the reprint. A thorough reading of the referenced paper is highly recommended. When I can find the time to finish copy-editing the monograph and get it printed. I will note the general availability in a posting.
> And if you want more deep diving into RSX, just let me know. I'll 
> happily guide you through it. But it will be lots of MACRO-11. ;-) 
> 
> Johnny
Johnny,

I still have my RSX-11M listings from Version 3.2. I was one of the systems programmers on our PDP-11/34, did quite a bit of driver architecting and writing. Also the first person outside RSX Engineering to write a queue manager symbiont (uncovered a nasty synchronization design flaw).

MACRO-11 was my fourth assembler language. 

- Bob Gezelter, http://www.rlgsc.com