[Info-vax] OS implementation languages

[Bob Gezelter]

On Thursday, August 31, 2023 at 1:45:56 PM UTC-4, Johnny Billquist wrote:
> On 2023-08-31 11:23, Bob Gezelter wrote: 
> > On Thursday, August 31, 2023 at 12:35:05 AM UTC-4, gah4 wrote: 
> >> On Tuesday, August 29, 2023 at 10:25:31 AM UTC-7, Simon Clubley wrote: 
> >> 
> >> (snip) 
> >>> 400GB/s ??? Is that all ??? Amateurs!!! :-) 
> >>> On a more serious note, I wonder what the maximum rate VMS is capable 
> >>> of emitting data at if it was using the fastest network hardware 
> >>> available. 
> >> I am not sure what hardware can do now. 
> >> 
> >> Traditionally, Ethernet was much faster than processors, such that the 
> >> shared media could handle the load. 
> >> 
> >> That is less obvious now, but a 400Gb/s network doesn't mean that one host 
> >> can go that fast. 
> >> 
> >> Otherwise, there are many stories of running old OS in emulation on modern 
> >> hardware, running into problems that never would have occurred years ago. 
> >> 
> >> One is that emulators often do synchronous I/O. The I/O interrupt occurs almost 
> >> immediately, as seen by the OS. Some OS assume that there is time in between. 
> >> 
> >> It is, then, possible that surprises will be found when running I/O at higher speed. 
> >> 
> >> It might be useful to say which host architecture you were asking about. 
> >> I am sure no-one thought about 400Gb/s Ethernet for VAX. 
> > gah4, 
> > 
> > Ethernet (and other CSMA/CD networking approaches) in a configuration with more than a single, full duplex connection connecting two adapters are essentially limited to a maximum effective utilization of 30% before contention backoff becomes unacceptable.
> Actually, that was/is a common misconception that still appears to be 
> around. With ethernet it was shown that it performs just fine up to 
> about 70-80% utilization. 
> 
> The 30% is basically what you see with Aloha based communication. 
> However, Ethernet is not really like Aloha. The point being that once 
> the initial 64 bits have been transmitted, noone else is going to start 
> transmitting, so no collision will happen after that, and the full 
> packet will go through. Basically, ethernet is based on listen before 
> starting transmit, while Aloha do no such thing. 
> 
> You can find some math behid this on 
> https://intronetworks.cs.luc.edu/1/html/ethernet.html for example. But 
> you should be able to find more articles about this if you search around.
> > Active switches, as opposed to hubs, can increase this threshold as each cable is physically connected to an interface and a switch port.
> Yes. With TP and switches on ethernet, every connection is contention 
> less, and the only problem is that switches have finite resources, and 
> if many ports want to talk towards a specific port, that will be 
> saturated, and packets will have to be dropped. But you will be able to 
> get to the nominal speed of the port at least.
> > Instant I/O completion has uncovered all manner of bugs and deficiencies over the years. Most such problems are at the driver level, where a driver fails to ensure that data structures are correctly prepared for an immediate interrupt when the "Go" bit is triggered. On occasion, an application has been written to run very I/O bound with the presumption that I/O delay will slow it down, e.g., OpenVMS COPY, RSX-11 PIP, linux dd. Combine a greedy application with a high dispatch priority and voila, monopolized machine for the duration. On OpenVMS, put a process at a base priority above most users, say 6-7, and run a large COPY from one instantaneous mass storage device to another. Other users see an effectively dead machine.
> True. Most of the time I don't think there are many problems with I/O 
> completing immediately (there is one known such problem in RSX, and that 
> is the console terminal device driver that gets the data reversed if 
> interrupt happen immediately). But starving other processes for 
> resources when I/O completes immediately is definitely a thing in almost 
> any OS.
> > Virtual machine-level synchronous I/O is a gargantuan performance impediment on many levels. My aforementioned Ph.D. dissertation on I/O performance, one of the main conclusions was that unnecessary serialization at any point in the I/O stack was a performance cliff. Serialization obstructs lower-level optimization and workload management. The mathematics could not be more definitive.
> Yes. And I'll just reflect from an RSX point of view here, since I'm so 
> intimately aware of the innards there. RSX actually have very little 
> serialization in most places. The system is very asynchronous in its 
> core design. Which is utilized by drivers and software to allow hardware 
> to reorder operations when it want to, since hardware can do this better 
> than software most of the time. But reordering also in software is 
> something that RSX can do. But for the MSCP device driver, for example, 
> software reordering is disabled, because it just lets the hardware do it 
> instead. And requests from programs can easily be asynchronous as well. 
> In fact they always are, but programs can request to wait for the 
> completion if they don't want to do something else meanwhile. But lots 
> of programs do make use of this possibility, since the CPU wasn't that 
> fast to begin with, so you were often very interested in ways to get 
> more performance out of your software, and having I/O going on in the 
> background was the most obvious way to improve. 
> 
> VMS inherited much of the design around this from RSX, so much is the 
> same. But of course, with more resources, less effort was put into 
> making use of such contructs. After all, it takes more work to write and 
> ensure it works right. 
> 
> Johnny
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.

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.

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.

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. 

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.

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