[Info-vax] OS implementation languages

[Craig A. Berry]

On 8/29/23 3:27 PM, bill wrote:
> On 8/29/2023 3:18 PM, Johnny Billquist wrote:
>> On 2023-08-29 19:25, Simon Clubley wrote:

>>> 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.
>>
>> What a weird question. VMS in itself don't have any limits. It's all 
>> always just about the hardware.
> 
> Not really.  VMS has always been notoriously slow with I/O and I assume
> that's what Simon was hinting at.

Right, and differently so for different kinds of I/O.  See posts from a
few years ago by (I think) Eric Johnson on performance testing of the
network stack.  And I wish I could remember the name of the guy who
posted about slow disk I/O even longer ago (Dave something?) including
code to do the testing.

VSI has canceled two different file system projects, one of which was
GFS and one of which was "not Spiralog" by Andy Goldstein (I don't know
if it ever had a name but Clair Grant posted here that it inherited some
concepts but was not the same thing as Spiralog). Something will have to
be done eventually for disk I/O, and while the file system isn't the
whole enchilada, it's certainly one big part of it.

The network stack improvements described here:

http://www.vmsconsultancy.com/download/NL-VMSUpdate-2015/Vienna%20LAN%20Performance%20Improvements.pdf

will hopefully be revisited at some point.  If they aren't, then VMS
will remain slower at network performance than other systems using the
same networking hardware.  I totally get why the port had to take
precedence for a small company, but holding the line is not the same
thing as moving forward.