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

[Jan-Erik Söderholm]

Den 2023-05-15 kl. 16:33, skrev Clair Grant:
> On Monday, May 15, 2023 at 10:16:42 AM UTC-4, Jan-Erik Söderholm wrote:
>> Den 2023-05-15 kl. 16:09, skrev Arne Vajhøj:
>>> On 5/15/2023 9:45 AM, Arne Vajhøj wrote:
>>>> On 5/15/2023 8:53 AM, Johnny Billquist wrote:
>>>>> On 2023-05-15 14:36, Arne Vajhøj wrote:
>>>>>> On 5/15/2023 8:20 AM, Simon Clubley wrote:
>>>>>>> On 2023-05-12, Arne Vajhøj <ar... at vajhoej.dk> wrote:
>>>>>>>> On 5/12/2023 1:30 PM, Simon Clubley wrote:
>>>>>>>>> On 2023-05-12, Dave Froble <da... 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?
>>>>>>>
>>>>>>> A type 1 hypervisor is still a software layer between the hardware and
>>>>>>> the RTOS. It would have to _guarantee_ that it would _never_ get in the
>>>>>>> way of the timing guarantees that a program running under a RTOS needs.
>>>>>>
>>>>>> It is software that is active between the VMS and the HW.
>>>>>>
>>>>>> But it is not obvious to me where any delay would come from.
>>>>>>
>>>>>> If we talk type 2 then it is easy to understand. You have a host
>>>>>> OS running 200 processes - 1 VM and 199 other stuff, and 4 CPU
>>>>>> so those 200 processes get scheduled on those 4 CPU's, and certain
>>>>>> interrupts may happen in the host OS. That VM will have
>>>>>> a problem providing real time capabilities.
>>>>>>
>>>>>> But in the type 1 with no over allocation of resources then
>>>>>> what will cause any delays? The VM got its own CPU or CPU's
>>>>>> that no other VM want, so I would expect the hypervisor to
>>>>>> keep them permanently allocated to the VM. And I don't
>>>>>> see the need for any interrupts in the hypervisor either.
>>>>>
>>>>> Can you guarantee that no interrupts happens on the CPUs the hypervisor
>>>>> is using? I would suspect "no", which means you do not have full control.
>>>>
>>>> What would those interrupts do?
>>>>
>>>> A type 1 hypervisor does not do that much.
>>>>
>>>> It has not very much in common with a type 2 hypervisor. I see it
>>>> as more of a software equivalent of system partitioning (DEC Galaxy,
>>>> IBM LPAR).
>>>
>>> As I don't know much about hypervisors and real time, then
>>> no need to take my opinion too serious.
>>>
>>> But one can look at the market.
>>>
>>> VMWare officially talks about real-time:
>>>
>>> https://docs.vmware.com/en/VMware-Edge-Compute-Stack/1.0/ecs-enterprise-edge-ref-arch/GUID-99972F62-3FAE-42B2-A850-66402274B616.html
>>>
>>> And a whole bunch of special type 1 hypervisors for real time usage exist:
>>>
>>> Wind River Helix - https://www.windriver.com/solutions/learning/hypervisor
>>> and https://www.windriver.com/products/helix
>>>
>>> RTS - https://www.real-time-systems.com/
>>>
>>> Acontis - https://www.acontis.com/en/acontis-hypervisor.html
>>>
>>> Some people besides me seems to think that VM and real time is possible.
>>>
>>> Arne
>>>
>>>
>> And I use to say that "real time" is worthless if you do not
>> specify what you mean with it. What are your expections?
>>
>> For a user standing with some I/O devices like a hand-scanner
>> and a label printer, "real time" can be "within 1-2 seconds".
>>
>> For a system talkning to some machinery, "real time" can be a
>> few 10's of milliseconds or even less.
> Of course you are right. My test did not prove anything. That was really stupid.

Maybe not stupid, but I'd say that it missed an important point. :-)

And I guess you are replying to my note about using the same system
to measure the systems own clock. It will always be "spot-on".
Not really my post about real-time...