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

[Craig A. Berry]

On 5/6/23 11:49 AM, 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
> 
> So the system advances its clock about 10 seconds for every 60 seconds
> of actual time.
> 
> Another way of illustrating the problem is by running the vups.com from
> <https://emuvm.com/download/vups-com-benchmark/>, which says:
> 
>   Approximate System VUPs Rating : 10430.2 ( min: 950.4 max: 55125.0 )
> 
> Divide that number by 6 and it might almost be credible based on numbers
> other people have been posting, though a factor of 10-15 would be more
> believable.  The system is *not* in fact fast at all -- it takes about
> 15 seconds for MONITOR SYSTEM to initiate its display when nothing at
> all is running.
> 
> I have not seen this anywhere in the VSI documentation, but this blog post:
> 
> <https://raymii.org/s/blog/OpenVMS_9.2_for_x86_Getting_Started.html>
> 
> says it's necessary to set the clock characteristics of the virtual
> machine like so:
> 
> $ vboxmanage modifyvm <vmname> --hpet on
> 
> I have done so but observe no difference (everything posted above was
> after running this command and restarting VirtualBox).  Supposedly this
> setting "Enables . . . a High Precision Event Timer (HPET) which can
> replace the legacy system timers," whatever that means. I guess one
> possibility is that the command, while it returned no errors, also
> didn't take effect for some reason.  I cannot tell from the following
> output whether the non-default setting is in effect:
> 
> $ vboxmanage debugvm <vmname> info hpet
> HPET status:
>   config=0000000000000003     isr=0000000000000000
>   offset=fffffff020435102 counter=0000000000000000 frequency=69841279 fs
>   legacy-mode=on   timer-count=4
> Timers:
>   0: comparator=0000001022973a28 accumulator=0000000000022f4d (9999944 ns)
>          config=ffffffff0000003c irq=0 en per cap_per cap_64
>   1: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
>          config=ffffffff00000000 irq=8
>   2: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
>          config=ffffffff00000000 irq=0
>   3: comparator=00000000ffffffff accumulator=0000000000000000 (0 ns)
>          config=ffffffff00000000 irq=0
> 
> 
> Has anyone sen anything like this or has any ideas on how to debug/fix
> it?  The only next step I can think of is to try VMWare Player and see
> if it works better than VirtualBox.

I did eventually get this fixed by migrating from VirtualBox to VMWare.
That was a bit of a hoot since the only free version is VMWare Fusion,
which does not have all the settings available that are required to run
VMS; I'll write about how I got that working separately.  The clock now
matches independent time sources after a couple days of uptime and
everything seems to be running at more or less reasonable speed.

Running the VUPS.com from:

https://wasd.vsm.com.au/other/vups.com

I get:

VMware, Inc. VMware20,1 with 2 CPU and 7932MB running VMS V9.2-1
INFO: Preventing endless loop (10$) on fast CPUs

Approximate System VUPs Rating : 610.0 ( min: 606.2 max: 612.6 )