OpenVMS x86-64 V9.2-1: Significant TOY Slippage over time

[bobgezelter]

I have observed multiple occurrences of accumulating TOY skew running OpenVMS x86-64 under Virtual Box. The underlying Windows host is not particularly busy. In the most recent episode, the time skew is over 1 hour 50 minutes(!) in approximately 24 hours. The skew appears not to be uniform, but episodic.

The hardware/software configuration is:

Host CPU: Dell Latitude E6420 (i5-2520M@2.5GHz; Turbo to 3.26GHz; Typical usage: 30% @ .90GHz); 16GB; 2TB Seagate Barracuda

Host OS: Windows 10 Professional, all patches to date
Virtual Machine: Oracle VirtualBox 7.0.6r1555176 (Qt5.15.2)
Basic OpenVMS x86-64 install; only VSI-supplied basic products (OVMS Community License; TCPIP; DECnet IV)

Examples:
Host Time (EDT) VMS Time (UTC)

Bootstrap 1:
09:38 1338Z
15:25 1857Z
16:26 1958Z
16:47 2019Z
18:46 2218Z
22:49 0219Z

Bootstrap 2:
10:25 1425Z
10:31 1431Z
23:22 0309Z
09:23 1211Z

This is a serious flaw for multiple reasons:
- The slippage is not at a constant ratio. Processes that sequence events based on time can not be reliably run if the clock reference is unpredictably varying. At best it triggers timeouts and correctable errors. At worst, it can compromise the safety of equipment operation.

- Time comparisons between OpenVMS-recorded events and other logs are not reliable.

- Unreliable time stamps compromise the ability to use OpenVMS log time stamps in legal proceedings. Having testified in court involving software-generated logs, unreliable Time of Year recording significantly undermines the reliability of such logs.

- SET TIME from DCL has no effect

It should be noted that guest Ubuntu LTS 20 virtual instances do not encounter corresponding difficulties.

- Bob Gezelter, http://www.rlgsc.com <gezelter@rlgsc.com>

[jreagan]

I have almost the same config (same OS, same VBox, etc) but a different host hardware (Skylake on a Gigabyte branded motherboard, self-built). I've seen these reports before here and my system has been rock solid time for over a week, I know that Clair was trying to spot it, but has not seen it yet.

$ show time
23-JUN-2023 14:20:09
$ show sys/noproc
OpenVMS V9.2-1 on node XGI5 23-JUN-2023 14:20:15.27 Uptime 7 02:38:23

There is something, but I haven't seen it. I'll guess some BIOS/UEFI setting.

[bobgezelter]

John,

I am now 3 for 3 in the last 36 hours. The most recent one lost 6 minutes in the first 30 minutes.

The only significant item on the host system was an upload to a DropBox share.

Everything on my VM is the default, except where the Installation Guide differs.

I will offer.

- If you want, I can upload the whole environment (VM and disk files) to a target of your choice (there is nothing sensitive; well ok, I did modify my LOGIN.COM).

- If you want to me to run something on my VMS instance to examine things or explore the situation.

If you want, we can move this dialogue to email.

- Bob

[jonesd]

How do you read the TOY clock without rebooting? The only time I observed slippage was that the system time would slip if the host laptop went to sleep while running VirtualBox (it had to sleep long enough that NTP would see too large a skew and give up).

My workaround for this program, also needed on Alpha emulators, is to concurrently run a program that tells Windows that is continuously needs the processor (i.e. don't sleep).

[bobgezelter]

@jonesd

System in question is an almost perfect insomniac, never sleeps. Consistent CPU usage in the 30% range.

After booting OpenVMS earlier this afternoon, it lost six minutes in the first 30 minutes.

On VAX, Alpha, and IA64 SET TIME from DCL will read the hardware TOY clock. Reference: HELP text.

[jonesd]

On VAX, Alpha, and IA64 SET TIME from DCL will read the hardware TOY clock. Reference: HELP text.

I knew that would set the TOY clock, but had forgotten that it could read it. This is actually a property of the SYS$SETIME
function and not the DCL command itself. The only slip I see is that the resolution on the TOY is 1 second so I lose the fractional second of the system time when reset.

[bobgezelter]

@jonesd

Omission from my previous posting re SET TIME:

On OpenVMS x86-64, the SET TIME command does NOT fetch the time from the hardware (Host's) clock. It has no effect.

[cct]

I thought that was VAX only, not that I worried about it on AXP, or I64

Chris

[cgrant]

I rarely use VBox these days but I thought I'd take a look at Bob's time issue. Sure enough, I have the same time loss problem. Easily reproduced. V9.2-1, VBox 7.0.6 r155176, Windows 11, Lenovo ThinkBook.

What's different between John and Bob/Clair? Don't know.

I will enter an official problem report and we will get on it.

BTW: I have KVM on a DL380 and ESXi on a DL580 guests that have been running for days with no time issue.

Clair

[jreagan]

And I'm at 9 days on my VBox 7.0.8, Windows 10, Gigabyte motherboard and still perfectly on time (as compared to the clock in the taskbar on my W10 host AND my cellphone)

$ show sys/noproc
OpenVMS V9.2-1 on node XGI5 26-JUN-2023 09:50:26.41 Uptime 9 22:08:34
$ show time
26-JUN-2023 09:50:28