[Info-vax] And another one bites the dust....

[Arne Vajhøj]

On 2/16/2022 12:53 PM, Johnny Billquist wrote:
> On 2022-02-16 17:32, Jan-Erik Söderholm wrote:
>> Den 2022-02-16 kl. 16:58, skrev Arne Vajhøj:
>>> On 2/16/2022 10:44 AM, Johnny Billquist wrote:
>>>> On 2022-02-15 18:21, Bill Gunshannon wrote:
>>>>> On 2/15/22 11:00, Jan-Erik Söderholm wrote:
>>>>>> Den 2022-02-15 kl. 16:46, skrev Bill Gunshannon:
>>>>>>> On 2/15/22 10:16, Dan Cross wrote:
>>>>>>>> In article <j71r42Fh9vsU1 at mid.individual.net>,
>>>>>>>> Bill Gunshannon  <bill.gunshannon at gmail.com> wrote:
>>>>>>>>> Maybe, but the push seems to be for virtualization and I saw a 
>>>>>>>>> number
>>>>>>>>> of OpenVMS job announcements that seemed to be production floor 
>>>>>>>>> systems
>>>>>>>>> which probably can't virtualized.
>>>>>>>>
>>>>>>>> Why not?  There are reasons to virtualize systems on-prem.
>>>>>>>
>>>>>>> I guess it depends on how you actually communicate with the
>>>>>>> devices on the floor.  When I think of production floor systems
>>>>>>> I think of cables between running machines and computers.
>>>>>>> Probably my PDP-11 past seeping through.
>>>>>>
>>>>>> Our VMS production support system only talks over the network.
>>>>>> Could just as well be in a VM as on the current Alpha.
>>>>>>
>>>>>
>>>>> I thought of that afterwards. I guess a  lot of it today is PLC's
>>>>> talking to the bigger iron over the network.  But that just leaves
>>>>> me wondering how one does realtime.
>>>>
>>>> Throw lots of hardware resources as the problem, and pray. That's 
>>>> what I usually see... Usually aided by the fact that a lot of 
>>>> situations isn't hard realtime.
>>>
>>> I would expect the real time characteristics to depend on the OS
>>> and the execution environment (read: if you want good real time
>>> characteristics then avoid GC) not virtualization vs non-virtualization.
>>>
>>> Assuming a type 1 (bare metal) hypervisor and no over-commitment of
>>> resources (aka number CPU's in VM's <= physical CPU's present), then
>>> I don't see how virtualization should be a problem.
>>
>> Right. We run "real time" against PLCs and have a round-trip time of
>> 10-20 ms including the database processing in the Alpha VMS system.
>> I do not expect that to be higher in a (modern) VM x86 environment.
> 
> Except of course if a packet is lost, which do happen. Then what?
> How soon will it be detected and retransmitted? Using TCP or UDP?
> Basically, throw lots of hardware on it, and pray? :-)
> Or it's not really hard realtime. If things occasionally go wrong, 
> nothing really bad happens.

For TCP the network software should detect and resend - for UDP the
application logic need to detect and resend.

Whether that delay is acceptable must depend on the specific case.

> And Arne - I read the question as related to networks. Not hypervisors 
> or virtual machines.

Well - it sort of started with virtualization (Bill) but has drifted
to network.

>                       But of course, we could also talk about those. Yes, 
> GC is an obvious bad thing. But how do you ensure that something is 
> scheduled within some limit when a hypervisor is doing things behind the 
> scene? What about interrupts and processing that happen on the physical 
> machine. That will have an impact on scheduling of virtual machines. And 
> resources are more than just pure CPU. Memory and I/O can also cause 
> impacts that affect other virtual environments running on the same host.
> Sure, if you make sure there are enough CPUs for each VM to have its 
> own, enough memory for each VM to ensure that they can run without 
> contention, and enough disks that each VM can have its own spindles, 
> then you can probably get close to ensured response times. But then you 
> are in fact actually having the number of machines again, and not 
> getting the economics of VMs, which are in fact designed to take 
> advantage of the fact that normally systems are not using all their 
> resources anyway, so you can share resources without negative impact.

It is obvious that one cannot share resources and not share resources at
the same time.

Not having to wait for shared resources means no over allocation of
resources.

But even with no over allocation then virtualization offers several
advantages in the form of increased flexibility:
- it just take a few minutes to provision a new system with whatever
   resources needed instead of having to order new server hardware
- hardware upgrades are a lot easier when one can just install the
   new hardware and then move the VM's over

Often there are even hardware resource savings. Because many system
require less resources than the smallest system the IT departments
favorite hardware pusher sell.

Arne