[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,

I am somewhat busy today, but the "With ethernet it was shown that it performs just fine up to
about 70-80% utilization." is somewhat apples/oranges.

You are correct that Aloha is the first, or at least the first well-known discussion of the phenomenon. However, the cited lecture notes miss several points.

- Aloha network nodes do not have guaranteed mutual visibility (a side effect of being radio-based on islands).
- The comparable Ethernet analysis presumes 10Base5 or 10Base2 coax with possible repeaters, not switches, with a network diameter maximum computer to guarantee that the signal of a transmitting node is detectable within the minimum packet size.

The presence of switches, which are inherently store-and-forward at a packet level, change the analysis dramatically. For the record, I recall that there were 10BaseT hubs, but the cost saving was not significant, so they are rare.

With care and careful design, one can get higher utilization, but that is a different story. For reference, look up Digital's CI, a higher performance CSMA/CD scheme, but with some twists to run at higher utilization percentages.

IEEE 802.11 (aka WiFi) is a different conversation altogether.

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