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

[Johnny Billquist]

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.
>>
>> Arne
>>
>>
> 
> 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.

And Arne - I read the question as related to networks. Not hypervisors 
or virtual machines. 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.

Basically the same thing time sharing already did 50 years ago with 
computers. Everyone don't need their own computer. Most of the time the 
computer is just waiting on the user anyway, so the system can serve 
someone else meanwhile. VMs just take it up another level. But nothing 
really new.

   Johnny