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

[Johnny Billquist]

On 2023-05-12 01:02, gah4 wrote:
> On Saturday, May 6, 2023 at 9:49:43 AM UTC-7, Craig A. Berry wrote:
>> I am running OpenVMS x86_64 E9.2-1 under VirtualBox 7.0.8 on macOS
>> Ventura 13.3.1 (a). The host is a 2019 MacBook Pro with 2.3 GHz 8-Core
>> Intel Core i9. The clock isn't working right, most easily seen by the
>> fact that the following two commands were typed exactly one minute apart:
>   
>> $ sh time
>> 5-MAY-2023 19:07:35
>> $ sh time
>> 5-MAY-2023 19:07:45
>   
> I haven't thought about this recently.
> 
> As well as I know it, many OS were designed to know about emulators,
> and virtual machines, and virtual machines to know about client systems.
> 
> The OS should be able to request the right time from VirtualBox.

That is something you could/would do at boot time to get initial time, 
but not after that.
During normal operation, most OSes uses a clock interrupt at a known 
frequency, and this is in turn used to update the wall clock in the OS. 
There are some tickless operating systems - mostly embedded RTOS stuff 
where you want to reduce power consumption, but otherwise this is how 
you normally do stuff, since you want to schedule all kind of things 
based on time, and it would make no sense to have a VM go out and read 
the host time hundreds of times per second as a way of just polling to 
get time.

But here is where and why you can observe time drift. In real hardware, 
this clock interrupt is very regular and reliable. In an emulator, you 
are exposed to the timing variations caused by the scheduling of the VM 
itself, which means you cannot deliver clock interrupts anywhere near at 
the same level of accuracy as hardware can.

VMs thus usually try to detect drift over time, and compensate by 
fielding extra clock interrupts to "catch up", so that over a longer 
period, you still have the correct number of interrupts happening. But 
this is a bit tricky, and VMs sometimes don't do this perfectly.

But it should normally only expose small variations in the clock 
compared to a proper wall clock.

If you see a much slower progress of time (or faster) than the wall 
clock, then the VM is probably generating clock interrupts at a 
different frequency than the OS is expecting.

> Note that IBM S/360 and successors have a convenience for emulation.
> OS enter a wait state, when there isn't anything else to do. They stop executing
> instructions, and so there is no idle process.

Well, there usually still is an idle process, or loop, but it's not 
doing a busy-wait spin loop.

> Many emulators and hypervisors recognize the idle loop, though.
> 
> How does VMS keep track of time?

Same as pretty much anything else. You have a clock interrupt at a 
regular interval and the OS counts time based on that.

VMS started off on the VAX, however, and that architecture do not have a 
WAIT instruction, so at idle, the processor is really just spinning.
Not sure if that was amended on Alpha or later.

But a WAIT is commonly only stopping the processor until something 
happens, which usually is an interrupt. If there is still nothing to do 
after the interrupt handler finish, the processor would loop back to the 
WAIT again.

simh (for example) do detect the idle loop in VMS (on VAX), and pause 
execution if it detects this loop, to let the host rest.

   Johnny