Timer resolution for sys$setimr() ?

[Simon Clubley]

What is the actual resolution of timer events queued using the
sys$setimr() system service ?

NOTE: this is about when the timer becomes eligible to fire, not when
it actually does, given that VMS is not a hard RTOS.

The base VMS time format is in 100ns units, but I couldn't see anything
about the units actually used when firing timer events. Is it the same
as the hopeless terminal driver timeouts, or is it 100ns, or is it
something in between ?

Thanks,

Simon.

PS: This is purely academic BTW. I am working with some sub-second timers
on a Linux project and was wondering what the situation is with VMS.

Simon.

[Arne Vajhøj]

Post by Simon Clubley
What is the actual resolution of timer events queued using the
sys$setimr() system service ?
NOTE: this is about when the timer becomes eligible to fire, not when
it actually does, given that VMS is not a hard RTOS.
The base VMS time format is in 100ns units, but I couldn't see anything
about the units actually used when firing timer events. Is it the same
as the hopeless terminal driver timeouts, or is it 100ns, or is it
something in between ?

IDS VMS Alpha 1.5 (30 years old!) says:

<quote>
12.2.1
All AXP systems provide an interval timer that generates an IPL 22
interrupt at the minimum rate of 1000 times per second, with a minimum
accuracy of 0.0005 percent.
...
All current available AXP systems generate interval timer interrupts
at a rate of 1024 per second.
...
12.6
The interval timer interrupt service routine, EXE$HWCLKINT
...
It checks whether the most imminent TQE is due
...
only the primary CPU is responsible for ... and checking the timer queue
...
EXE$HWCLKINT compares the updates system time with the quadword
EXE$GQ_1ST_TIME, the expiration of the most imminent TQE. If the
TQE is due then, EXE$HWCLKINT checks whether the specific fork block
for the software time fork routine has already been inserted
into the primary processors IPL 8 fork queue. If not the, it
inserts the fork block into the queue, and, if the queue was empty,
requests an IPL$_TIMER software interrupt.
...
12.7
The software timer interrupt service routine, EXE$SWTIMINT
...
The software timer interrupt is requested by the interval timer
interrupt service routine when the current process has reached
quantum end.
...
In later versions of VAX VMS and in OpenVMS AXP, an IPL 8 fork
process running the software timer fork routine
...
12.8
Thew software fork timer routine, EXE$SW_TIMER_FORK
...
If the TQE is a process timer request, created by the a $SETIMR
system service request, then EXE$SW_TIMER_FORK performs the
following operations:
...
EXE$SWTIMER_FORK invokes SCH$QAST to queue the ACB to the
process
</quote>

which I read as if that on Alpha then VMS checks for SYS$SETIMR
AST's to queue every 1 millisecond.

No guarantees when the AST's will actually run.

And some things may have changed in newer VMS versions and
newer hardware.

Arne

[Arne Vajhøj]

Post by Arne Vajhøj

Post by Simon Clubley
What is the actual resolution of timer events queued using the
sys$setimr() system service ?
NOTE: this is about when the timer becomes eligible to fire, not when
it actually does, given that VMS is not a hard RTOS.
The base VMS time format is in 100ns units, but I couldn't see anything
about the units actually used when firing timer events. Is it the same
as the hopeless terminal driver timeouts, or is it 100ns, or is it
something in between ?

<quote>

...

Post by Arne Vajhøj
</quote>
which I read as if that on Alpha then VMS checks for SYS$SETIMR
AST's to queue every 1 millisecond.
No guarantees when the AST's will actually run.
And some things may have changed in newer VMS versions and
newer hardware.

https://hunter.goatley.com/writing-vms-privileged-code/part-v-timer-queues/

has a lot of details.

But is about the same age as the old IDS.

Arne

[Simon Clubley]

Post by Arne Vajhøj
https://hunter.goatley.com/writing-vms-privileged-code/part-v-timer-queues/
has a lot of details.
But is about the same age as the old IDS.

From that page:

|The VAX architecture stipulates the interval timer must generate a hardware
|interrupt every 10 milliseconds, or ten times per second, and the VAX
|hardware guarantees a hardware interrupt every 10 ms.

I didn't see a way to leave feedback on that page.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Arne Vajhøj
https://hunter.goatley.com/writing-vms-privileged-code/part-v-timer-queues/
has a lot of details.
But is about the same age as the old IDS.

|The VAX architecture stipulates the interval timer must generate a hardware
|interrupt every 10 milliseconds, or ten times per second, and the VAX
|hardware guarantees a hardware interrupt every 10 ms.
I didn't see a way to leave feedback on that page.

It is an old mostly historic document.

But Hunter is still around so you can email him.

I have not seen Heinrich around for a few decades.

Arne

[Simon Clubley]

Post by Simon Clubley
What is the actual resolution of timer events queued using the
sys$setimr() system service ?
NOTE: this is about when the timer becomes eligible to fire, not when
it actually does, given that VMS is not a hard RTOS.
The base VMS time format is in 100ns units, but I couldn't see anything
about the units actually used when firing timer events. Is it the same
as the hopeless terminal driver timeouts, or is it 100ns, or is it
something in between ?

[snip]

Thanks Arne. I never even thought to check the I&DS as this was something
I was expecting to find in the normal user documentation.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Simon Clubley
What is the actual resolution of timer events queued using the
sys$setimr() system service ?
NOTE: this is about when the timer becomes eligible to fire, not when
it actually does, given that VMS is not a hard RTOS.
The base VMS time format is in 100ns units, but I couldn't see anything
about the units actually used when firing timer events. Is it the same
as the hopeless terminal driver timeouts, or is it 100ns, or is it
something in between ?

[snip]
Thanks Arne. I never even thought to check the I&DS as this was something
I was expecting to find in the normal user documentation.

Maybe it is. I just found it in IDS, but that does not preclude that
it also is somewhere in the "electronic colored wall".

But they could have decided to omit it because it is so
implementation specific.

Arne