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

[Craig A. Berry]

On 5/8/23 1:45 AM, Jan-Erik Söderholm wrote:
> Den 2023-05-08 kl. 00:44, skrev David Turner:
>> Like I have always suspected.
>> I think there is more of an emulator in the OpenVMS x86 code than has 
>> been admitted.
>> The faster the CPU on the virtualbox the faster your "native X86" code 
>> is gonna run
>> Anyone care to elaborate or prove this?

Prove what?  That nothing in this newsgroup stays on-topic?
> I should not take the writing below as anything of a value.

It's of value to me if it helps anyone identify a solution to the
problem I'm having.

> Just the line saying "it takes about >> 15 seconds for MONITOR
> SYSTEM to initiate its display" says that something is really
> wrong with that environment. On my laptop with VirtualBox,
> MONITOR starts in around 1 sec. I cannot see any difference
> between my VirtualBox environment and a real AlphaServer DS20e.

Right.  There is no reason to hijack my thread with a conspiracy theory.
I have what must be an extremely common set-up, yet things are
completely haywire.  Other people with VirtualBox do not see what I'm
seeing.  There must be some combination of host OS / host hardware /
hypervisor / settings that is not an agreeable combo.  Speculating
without foundation that OpenVMS x86 runs on an emulator rather than a
hypervisor does not get me any closer to figuring out what the actual
problem is.

> What I can see, is a slight lag in the clock. It looses approx
> 1 second in 2.5 minutes. But it is not consitent, a few minutes
> later, my VirtualBox VMS time was back i phase with our real
> production DS20e again. And over a longer timespan, it seems to
> keep the time fine.
> 
> When looking at the MON screen, I can see that the running clock
> at the top right, sometimes jumps over a second and advances 2
> secons "in one second", so to speak.
> 
> I have not done any NNTP setup.
> I have not done that command regarding the clock in the docs.
> 
> Regards,
> Jan-Erik.
> 
> 
> 
>>
>>
>> DT
>>
>>
>> On 5/6/2023 12:49 PM, 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.
>>>
>>
>