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

[Johnny Billquist]

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?

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

   Johnny