clock problems with OpenVMS x86 on VirtualBox

[Craig A. Berry]

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.

[David Jones]

On Saturday, May 6, 2023 at 12:49:43 PM UTC-4, 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.

> ...

> 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 haven't seen anything like that, VirtualBox doesn't step the time if my
Windows laptop does to sleep and wake up. On my laptop, VirtualBox
V7.0.6 seems to enable hpet by default, since it show up as enabled in
the logs.

The NTP daemon doesn't seem stable in this envvironment. The drift
file has -1.498 in it.

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


DT

[Robert A. Brooks]

On 5/7/2023 6:44 PM, David Turner wrote:
> 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?

With every port, more code has been moved from hardware to firmware to software.

Alpha to IA64 required a new mechanism (SoftWare Interupt Services, otherwise
known as SWIS) to handle stuff that was in VAX hardware and Alpha firmware.
SWIS also exists for X86_64 VMS.

There is no VEST/TIE-like mechanism for running non-X86 code on VMS for X86_64.

This is not a VAX/VMS V1.0 situation where some of the VMS commonly-used system
programs were RSX images.

--

--- Rob

[terry-...@glaver.org]

On Sunday, May 7, 2023 at 10:05:59 PM UTC-4, Robert A. Brooks wrote:
> There is no VEST/TIE-like mechanism for running non-X86 code on VMS for X86_64.

Do I remember correctly that some method of running Alpha user code was planned for a future release?

[Gary Sparkes]

VSI states in their FAQ that they prototyped a working VEST type solution, but....

"We created a prototype binary translator for Alpha to x86-64, however there are no plans at this time to develop this further. Any additional work will be evaluated based on customer requirements."

from: https://vmssoftware.com/about/v9-qa/

[Jan-Erik Söderholm]

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?

I should not take the writing below as anything of a value.
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.

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.

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

[Jan-Erik Söderholm]

Den 2023-05-08 kl. 13:08, skrev 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.

Now, did *I* do that? You quoted me before your reply.
It was David T that dragged the "emulator" into this. And he was
of course completely of-track with this "emulator" talk.

I was just confirming that something must be weird in the
setup that was reported, and that was what I commented on. You are
correct that it migth now help you directly, but I thought it could
be of some use/interest anyway.

And I also found it interesting that the clock "ticked" a bit
slow and then jumped forward and skipped a second to catch-up.

But yes, if this had been a common VirtualBox issue, it would
have been know by now, of course.

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

Sure...

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

Again, *I* did not do added that "speculation"...

[Craig A. Berry]

On 5/8/23 6:22 AM, Jan-Erik Söderholm wrote:
> Den 2023-05-08 kl. 13:08, skrev Craig A. Berry:

>> Right.  There is no reason to hijack my thread with a conspiracy theory.

> Now, did *I* do that? You quoted me before your reply.

No. I believe the quote indent levels were correct in my post.

> It was David T that dragged the "emulator" into this. And he was
> of course completely of-track with this "emulator" talk.

Yes. I was agreeing with you on that point and hoping (in vain, no
doubt, this being c.o.v) to drag the thread back on track.

[Jan-Erik Söderholm]

Sure! :-)
Hope you find some solution! And I do not see it *that* off track...

And, I guess that these issues kind of proves the point that
VSI will/must keep it's *supported* production environments
to a few well proven platforms/environments.

[bill]

At this point I am amazed there isn't a VAX and an Alpha emulator
included as a part of VMS-x86_64 to allow people to run code that
can not be moved forward.

bill

[Dave Froble]

"At this point" x86 VMS does not have all the compilers working on x86, and the
OS build is not native. "At this point" I have no idea why you'd think such
software would have any priority.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[bill]

On 5/8/2023 8:53 AM, Dave Froble wrote:
> On 5/8/2023 8:40 AM, bill wrote:
>> On 5/7/2023 11:34 PM, terry-...@glaver.org wrote:
>>> On Sunday, May 7, 2023 at 10:05:59 PM UTC-4, Robert A. Brooks wrote:
>>>> There is no VEST/TIE-like mechanism for running non-X86 code on VMS
>>>> for X86_64.
>>>
>>> Do I remember correctly that some method of running Alpha user code was
>>> planned for a future release?
>>
>> At this point I am amazed there isn't a VAX and an Alpha emulator
>> included as a part of VMS-x86_64 to allow people to run code that
>> can not be moved forward.
>>
>> bill
>>
>
> "At this point" x86 VMS does not have all the compilers working on x86,
> and the OS build is not native.  "At this point" I have no idea why
> you'd think such software would have any priority.
>

Because we often hear that there are still people running Vaxen
with VMS on them and I expect moving a program from the VAX to
x86-64 would be difficult if not impossible (especially if it
has any MACRO in it!) VAX hardware is getting rarer and rarer.
I just see it as an alternative to trying to develop a VEST.

Alpha is in a similar but not quite as near to extinction.

bill

[Arne Vajhøj]

On 5/8/2023 8:40 AM, bill wrote:

If you mean a true emulator then I don't see the point - there are
plenty of such products available from third parties. If anyone need
one, then they buy one. No need for VSI to do anything.

(VSI would also have a small problem supplying a VMS version for
a VAX simulator)

If you mean something like VEST or AEST (which is a translation not
an emulation) - it would probably be called IEST to follow naming
convention, then my guess is that if VSI were DEC/HP size, then they
would have created such a beast, but they are not. VSI is a smaller
company and they have to prioritize. IEST with the possibility to
also process images that has already been through AEST and
possible VEST would be a lot of work. So they decided not to do it.

Arne

[Arne Vajhøj]

On 5/8/2023 9:11 AM, bill wrote:
> On 5/8/2023 8:53 AM, Dave Froble wrote:
>> On 5/8/2023 8:40 AM, bill wrote:
>>> At this point I am amazed there isn't a VAX and an Alpha emulator
>>> included as a part of VMS-x86_64 to allow people to run code that
>>> can not be moved forward.
>>

>> "At this point" x86 VMS does not have all the compilers working on
>> x86, and the OS build is not native.  "At this point" I have no idea
>> why you'd think such software would have any priority.
>
> Because we often hear that there are still people running Vaxen
> with VMS on them and I expect moving a program from the VAX to
> x86-64 would be difficult if not impossible (especially if it
> has any MACRO in it!) VAX hardware is getting rarer and rarer.
> I just see it as an alternative to trying to develop a VEST.

There are people with that need.

But solutions are already available.

Stromasys Charon-VAX is probably the most well known.

https://www.stromasys.com/solution/charon-vax

You pay - you get your VAX - you get support - I assume
Stromasys can even help with the license transfer.

What should VSI contribute with?

> Alpha is in a similar but not quite as near to extinction.

There are even more Alpha simulators available.

https://www.stromasys.com/solution/charon-axp

https://emuvm.com/

Arne

[abrsvc]

> But solutions are already available.
>
> Stromasys Charon-VAX is probably the most well known.
>
> https://www.stromasys.com/solution/charon-vax
>
> You pay - you get your VAX - you get support - I assume
> Stromasys can even help with the license transfer.
>
> What should VSI contribute with?
> > Alpha is in a similar but not quite as near to extinction.
> There are even more Alpha simulators available.
>
> https://www.stromasys.com/solution/charon-axp
>
> https://emuvm.com/
>
> Arne

