On 2023-05-11, gah4 <gah4@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.

On 2023-05-12, Jan-Erik Söderholm <jan-erik.soderholm@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.

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

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?

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

On 5/12/2023 8:14 AM, Simon Clubley wrote:
> On 2023-05-12, Jan-Erik Söderholm <jan-erik.soderholm@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.

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

On 5/12/2023 8:14 AM, Simon Clubley wrote:
> On 2023-05-12, Jan-Erik Söderholm <jan-erik.soderholm@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

On 2023-05-12, Dave Froble <davef@tsoft-inc.com> wrote:
> On 5/12/2023 8:14 AM, Simon Clubley wrote:
>> On 2023-05-12, Jan-Erik Söderholm <jan-erik.soderholm@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.

Simon.

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

On Friday, May 12, 2023 at 1:30:37 PM UTC-4, Simon Clubley wrote:
> 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.
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.
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

On Friday, May 12, 2023 at 5:56:13 AM UTC-4, Johnny Billquist wrote:
> 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.

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.

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

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

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

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

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.

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

On 5/12/2023 8:18 PM, 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.soderholm@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.

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

In article <kc9eeuFd1mgU1@mid.individual.net>,
bill <bill.gunshannon@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.

On 5/13/2023 8:58 AM, Craig Ruff wrote:
> In article <kc9eeuFd1mgU1@mid.individual.net>,
> bill <bill.gunshannon@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.

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

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

On 2023-05-13 01:32, Gary Sparkes wrote:
> On Friday, May 12, 2023 at 5:56:13 AM UTC-4, Johnny Billquist wrote:
>> 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.
>
> Virtualization aware OSes *Will* update/request host time at specified intervals.
>
> Not just at boot.

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

On 2023-05-12 14:09, Simon Clubley wrote:
> On 2023-05-11, gah4 <gah4@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

On 2023-05-12 14:14, Simon Clubley wrote:
> On 2023-05-12, Jan-Erik Söderholm <jan-erik.soderholm@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

On 2023-05-12 22:25, Clair Grant wrote:
> On Friday, May 12, 2023 at 1:30:37 PM UTC-4, Simon Clubley wrote:
>> 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.
>> Simon.
>>
>> --
>> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
>> Walking destinations on a map are further away than they appear.
> 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.

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

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

Johnny

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

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.

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.