[Info-vax] clock problems with OpenVMS x86 on VirtualBox

[Johnny Billquist]

On 2023-05-15 15:35, Arne Vajhøj wrote:
> On 5/15/2023 8:51 AM, Johnny Billquist wrote:
>> On 2023-05-15 14:03, Arne Vajhøj wrote:
>>> On 5/15/2023 6:17 AM, Johnny Billquist wrote:
>>>> On 2023-05-13 02:16, Arne Vajhøj wrote:
>>>>> On 5/12/2023 1:30 PM, Simon Clubley wrote:
>>>>>> On 2023-05-12, Dave Froble <davef at tsoft-inc.com> wrote:
>>>>>>> On 5/12/2023 8:14 AM, Simon Clubley wrote:
>>>>>>>> That's going to make for some "interesting" real-time program 
>>>>>>>> behaviour... :-)
>>>>>>>
>>>>>>> Do you think any serious real time programmer will run a real 
>>>>>>> time task inside a
>>>>>>> VM?  I'm not a real time programmer, and I'd still not do that.
>>>>>>
>>>>>> As well as traditional real-time stuff (which I agree with you 
>>>>>> about BTW),
>>>>>
>>>>> I would not want to do it on a type 2 hypervisor - there must be
>>>>> cases where what is happening on the host OS impact the performance
>>>>> of the guest OS.
>>>>>
>>>>> But with a type 1 hypervisor and no over allocation of resources -
>>>>> would it be worse than running on bare metal?
>>>>
>>>> For sure. You have no guarantee that you will get the CPU cycles 
>>>> when you need them. No matter what kind of hypervisor we're talking 
>>>> about, there is overhead in the host that can affect things way more 
>>>> than what might happen on bare metal.
>>>
>>> What host? A type 1 hypervisor does not run a host OS.
>>
>> Um? What is the hypervisor then?
> 
> The hypervisor software like ESXi.
> 
> It is not running on top of a host OS like a type 2 (VirtualBox etc.) does.

I never assumed you had a full OS. However, they Hypervisor is 
intercepting access to hardware, and is responsible for the actual 
interaction with the hardware, adding a layer between the guest OS and 
the hardware. Which means that the hypvervisor is in the end doing 
interrupt handling, for example. Which means that the CPU might be doing 
things that suspends the execution for the hypervisor outside the 
control of the hypervisor itself, and further more makes things like 
interrupts to the guest OS happen at some random later time, including 
clock interrupts, which are what affects things like real-time reponse 
times.

>>> And why would the CPU not be available, when there is no
>>> over allocation of resources? It seems pretty silly of
>>> the hypervisor to not want to give the CPU if no other
>>> VM can get it.
>>
>> Any kind of hypervisor means we're talking about virtualization. That 
>> means you have real hardware which exists outside of this 
>> virtualization. And that hardware can generate interrupts and demand 
>> service, which then forces the hypervisor to wait before it can 
>> actually get any cycles. Outside the control of the hypervisor...
> 
> Maybe. But what would that be?

Primarily I would be worried about interrupts, which introduce unknown 
amout of delay.

But yes, for things like memory, if it is fixed allocated to VM 
instances, and always available, then another potential source of delays 
are at least not there.

Depending on what the hypervisor does, you might still also have issues 
like page table caches, and normal memory caches, which will have rather 
different behaviors compared to plain hardware. Caches are a significant 
factor is performance these days.

   Johnny