Yes, Stromays can help with the license transfer (and general VAX and OpenVMS operational support too!)
The same goes for the Alpha platform.

Dan

Full disclosure: I work for Stromasys providing the above support.

[John Dallman]

In article <kbsanj...@mid.individual.net>, bill.gu...@gmail.com

(bill) wrote:

> Because we often hear that there are still people running Vaxen
> with VMS on them and I expect moving a program from the VAX to
> x86-64 would be difficult if not impossible (especially if it
> has any MACRO in it!)

If you have the source, the MACRO cross-compiler to x86 is available. It
had to be: chunks of VMS are still written in it.

John

[bill]

On 5/8/2023 9:14 AM, Arne Vajhøj wrote:
>
>
> If you mean a true emulator then I don't see the point - there are
> plenty of such products available from third parties. If anyone need
> one, then they buy one. No need for VSI to do anything.

I guess I'm just to subtle. I certainly didn't mean for VSI to re-
invent the wheel yet again. I meant that they should [ick up one of
these existing emulators (SIMH for the VAX) do a port for VMS (if
it doesn't already exist) and then bundle them with VMS-x86_64.
IMHO a reasonable alternative to the VEST idea. I am sure any VAX
emulation will be faster than the fastest hardware VAX ever built.
Alpha, I couldn't say.

>
> (VSI would also have a small problem supplying a VMS version for
> a VAX simulator)

Well, once things smooth out keeping these VAX customers on VMS might
just be the incentive they need to do a VSI VAX Version. I am pretty
sure they have said in the past that they have the license to do this
but just didn't see a business case.

>
> If you mean something like VEST or AEST (which is a translation not
> an emulation) - it would probably be called IEST to follow naming
> convention, then my guess is that if VSI were DEC/HP size, then they
> would have created such a beast, but they are not. VSI is a smaller
> company and they have to prioritize. IEST with the possibility to
> also process images that has already been through AEST and
> possible VEST would be a lot of work. So they decided not to do it.

I see it as an alternative. And, I expect a much more reliable one.
I have never run anything VESTed or AESTed but I can see a lot of ways
that could go wrong. I think even more so with the new architecture.

bill

[terry-...@glaver.org]

On Monday, May 8, 2023 at 2:56:05 PM UTC-4, bill wrote:
> I guess I'm just to subtle. I certainly didn't mean for VSI to re-
> invent the wheel yet again. I meant that they should [ick up one of
> these existing emulators (SIMH for the VAX) do a port for VMS (if
> it doesn't already exist) and then bundle them with VMS-x86_64.
> IMHO a reasonable alternative to the VEST idea. I am sure any VAX
> emulation will be faster than the fastest hardware VAX ever built.
> Alpha, I couldn't say.

IMH expects to be running operating systems (at least in the VAX
case). It might need substantial changes to its design to provide
only instruction emulation and to simply produce calls to equivalent
x86-64 VMS functions.

If you just mean running a complete VAX/VMS environment, since
x86-64 VMS already runs under a hypervisor it would probably be
better to just run vanilla SIMH as another VM. If VSI ever releases
a "cluster compatibility kit" for VAX/VMS, it could even be a poten-
tially-supported cluster environment.

There is also the issue that some / many (I don't have that info, but
I assume VSI has some idea) VAX customers are still on VAX due
to dependency on [semi-]custom hardware. With the small number
of VMS customers I'm familiar with, VAX -> Alpha was usually "We
can't" while Alpha -> Itanium was "We won't".

[Robert A. Brooks]

On 5/8/2023 6:32 PM, terry-...@glaver.org wrote:

> If you just mean running a complete VAX/VMS environment, since
> x86-64 VMS already runs under a hypervisor it would probably be
> better to just run vanilla SIMH as another VM. If VSI ever releases
> a "cluster compatibility kit" for VAX/VMS, it could even be a poten-
> tially-supported cluster environment.

I can say with a staggeringly high level of confidence that
VSI will *never* release anything for the VAX.

As I've said before, we have the rights to release
a VSI-built version of VAX/VMS, but we won't.

--

--- Rob

[terry-...@glaver.org]

On Monday, May 8, 2023 at 7:39:59 PM UTC-4, Robert A. Brooks wrote:
> I can say with a staggeringly high level of confidence that
> VSI will *never* release anything for the VAX.

I'm just going by https://vmssoftware.com/about/v9-qa #12,
"Can I cluster VAX 7.3 with OpenVMS x86?"

I wasn't implying that VSI might produce a whole new VAX/VMS
kit, just that if there's going to be supported clustering, most times
in the past with HPaqital it has usually required a "cluster com-
patibility" kit on the older systems. I seem to remember some of
these being listed as "supported" and some "only as a temporary
migration aid".

Whether such a thing is desirable or practical is only known to
VSI. If some customers are migrating from VAX to x86-64 it could
be useful.

I'm aware that there are finite resources being pulled in several
different directions. As I said in the previous paragraph, VSI is
in the best (only) position to know if this is a good use of those
resources.

[Johnny Billquist]

On 2023-05-08 00:44, David Turner wrote:
> 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?

Wait...

Did you expect the emulated CPU to run at the same speed independent of
the actual CPU speed?

Johnny

[Johnny Billquist]

Fully understood and understandable.

But there is a whole lot of people who wish VSI would just re-release
V7.3 with a VSI stamp on it, so it could be handled for hobbyists.

But I understand that even that is probably too much work to be worth
it. Extremely little return on any work done.

Johnny

[Dave Froble]

Ok, here is how I understand the issue ...

VSI is able to release a new VSI VAX/VMS. They choose not to do so. A
reasonable decision. That is not their future.

VSI is not allowed to release anything for DEC/Compaq/HP releases of VMS. I may
not understand correctly, but that seems to be what they have said more than
once. Thus, they cannot legally release a cluster compatibility kit for
VAX/VMS. Unless they issued a new release of VAX/VMS, which most likely will
not happen.

[Dave Froble]

I can guess that perhaps the biggest technical reason is the lack of old VAX
hardware to test against. A few edits and firing up the build procedure might
be possible. But on what HW do you run the build procedure?

[bill]

On 5/9/2023 11:52 AM, Dave Froble wrote:
> On 5/9/2023 8:52 AM, Johnny Billquist wrote:
>> On 2023-05-09 01:39, Robert A. Brooks wrote:
>>> On 5/8/2023 6:32 PM, terry-...@glaver.org wrote:
>>>
>>>> If you just mean running a complete VAX/VMS environment, since
>>>> x86-64 VMS already runs under a hypervisor it would probably be
>>>> better to just run vanilla SIMH as another VM. If VSI ever releases
>>>> a "cluster compatibility kit" for VAX/VMS, it could even be a poten-
>>>> tially-supported cluster environment.
>>>
>>> I can say with a staggeringly high level of confidence that
>>> VSI will *never* release anything for the VAX.
>>>
>>> As I've said before, we have the rights to release
>>> a VSI-built version of VAX/VMS, but we won't.
>>
>> Fully understood and understandable.
>>
>> But there is a whole lot of people who wish VSI would just re-release
>> V7.3 with
>> a VSI stamp on it, so it could be handled for hobbyists.
>>
>> But I understand that even that is probably too much work to be worth it.
>> Extremely little return on any work done.
>>
>>   Johnny
>>
>
> I can guess that perhaps the biggest technical reason is the lack of old
> VAX hardware to test against.  A few edits and firing up the build
> procedure might be possible.  But on what HW do you run the build
> procedure?
>

SIMH... :-)

bill

[Johnny Billquist]

On 2023-05-09 17:49, Dave Froble wrote:
> On 5/8/2023 8:43 PM, terry-...@glaver.org wrote:
>> On Monday, May 8, 2023 at 7:39:59 PM UTC-4, Robert A. Brooks wrote:
>>> I can say with a staggeringly high level of confidence that
>>> VSI will *never* release anything for the VAX.
>>
>> I'm just going by https://vmssoftware.com/about/v9-qa #12,
>> "Can I cluster VAX 7.3 with OpenVMS x86?"
>>
>> I wasn't implying that VSI might produce a whole new VAX/VMS
>> kit, just that if there's going to be supported clustering, most times
>> in the past with HPaqital it has usually required a "cluster com-
>> patibility" kit on the older systems. I seem to remember some of
>> these being listed as "supported" and some "only as a temporary
>> migration aid".
>>
>> Whether such a thing is desirable or practical is only known to
>> VSI. If some customers are migrating from VAX to x86-64 it could
>> be useful.
>>
>> I'm aware that there are finite resources being pulled in several
>> different directions. As I said in the previous paragraph, VSI is
>> in the best (only) position to know if this is a good use of those
>> resources.
>>
>
> Ok, here is how I understand the issue ...
>
> VSI is able to release a new VSI VAX/VMS.  They choose not to do so.  A
> reasonable decision.  That is not their future.

That's what I understand as well, and seems to be a reasonable
conclusion. I doubt they'd get any money from such an initiative.

> VSI is not allowed to release anything for DEC/Compaq/HP releases of
> VMS.  I may not understand correctly, but that seems to be what they
> have said more than once.  Thus, they cannot legally release a cluster
> compatibility kit for VAX/VMS.  Unless they issued a new release of
> VAX/VMS, which most likely will not happen.

That sounds strange. Anyone could release any kind of software for any
VMS version. I doubt HP can say anything about that.

What VSI cannot do is issue licenses for an HPE owned version of VMS,
which is where the VAX issue is stuck.

HPE don't give any more licenses for VMS for VAX, and VSI are not
allowed to for the versions that exist.

VSI could give licenses, if they made a release. But see above...

With regards to the cluster compatibility kit - if such a thing is a
separate product, then I think VSI could very well do that. But I think
it also falls on the same problem - VSI have no interest in doing it. I
doubt they'd make the money back from the work required. So it would
also more be a goodwill thing. But if we want to talk goodwill, a VSI
licensed version of VMS for VAX would most likely generate way more
goodwill.

Johnny

[Johnny Billquist]

On 2023-05-09 17:52, Dave Froble wrote:
> On 5/9/2023 8:52 AM, Johnny Billquist wrote:
>> On 2023-05-09 01:39, Robert A. Brooks wrote:
>>> On 5/8/2023 6:32 PM, terry-...@glaver.org wrote:
>>>
>>>> If you just mean running a complete VAX/VMS environment, since
>>>> x86-64 VMS already runs under a hypervisor it would probably be
>>>> better to just run vanilla SIMH as another VM. If VSI ever releases
>>>> a "cluster compatibility kit" for VAX/VMS, it could even be a poten-
>>>> tially-supported cluster environment.
>>>
>>> I can say with a staggeringly high level of confidence that
>>> VSI will *never* release anything for the VAX.
>>>
>>> As I've said before, we have the rights to release
>>> a VSI-built version of VAX/VMS, but we won't.
>>
>> Fully understood and understandable.
>>
>> But there is a whole lot of people who wish VSI would just re-release
>> V7.3 with
>> a VSI stamp on it, so it could be handled for hobbyists.
>>
>> But I understand that even that is probably too much work to be worth it.
>> Extremely little return on any work done.
>>
>>   Johnny
>>
>
> I can guess that perhaps the biggest technical reason is the lack of old
> VAX hardware to test against.  A few edits and firing up the build
> procedure might be possible.  But on what HW do you run the build
> procedure?

simh would be perfectly reasonable.

Johnny

[Chris Townley]

Maybe they haven't got a licence PAK?

--
Chris

[Arne Vajhøj]

What about build time?

Arne

[Dave Froble]

From some past posts, the VAX/VMS build was done on one or more clustered
systems. We don't know of the requirements for an OS build.

As far as time, who cares. If it is to be a one time build for a VSI release,
who is going to care if it takes a month or two? A one time build is all VSI
would need to allow many things, such as hobbyist use, and others.

But, I'm guessing it would not be so simple. None of us knows the requirements
of the build procedure.

[bill]

On 5/9/2023 11:19 PM, Dave Froble wrote:
> On 5/9/2023 6:56 PM, Arne Vajhøj wrote:
>> On 5/9/2023 12:44 PM, Johnny Billquist wrote:
>>> On 2023-05-09 17:52, Dave Froble wrote:
>>>> I can guess that perhaps the biggest technical reason is the lack of
>>>> old VAX
>>>> hardware to test against.  A few edits and firing up the build
>>>> procedure
>>>> might be possible.  But on what HW do you run the build procedure?
>>>
>>> simh would be perfectly reasonable.
>>
>> What about build time?
>>
>> Arne
>>
>>
>
> From some past posts, the VAX/VMS build was done on one or more
> clustered systems.  We don't know of the requirements for an OS build.
>
> As far as time, who cares.  If it is to be a one time build for a VSI
> release, who is going to care if it takes a month or two?  A one time
> build is all VSI would need to allow many things, such as hobbyist use,
> and others.
>
> But, I'm guessing it would not be so simple.  None of us knows the
> requirements of the build procedure.
>

I'll bet at least one person here knows exactly what the requirements
are and how long it is likely to take. :-)

bill

[Arne Vajhøj]

On 5/10/2023 11:11 AM, bill wrote:
> On 5/9/2023 11:19 PM, Dave Froble wrote:
>> On 5/9/2023 6:56 PM, Arne Vajhøj wrote:
>>> On 5/9/2023 12:44 PM, Johnny Billquist wrote:
>>>> On 2023-05-09 17:52, Dave Froble wrote:
>>>>> I can guess that perhaps the biggest technical reason is the lack
>>>>> of old VAX
>>>>> hardware to test against.  A few edits and firing up the build
>>>>> procedure
>>>>> might be possible.  But on what HW do you run the build procedure?
>>>>
>>>> simh would be perfectly reasonable.
>>>
>>> What about build time?
>>

>>  From some past posts, the VAX/VMS build was done on one or more
>> clustered systems.  We don't know of the requirements for an OS build.
>>
>> As far as time, who cares.  If it is to be a one time build for a VSI
>> release, who is going to care if it takes a month or two?  A one time
>> build is all VSI would need to allow many things, such as hobbyist
>> use, and others.
>>
>> But, I'm guessing it would not be so simple.  None of us knows the
>> requirements of the build procedure.
>
> I'll bet at least one person here knows exactly what the requirements
> are and how long it is likely to take.  :-)

Everyone employed in the VMS group at DEC before Alpha arrived
would know the VAX build process.

Probably more than one. John R, Hoff etc..

I expect it to have taken a long time even on a 8xxx cluster.

I remember late 80's building a single (pretty big) application
EXE taking like an hour. VMS is a lot of EXE files.

Obviously the real HW will matter as well. An 8 core i9 and
SIMH emulating a VAX 6660 and SSD disks may help.

Arne

[Johnny Billquist]

I assume this was a joke. Because the point was that if they built a new
version, they would be the ones generating the PAK...

Johnny

[Johnny Billquist]

Probably a fraction of what it took 20 years ago. Assuming it can be
done without having every model of a VAX available for building.
simh only simulates a subset of existing VAXen. But it moves on very
fast compared to any VAX of old... Hardware have just become so much
faster...

Johnny

[abrsvc]

This is correct. I still have my VAX 3800 and using the Charon emulator on a 2,4Ghz box, the emulator blows away the "real" hardware in performance.
OpenVMS V5.5-2 used in both cases.

Dan

[Bob Wilson]

The last type of VAX system that we used to build VAX VMS was a VAX 7600 (6 cpu), w/maximum memory, etc. (it was named SOXFAN for all your Red Sox fans out there)

As I recall a VMS O/S build didn't take terribly long (couple of hours, I think...the 7600 was a screamer)

[David Jones]

On Wednesday, May 10, 2023 at 2:05:43 PM UTC-4, Bob Wilson wrote:
> The last type of VAX system that we used to build VAX VMS was a VAX 7600 (6 cpu), w/maximum memory, etc. (it was named SOXFAN for all your Red Sox fans out there)
>
> As I recall a VMS O/S build didn't take terribly long (couple of hours, I think...the 7600 was a screamer)

Part of the VMS lore I remember is that the 782 had just enough horsepower to build the OS (much
smaller back then) over night..

[bill]

Unless, of course, someone was running the Ada Compiler. Then it could
easily take a month. :-)

