[Info-vax] OS implementation languages

[Johnny Billquist]

On 2023-08-30 15:02, Dan Cross wrote:
> In article <uclgav$q0b$1 at news.misty.com>,
> Johnny Billquist  <bqt at softjar.se> wrote:
>> On 2023-08-29 19:25, Simon Clubley wrote:
>> [snip]
>>> 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.
>> Some software might be able to squeeze more out of the same hardware,
>> but just spin up faster hardware, and you'll get higher throughput. But
>> any system will basically just be limited by the speed of the network
>> hardware, if that item is fixed. You can't go above that. But there are
>> no reasons why you wouldn't be able to get to that point.
> 
> I don't really understand this line of reasoning.  At some point
> you're running on the fastest hardware available; at that point,
> what do you do?  It seems perfectly reasonable to try and
> quantify the overhead due to the software stack, and if possible
> to optimize it, particularly if your chosen software platform
> can't saturate the NIC at line rate.  And even if it can, if it
> requires all of the CPU resources on your machine to do so, then
> you're starving the platform for cycles that would otherwise go
> to the software that all of those hungry network clients want to
> talk to.

But that is a different question. We are not talking about maximising 
the amount of work done over some time (with whatever unit of 
measurement of work we might be using).

The question was "I wonder what the maximum rate VMS is capable of 
emitting data at if it was using the fastest network hardware available"?

And the answer to that will end up - the speed data can be delivered by 
that network hardware.

Now, if you instead want to talk about how cost efficient it might be, 
or what the user experience for 100 users sitting trying to do 
interactive editing on the machine at that same time, then we might have 
more things to talk about. But that was not the question.

> "Throw more hardware at it" works well until it doesn't, and
> when that happens you've hit a wall that you have to get around
> some other way.

Well. Then ask a question about that.

   Johnny