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

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