bill

[Single Stage to Orbit]

Now it probably takes a few mins on a threadripper :-D
--
Tactical Nuclear Kittens

[gah4]

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.

IBM used to develop new OS running under VM/CMS, so they had to
figure out that early. I suspect it is not unusual to develop OS now
using virtualization.

It might be, though, that someone hasn't gotten around to that one.

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.

That goes back to the days when hardware was rented, and rental depended
on how much it was used. That is, it would stop charging when the system
stopped executing instructions.

Many emulators and hypervisors recognize the idle loop, though.

How does VMS keep track of time?

[Arne Vajhøj]

On 5/11/2023 7:02 PM, gah4 wrote:
> How does VMS keep track of time?

According to IDSM then it reads time from the HW clock
at boot and then update it N (N >= 1000) times per
second at IPL 22.

Arne

[gah4]

So, for all architectures?

https://www.digiater.nl/openvms/freeware/v60/vmsfaq/vmsfaq_004.html

[gah4]

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:

If you Google for virtualbox clock, there are over 15 million hits.
(That is, for all guest OS.)

I didn't follow all of them, but it does seem that the ones that work have
guest OS that know how to ask VB about the clock, instead of using
the usual one.

[Jan-Erik Söderholm]

Actually, that was how I thought it worked. Since I observed that
the clock in my VirtualBox VMS environment lagge a bit behind
but each 10-20 sec, it jumpt ahead and skipped a second so that
it become in sync with the host Windows environment again.

