[Info-vax] OS implementation languages

[bill]

On 8/29/2023 6:49 PM, Craig A. Berry wrote:
> 
> 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.
> 

Well, to be honest, is network performance really that important for the
things VMS is used for?  I doubt we are going to see a proliferation of
VMS run web sites.

bill