[Info-vax] OS implementation languages

[Johnny Billquist]

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