I do not understand how VMS "knows" to jump a second ahead in
any other way then to ask some other environment. No NNTP here...

[Jan-Erik Söderholm]

Btw, and I might have missed some posts, but do we have more then one
report of the VMS clock showing the wrong time?

[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

[Johnny Billquist]

VMS don't know. And no, it is also not querying VirtualBox as such.
There is a defined RTC in the architecture and/or platform, which can be
queried. Be that on real hardware or emulation. And this is used to find
out the time at boot.

VirtualBox of course knows the time in the host, and it just transfers
this information over to the emulated machine via this simulated RTC.

As for how VMS "jumps", it's pretty simple. VMS advances the clock at
ever clock interrupt. The emulated environment knows how many clock
interrupts have been fielded, and how many should have been fielded, and
compensates by fielding extra interrupts if needed, to catch up. All of
that is done in VirtualBox, and VMS have no clue.

Johnny

[gah4]

On Friday, May 12, 2023 at 2:56:13 AM UTC-7, Johnny Billquist wrote:

(snip, I wrote)

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

Yes. On the other hand, when the OS gives up, usually at IPL time when
something fails, there is disabled WAIT state. That is, no interrupts
enabled, in which case it stops.

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

Some put a special instruction in the loop to make it easier for emulators.

There are two time related things that OS need to do. One is tell what
time of day, month, year, it is. The other is task switching, and any other
short time related events.

IBM S/360 uses the same system for both, as you describe.

But S/370 adds a TOD clock, which keeps track of time, and a separate
system for non TOD related timing. One complication with the TOD clock
in Y2K days, is that access is not privileged, such that it can't be emulated
by VM. So, VM/370 and successor guests read the hardware TOD clock.
But other timing uses a different timer which is emulated.

So, some VirtualBox guests have a special way to get the host clock for
TOD functions, but the interrupt clock for others. Saves a lot of work
keeping two clocks synchronized.

[Simon Clubley]

On 2023-05-11, gah4 <ga...@u.washington.edu> wrote:
>
> How does VMS keep track of time?
>

By modern standards, very, very poorly, as demonstrated by an event that
takes place twice a year.

This is something that Unix got absolutely right, and which VMS got
absolutely wrong...

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[Simon Clubley]

On 2023-05-12, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>
> Actually, that was how I thought it worked. Since I observed that
> the clock in my VirtualBox VMS environment lagge a bit behind
> but each 10-20 sec, it jumpt ahead and skipped a second so that
> it become in sync with the host Windows environment again.
>

That's going to make for some "interesting" real-time program behaviour... :-)

[Dave Froble]

As far as I know, there hasn't been an IDSM release since Alpha. So, who knows?

[Dave Froble]

On 5/12/2023 8:14 AM, Simon Clubley wrote:
> On 2023-05-12, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>>
>> Actually, that was how I thought it worked. Since I observed that
>> the clock in my VirtualBox VMS environment lagge a bit behind
>> but each 10-20 sec, it jumpt ahead and skipped a second so that
>> it become in sync with the host Windows environment again.
>>
>
> That's going to make for some "interesting" real-time program behaviour... :-)
>
> Simon.
>

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.

[bill]

On 5/12/2023 8:14 AM, Simon Clubley wrote:

> On 2023-05-12, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>>
>> Actually, that was how I thought it worked. Since I observed that
>> the clock in my VirtualBox VMS environment lagge a bit behind
>> but each 10-20 sec, it jumpt ahead and skipped a second so that
>> it become in sync with the host Windows environment again.
>>
>
> That's going to make for some "interesting" real-time program behaviour... :-)
>

Does VMS still claim to be an RTOS? Did it ever (there was VAXELN)?

And, anyway, trying to do realtime in a VM has got to be futile.

bill

[Simon Clubley]

On 2023-05-12, Dave Froble <da...@tsoft-inc.com> wrote:
> On 5/12/2023 8:14 AM, Simon Clubley wrote:
>> On 2023-05-12, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>>>
>>> Actually, that was how I thought it worked. Since I observed that
>>> the clock in my VirtualBox VMS environment lagge a bit behind
>>> but each 10-20 sec, it jumpt ahead and skipped a second so that
>>> it become in sync with the host Windows environment again.
>>>
>>
>> That's going to make for some "interesting" real-time program behaviour... :-)
>>
>> Simon.
>>
>
> 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),
there's also communications with external devices and the timestamping of
received messages, both of which could be affected by such jumps.

[Clair Grant]

Virtual Box 7.0.6, Lenovo ThinkBook, Windows 11

I put SHOW TIME in a 10 minute loop and ran it 7 hours. Every output showed exactly 10 minutes and 0 seconds from the previous. I did the same thing on

ESXi 8.0, DL580

and got the same result. If we have a problem, it is certainly not universal.

Clair

[Gary Sparkes]

Virtualization aware OSes *Will* update/request host time at specified intervals.

Not just at boot.

Most mainstream OSes have this capability to avoid VM time drift.

It can also be disabled, which is the recommended setting for Windows AD Domain
controllers, for example - the PDC emulator hosting one does external time sync,
all other DCs sync to that, and then you sync your hardware to those sources (the DCs)

All other guest VMs use host time sync. If the host's time drifts too far, you will
have a Bad Day (tm) in a kerberos authentication environment because the guest
VMs time will drift too. Without reboot. Because the guest VMs are hypervisor time aware
unless you disable host time sync and/or don't install the VM tooling (if required, linux
for example wouldn't need it if the hypervisor support is compiled into kernel for
time sync to work)

So yes, it is done after boot. Constantly.

[Arne Vajhøj]

On 5/12/2023 1:30 PM, Simon Clubley wrote:
> On 2023-05-12, Dave Froble <da...@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?

Arne

[Arne Vajhøj]

On 5/12/2023 8:41 AM, bill wrote:
> On 5/12/2023 8:14 AM, Simon Clubley wrote:
>> On 2023-05-12, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>>> Actually, that was how I thought it worked. Since I observed that
>>> the clock in my VirtualBox VMS environment lagge a bit behind
>>> but each 10-20 sec, it jumpt ahead and skipped a second so that
>>> it become in sync with the host Windows environment again.
>>
>> That's going to make for some "interesting" real-time program
>> behaviour... :-)
>
> Does VMS still claim to be an RTOS?  Did it ever (there was VAXELN)?

I don't think it ever has.

But 30 years ago most believed that VMS had better
real time characteristics than Unix.

Arne

[Arne Vajhøj]

On 5/12/2023 8:32 AM, Dave Froble wrote:
> On 5/11/2023 9:41 PM, gah4 wrote:
>> On Thursday, May 11, 2023 at 4:42:06 PM UTC-7, Arne Vajhøj wrote:
>>> On 5/11/2023 7:02 PM, gah4 wrote:
>>>> How does VMS keep track of time?
>>
>>> According to IDSM then it reads time from the HW clock
>>> at boot and then update it N (N >= 1000) times per
>>> second at IPL 22.
>>
>> So, for all architectures?
>>
>> https://www.digiater.nl/openvms/freeware/v60/vmsfaq/vmsfaq_004.html
>>
>
> As far as I know, there hasn't been an IDSM release since Alpha.  So,
> who knows?

Various VMS people know.

But my understanding is that:
* VAX to Alpha added a ton of new features
* Alpha to Itanium was mostly a 1:1 port (unless new ISA
required a change)
* Itanium to x86-64 is mostly a 1:1 port (unless new ISA
required a change)

So unless there is a difference between Alpha, Itanium
and x86-64 regarding clocks requiring a change then I
would expect it to still be so.

Arne

[Fred. Zwarts]

Op 13.mei.2023 om 02:18 schreef Arne Vajhøj:

In 1980 the RT properties of VMS were part of the decision to by a VAX
for our nuclear physics laboratory, i.e. the special scheduling of 'Real
Time' priority processes.
I don't know if those properties are still present.

[Arne Vajhøj]

On 5/13/2023 3:30 AM, Fred. Zwarts wrote:
> Op 13.mei.2023 om 02:18 schreef Arne Vajhøj:
>> On 5/12/2023 8:41 AM, bill wrote:
>>> On 5/12/2023 8:14 AM, Simon Clubley wrote:
>>>> On 2023-05-12, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>>>>> Actually, that was how I thought it worked. Since I observed that
>>>>> the clock in my VirtualBox VMS environment lagge a bit behind
>>>>> but each 10-20 sec, it jumpt ahead and skipped a second so that
>>>>> it become in sync with the host Windows environment again.
>>>>
>>>> That's going to make for some "interesting" real-time program
>>>> behaviour... :-)
>>>
>>> Does VMS still claim to be an RTOS?  Did it ever (there was VAXELN)?
>>
>> I don't think it ever has.
>>
>> But 30 years ago most believed that VMS had better
>> real time characteristics than Unix.
>

> In 1980 the RT properties of VMS were part of the decision to by a VAX
> for our nuclear physics laboratory, i.e. the special scheduling of 'Real
> Time' priority processes.
> I don't know if those properties are still present.

VAX got real time priorities 16-31.

Alpha got real time priorities 16-63.

I assume Itanium and x86-64 has 16-63 as well.

But I believe there is more to real time than
having those (no quantum end and no dynamic
adjustment).

Arne

[bill]

Basic Unix was never an RTOS. But there were versions that made the
necessary modifications to be an RTOS. But then I guess the question
becomes are they still Unix. :-)

bill

[Craig Ruff]

In article <kc9eeu...@mid.individual.net>,

bill <bill.gu...@gmail.com> wrote:
>Basic Unix was never an RTOS. But there were versions that made the
>necessary modifications to be an RTOS. But then I guess the question
>becomes are they still Unix. :-)

Linux with the rt-premept feature enabled does a good job of supporting
near real time applications. I use this at work in embedded devices.
Sometimes you have to do things like lock a process into memory to
prevent issues or ensure latency is met, but you get the benefit of also
running non-real time processes to do other things like a GUI or network
communications.

[Arne Vajhøj]

Seen from an ordinary user or programmer perspective then Linux
is Unix, but for real time characteristics I think there is a huge
difference between the Linux of today and the Unix of the 80.s

Arne

[Johnny Billquist]

On 2023-05-12 12:24, gah4 wrote:
> On Friday, May 12, 2023 at 2:56:13 AM UTC-7, Johnny Billquist wrote:
>
> (snip, I wrote)
>
>>> 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.
>
> Yes. On the other hand, when the OS gives up, usually at IPL time when
> something fails, there is disabled WAIT state. That is, no interrupts
> enabled, in which case it stops.

Yeah. Well, if you disable all interrupts, and spin (or WAIT), not much
else can be expected to happen...

>> 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.
>
> Some put a special instruction in the loop to make it easier for emulators.

Doable if you have sources, which usually isn't the case with VMS.
NetBSD on VAX did add a hack to allow simh to detect the idle state,
which is harmless on real hardware (basically raising IPL to 1).

> There are two time related things that OS need to do. One is tell what
> time of day, month, year, it is. The other is task switching, and any other
> short time related events.
>
> IBM S/360 uses the same system for both, as you describe.

So does VMS, all Unixes that I've ever encountered, all PDP-11 OSes I've
ever encountered, all RTOSes I've ever encountered, and everything else
I've ever encountered...

> But S/370 adds a TOD clock, which keeps track of time, and a separate
> system for non TOD related timing. One complication with the TOD clock
> in Y2K days, is that access is not privileged, such that it can't be emulated
> by VM. So, VM/370 and successor guests read the hardware TOD clock.
> But other timing uses a different timer which is emulated.

Most systems do have a TOD clock as well, in hardware. But it is not
used for actually reporting current wall clock time, but is read out at
boot time and the OS time is set from it, and occasionally it is also
written to, to correct small drifts that happen over time.

Some PDP-11s have it, all VAXen have it, any PC have it these days, and
pretty much most other hardware as well, unless it's a rather limited
embedded system.

> So, some VirtualBox guests have a special way to get the host clock for
> TOD functions, but the interrupt clock for others. Saves a lot of work
> keeping two clocks synchronized.

Which is how it works on everything I've encountered. :-)
But as I mentioned, the TOD clock is read out at boot time, and not
directly used for reporting current time.

Johnny

[Johnny Billquist]

That don't make much sense, and I've not see any who do it. But you
might be right. And that would probably cause some interesting conflicts
with most OSes that tend to have an NTP daemon running, which corrects
local time on the OS as well.

> Most mainstream OSes have this capability to avoid VM time drift.

The VM drift is usually the responsibility of the VM itself, and not the
host OS. And it's handled by the simple fact that clock interrupts are
controlled by the VM, and can be monitored and tracked by the VM, so it
knows if there is any drift in the first place.

> It can also be disabled, which is the recommended setting for Windows AD Domain
> controllers, for example - the PDC emulator hosting one does external time sync,
> all other DCs sync to that, and then you sync your hardware to those sources (the DCs)
>
> All other guest VMs use host time sync. If the host's time drifts too far, you will
> have a Bad Day (tm) in a kerberos authentication environment because the guest
> VMs time will drift too. Without reboot. Because the guest VMs are hypervisor time aware
> unless you disable host time sync and/or don't install the VM tooling (if required, linux
> for example wouldn't need it if the hypervisor support is compiled into kernel for
> time sync to work)
>
> So yes, it is done after boot. Constantly.

Yes. But usually not in the way you describe. At least not in any system
I've seen.

What you normally have is the VM itself that corrects time though
interrupt generation so that the guest OS is pretty much running the
same time as the host. However, the guest OS usually also have NTP
running (or some other time synchronization protocol), which are
adjusting time, since there can still be drift because the host might
not have correct time, and the VM might not be completely successful in
getting clock interrupts at the correct rate over time to the guest.

Johnny

[Johnny Billquist]

On 2023-05-12 14:09, Simon Clubley wrote:
> On 2023-05-11, gah4 <ga...@u.washington.edu> wrote:
>>
>> How does VMS keep track of time?
>>
>
> By modern standards, very, very poorly, as demonstrated by an event that
> takes place twice a year.
>
> This is something that Unix got absolutely right, and which VMS got
> absolutely wrong...

Well, the DST is in a sense a completely different topic, but I do agree
that Unix got this right, and VMS wrong.

Johnny

[Johnny Billquist]

On 2023-05-12 14:14, Simon Clubley wrote:
> On 2023-05-12, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>>
>> Actually, that was how I thought it worked. Since I observed that
>> the clock in my VirtualBox VMS environment lagge a bit behind
>> but each 10-20 sec, it jumpt ahead and skipped a second so that
>> it become in sync with the host Windows environment again.
>>
>
> That's going to make for some "interesting" real-time program behaviour... :-)

Yup. Basically, *do not run time senstive programs under a VM*. You will
never have proper timing on things.

Johnny

[Johnny Billquist]

You can hide a lot of potential problems with really fast hardware.
Don't mean the problems don't exist.

You want me to demonstrate this to you? Give me access to your host
system where these VMs are running, and I'll throw some monkey wrenches
in your timing... ;-)

Also, over time, the VMs compensate for jitter and drift, so over time,
you should be still be good for the type of test/measurement you did.

Johnny

[Johnny Billquist]

For sure. You have no guarantee that you will get the CPU cycles when
you need them. No matter what kind of hypervisor we're talking about,
there is overhead in the host that can affect things way more than what
might happen on bare metal.

Johnny

[Johnny Billquist]

On 2023-05-13 02:18, Arne Vajhøj wrote:
> On 5/12/2023 8:41 AM, bill wrote:
>> On 5/12/2023 8:14 AM, Simon Clubley wrote:
>>> On 2023-05-12, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>>>> Actually, that was how I thought it worked. Since I observed that
>>>> the clock in my VirtualBox VMS environment lagge a bit behind
>>>> but each 10-20 sec, it jumpt ahead and skipped a second so that
>>>> it become in sync with the host Windows environment again.
>>>
>>> That's going to make for some "interesting" real-time program
>>> behaviour... :-)
>>
>> Does VMS still claim to be an RTOS?  Did it ever (there was VAXELN)?
>
> I don't think it ever has.

I think it claimed/aimed at soft realtime.

> But 30 years ago most believed that VMS had better
> real time characteristics than Unix.

It still do. Unix is way worse. That's why you have these real time
extensions to Linux. With those, you are getting acceptable soft
realtime in Linux as well, but at the cost of not having a Unix-like API
for those parts...

Johnny

[gah4]

On Monday, May 15, 2023 at 3:06:16 AM UTC-7, Johnny Billquist wrote:

(snip, I wrote)

> > IBM S/360 uses the same system for both, as you describe.

> So does VMS, all Unixes that I've ever encountered, all PDP-11 OSes I've
> ever encountered, all RTOSes I've ever encountered, and everything else
> I've ever encountered...

The S/360 interval timer is a 32 bit word in memory that decrement such that
bit 23 (counting from the left) seems to decrement at 300Hz. That allows for
an actual 50Hz or 60Hz timer, subtracting 6 or 5. An interrupt is generated
when it goes below zero.

One way to look at it is a microcode interrupt. It only decrements between
instructions. It does not need to generate a real interrupt at that rate.

[gah4]

On Monday, May 15, 2023 at 3:06:16 AM UTC-7, Johnny Billquist wrote:

(snip, I wrote)

> > But S/370 adds a TOD clock, which keeps track of time, and a separate
> > system for non TOD related timing. One complication with the TOD clock
> > in Y2K days, is that access is not privileged, such that it can't be emulated
> > by VM. So, VM/370 and successor guests read the hardware TOD clock.
> > But other timing uses a different timer which is emulated.

> Most systems do have a TOD clock as well, in hardware. But it is not
> used for actually reporting current wall clock time, but is read out at
> boot time and the OS time is set from it, and occasionally it is also
> written to, to correct small drifts that happen over time.

The S/370 TOD clock is 64 bits, and increments such that bit 51
(counting from the MSB as bit 0) increments at 1MHz.
Actual implementations might have more or less resolution.

It is accessed with the STCK instruction, which stores its value
in memory. It is defined such that you never see the same value
in successive execution. That is easy on slow CPUs, otherwise
they increment low bits. As well as I know it, processors in the
1970's really did increment it at 1MHz. You would not want to do
that with interrupts.

Then there is the CPU timer, again 64 bits, which decrements such that
but 51 decrements at 1MHz. Again, actual implementations might
have or or less resolution. It generates an interrupt when it is negative.

So, no high speed interrupt is needed, but you still get high resolution.
There are reasons why it might not always be decremented, such that
it isn't good for time-of-day use.

In the case of virtual machines, each one will have its own CPU timer,
but only one TOD clock. STCK is not a privileged instruction, so programs
(or OS) see the host clock.

[Craig A. Berry]

On 5/12/23 3:25 PM, Clair Grant wrote:
> Virtual Box 7.0.6, Lenovo ThinkBook, Windows 11
>
> I put SHOW TIME in a 10 minute loop and ran it 7 hours. Every output
> showed exactly 10 minutes and 0 seconds from the previous. I did the
> same thing on
>
> ESXi 8.0, DL580
>
> and got the same result. If we have a problem, it is certainly not
> universal.
>
> Clair

Thanks for the reply and for running your own test. The problem is
indeed not universal. I'm beginning to think in my case there is some
disagreement between VirtualBox and macOS, and/or something specific to
the particular laptop hardware of the host.

[Arne Vajhøj]

What host? A type 1 hypervisor does not run a host OS.

And why would the CPU not be available, when there is no
over allocation of resources? It seems pretty silly of
the hypervisor to not want to give the CPU if no other
VM can get it.

Arne

[Arne Vajhøj]

On 5/15/2023 7:37 AM, Craig A. Berry wrote:
> On 5/12/23 3:25 PM, Clair Grant wrote:
>> Virtual Box 7.0.6, Lenovo ThinkBook, Windows 11
>>
>> I put SHOW TIME in a 10 minute loop and ran it 7 hours. Every output
>> showed exactly 10 minutes and 0 seconds from the previous. I did the
>> same thing on
>>
>> ESXi 8.0, DL580
>>
>> and got the same result. If we have a problem, it is certainly not
>> universal.
>

> Thanks for the reply and for running your own test.  The problem is
> indeed not universal.  I'm beginning to think in my case there is some
> disagreement between VirtualBox and macOS, and/or something specific to
> the particular laptop hardware of the host.

From the high level perspective then I think we need to realize that:

number of virtualization platforms (software and version) x number of OS
platforms (software and version - discard if type 1 hypervisor) x number
of HW platforms (CPU + MB + more combos) > number VMS x86-64 users

Impossible to test everything.

And in some cases there will be glitches.

Bug in VMS x86-64 or bug in virtualization software or bug in host OS
(if present) or bug in HW.

So far I believe the indication is that VMS x86-64 quality is
pretty good.

Let us call it VMS quality! :-) :-) :-)

Arne

[Simon Clubley]

On 2023-05-13, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
> VAX got real time priorities 16-31.
>
> Alpha got real time priorities 16-63.
>
> I assume Itanium and x86-64 has 16-63 as well.
>
> But I believe there is more to real time than
> having those (no quantum end and no dynamic
> adjustment).
>

Real-time at its core is about meeting timing deadlines.

If you miss the odd timing deadline and can still function (maybe in
a degraded way), it's called soft real-time.

If you miss a timing deadline and hence go BOOM!!! (or even fully fail
in a less dramatic way :-)), it's called hard real-time.

[Dan Cross]

In article <8b6c6dbd-5dc4-41aa...@googlegroups.com>,
gah4 <ga...@u.washington.edu> wrote:
>[snip]

>In the case of virtual machines, each one will have its own CPU timer,
>but only one TOD clock. STCK is not a privileged instruction, so programs
>(or OS) see the host clock.

This would seem to violate Popek and Goldberg's virtualization
criteria; how is that squared?

- Dan C.

[Jan-Erik Söderholm]

>
> On 5/12/23 3:25 PM, Clair Grant wrote:
>> Virtual Box 7.0.6, Lenovo ThinkBook, Windows 11
>>
>> I put SHOW TIME in a 10 minute loop and ran it 7 hours. Every
>> output showed exactly 10 minutes and 0 seconds from the previous.

I'm not sure I fully understand how that test was done.

If you ask VMS to wait for 10 min and then ask VMS for the time
passed, I would expect VMS to say that "10 min has passed", no
matter how long those 10 min was in reallity.

Of course VMS in it self belives that 10 min has passed,
it doesn't know better, so to speak.

Or, fully possible of course, I'm just missing something here... :-)

Jan-Erik.

[Simon Clubley]

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.

[Simon Clubley]

On 2023-05-15, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>>
>> On 5/12/23 3:25 PM, Clair Grant wrote:
>>> Virtual Box 7.0.6, Lenovo ThinkBook, Windows 11
>>>
>>> I put SHOW TIME in a 10 minute loop and ran it 7 hours. Every
>>> output showed exactly 10 minutes and 0 seconds from the previous.
>
> I'm not sure I fully understand how that test was done.
>
> If you ask VMS to wait for 10 min and then ask VMS for the time
> passed, I would expect VMS to say that "10 min has passed", no
> matter how long those 10 min was in reallity.
>

I agree. I don't think it's a real test unless both VMS and the host OS
are both doing other things while also running this timing loop and there
is a way to compare the reported VMS time with the underlying host OS time.

> Of course VMS in it self belives that 10 min has passed,
> it doesn't know better, so to speak.
>
> Or, fully possible of course, I'm just missing something here... :-)
>

I don't think you are. I think for the test to be valid, it needs to be
done on a loaded system and a way of comparing the VMS reported time to
the actual host time needs to be devised.

Given the reported problems, I also think the test needs to have an
test interval that's way under 10 minutes.

It needs some kind of script, running on the host OS, that is connected to
VMS and runs a $ SHOW TIME every couple of minutes for several hours.

It needs to write both the output from $ SHOW TIME and the current host
time to a log file, along with the delta difference value between the two.

[Arne Vajhøj]

On 5/15/2023 8:20 AM, Simon Clubley wrote:
> On 2023-05-12, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 5/12/2023 1:30 PM, Simon Clubley wrote:
>>> On 2023-05-12, Dave Froble <da...@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.

Arne

[Johnny Billquist]

On 2023-05-15 12:59, gah4 wrote:
> On Monday, May 15, 2023 at 3:06:16 AM UTC-7, Johnny Billquist wrote:
>
> (snip, I wrote)
>
>>> IBM S/360 uses the same system for both, as you describe.
>
>> So does VMS, all Unixes that I've ever encountered, all PDP-11 OSes I've
>> ever encountered, all RTOSes I've ever encountered, and everything else
>> I've ever encountered...
>
> The S/360 interval timer is a 32 bit word in memory that decrement such that
> bit 23 (counting from the left) seems to decrement at 300Hz. That allows for
> an actual 50Hz or 60Hz timer, subtracting 6 or 5. An interrupt is generated
> when it goes below zero.

PDP-11 clock interrupts are usually also at 50Hz or 60Hz depending on
what frequence is used on main lines power. Not an unusual frequency for
computers to use to count time.

It used to be a *very* reliable clock source. Power grids used to
compensate for drift because of load, so that over 24 hours, you have a
very exact number of peaks on the power. All type of clocks were
designed with this clock source. Sadly, I think power grids no longer
are caring as much about the accuracy of the frequency.

VAX didn't, but instead have a 100 Hz clock source for interrupts, which
was less accurate than the power based one.

> One way to look at it is a microcode interrupt. It only decrements between
> instructions. It does not need to generate a real interrupt at that rate.

I don't know the S/360 at all, but I would expect that it also uses the
50/60Hz as a clock source with interrupts generated at that frequency...

Johnny

[Craig A. Berry]

I was assuming that the total time of 7 hours was independently
corroborated, but you're right, he didn't explicitly say that.

[Johnny Billquist]

In your case, I would agree. The amount of errors you mentioned is big.
Definitely sounds like some disagreement between the components about
the clock handling.

Johnny

[Johnny Billquist]

Ha! A very good point. The test don't actually prove anything. You are
right. :-)

But if you were to compare to an external clock, I would suspect you
would not see big deviations either, but I would expect there to be
small glitches in the short timescale and if you look with enough
resolution.

Johnny

[Johnny Billquist]

On 2023-05-15 14:03, Arne Vajhøj wrote:
> On 5/15/2023 6:17 AM, Johnny Billquist wrote:
>> On 2023-05-13 02:16, Arne Vajhøj wrote:
>>> On 5/12/2023 1:30 PM, Simon Clubley wrote:
>>>> On 2023-05-12, Dave Froble <da...@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?
>>
>> For sure. You have no guarantee that you will get the CPU cycles when
>> you need them. No matter what kind of hypervisor we're talking about,
>> there is overhead in the host that can affect things way more than
>> what might happen on bare metal.
>
> What host? A type 1 hypervisor does not run a host OS.

Um? What is the hypervisor then?

> And why would the CPU not be available, when there is no
> over allocation of resources? It seems pretty silly of
> the hypervisor to not want to give the CPU if no other
> VM can get it.

Any kind of hypervisor means we're talking about virtualization. That
means you have real hardware which exists outside of this
virtualization. And that hardware can generate interrupts and demand
service, which then forces the hypervisor to wait before it can actually
get any cycles. Outside the control of the hypervisor...

Johnny

[Johnny Billquist]

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.

It's kindof weird to me that people can even believe that it would be
possible to add a software layer in between that have no actual impact.

Johnny

[Arne Vajhøj]

The hypervisor software like ESXi.

It is not running on top of a host OS like a type 2 (VirtualBox etc.) does.

>> And why would the CPU not be available, when there is no
>> over allocation of resources? It seems pretty silly of
>> the hypervisor to not want to give the CPU if no other
>> VM can get it.
>
> Any kind of hypervisor means we're talking about virtualization. That
> means you have real hardware which exists outside of this
> virtualization. And that hardware can generate interrupts and demand
> service, which then forces the hypervisor to wait before it can actually
> get any cycles. Outside the control of the hypervisor...

Maybe. But what would that be?

Arne

[Arne Vajhøj]

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

Arne

[Arne Vajhøj]

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

[Dan Cross]

In article <u3t0se$5jt$6...@news.misty.com>,

There are many issues at play when we talk about virtualization
and soft real-time systems. What you're describing has to do
with scheduling of guest tasks, and best-in-class techniques can
mostly deal with that (e.g., schedulers like Tableau or applying
an EDF scheduler to VCPU management).

But even without over-commit, there are other aspects of the
overall system configuration that can affect performance. For
example, there is overhead in managing the guest's physical
address space: while current x86 architectures can support a set
of second-level page tables for this, there is still the issue
of needing to walk those tables, the pressure that puts on the
equivalent of the TLB, etc. Not to mention that the real TLB
for virtual addresses (both guest and host) will be put under
pressure due to both the host and other guest tasks (even a
non-overcommitted type-1 hypervisor may move tasks around
between physical host CPUs). And if you're using nested virt
or shadow-paging...well, good luck.

And separately there are issues of IO: in a type-1 scenario, IO
is offloaded to another VM (or even a separate system) on behalf
of a guest; that introduces non-determinate latency and
noisy-neighbor problems without careful construction. Even with
SR-IOV and passthru techniques for hypervisor-bypass, there are
classes of IO that must go through the host, and these can take
arbitrarily long. What do you do when the `outb` to your
virtualized console UART blocks? There are some techniques to
amortize the overhead of these events (posted IOs, for example)
but they are not perfect.

With careful construction, one can side-step most of the cost
and get latencies down to within a couple of percentage points
of running on bare-metal, but there _is_ overhead, and in many
scenarios, it can be unbounded, even if in practice it is
relatively small.

- Dan C.

[Jan-Erik Söderholm]

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.

[Clair Grant]

Of course you are right. My test did not prove anything. That was really stupid.

[Jan-Erik Söderholm]

Maybe not stupid, but I'd say that it missed an important point. :-)

And I guess you are replying to my note about using the same system
to measure the systems own clock. It will always be "spot-on".
Not really my post about real-time...

[terry-...@glaver.org]

On Monday, May 15, 2023 at 8:45:00 AM UTC-4, Johnny Billquist wrote:
> It used to be a *very* reliable clock source. Power grids used to
> compensate for drift because of load, so that over 24 hours, you have a
> very exact number of peaks on the power. All type of clocks were
> designed with this clock source. Sadly, I think power grids no longer
> are caring as much about the accuracy of the frequency.

You can see the (near) real-time frequency deviation as well as the
cumulative clock drift that it causes here:
https://www.swissgrid.ch/en/home/operation/grid-data/current-data.html#frequency

5 or years ago, a Kosovo / Serbia dispute caused much larger drift -
on the order of 6 minutes. Do a web search for 'kosovo makes clocks
run slow'

[Johnny Billquist]

I never assumed you had a full OS. However, they Hypervisor is
intercepting access to hardware, and is responsible for the actual
interaction with the hardware, adding a layer between the guest OS and
the hardware. Which means that the hypvervisor is in the end doing
interrupt handling, for example. Which means that the CPU might be doing
things that suspends the execution for the hypervisor outside the
control of the hypervisor itself, and further more makes things like
interrupts to the guest OS happen at some random later time, including
clock interrupts, which are what affects things like real-time reponse
times.

>>> And why would the CPU not be available, when there is no
>>> over allocation of resources? It seems pretty silly of
>>> the hypervisor to not want to give the CPU if no other
>>> VM can get it.
>>
>> Any kind of hypervisor means we're talking about virtualization. That
>> means you have real hardware which exists outside of this
>> virtualization. And that hardware can generate interrupts and demand
>> service, which then forces the hypervisor to wait before it can
>> actually get any cycles. Outside the control of the hypervisor...
>
> Maybe. But what would that be?

Primarily I would be worried about interrupts, which introduce unknown
amout of delay.

But yes, for things like memory, if it is fixed allocated to VM
instances, and always available, then another potential source of delays
are at least not there.

Depending on what the hypervisor does, you might still also have issues
like page table caches, and normal memory caches, which will have rather
different behaviors compared to plain hardware. Caches are a significant
factor is performance these days.

Johnny

[Johnny Billquist]

Thanks for the exhaustive answer. I don't think I need to add much more
to this.

Johnny