$SETIME and Timer Queues

[Bill Ostrander]

Documentation says:

"After changing or recalibrating the system clock, $SETIME updates the timer queue by adjusting each element in the timer queue by the difference between the previous system time and the new system time."

I'm not finding this to be true. If process A has set a timer to fire 30 seconds from now and process B now sets the time back 5 minutes with $SETIME, A's timer will not fire until 5.5 minutes from now. Conversely if B sets the time ahead, A's timer will fire immediately.

Is there anything B needs to do to insure the timer queues are adjusted so A will fire in 30 seconds as expected?

Thanks,
--Bill

[John Gillings · Accepted solution]

Bill,

I think it depends on how you specified the time in the "daytim" argument to $SETIMR. Was it as an ABSOLUTE time, or a DELTA time?

If absolute, then I'd expect the timer to fire when the system clock reaches or exceeds the specified time (which may be affected by $SETIME changes).

If it was a delta time, then I'd expect adjustment according if the system clock is changed so the duration (as measured by an external clock) was as requested.

Please post version and patch details, along with example code you think is misbehaving.

Maybe modify your test to see if there's a difference between $SETIMR with absolute or delta times?

[John Gillings]

Bill,

Experiment time... this confirms my expectations. OpenVMS Alpha V7.3-2.

I tried the attached Pascal program which schedules two timers one minute ahead. One using an absolute time, calculated as an offset from the current time, and one using a delta time. Each triggers an AST which writes a timestamp when executed.

Three experimental runs.

First run, make sure it works:

$ run timers
Main waiting at 23-AUG-2006 14:13:15.37
Absolute AST fired at 23-AUG-2006 14:14:15.37
Delta AST fired at 23-AUG-2006 14:14:15.37
First wake at 23-AUG-2006 14:14:15.37
Second wake at 23-AUG-2006 14:14:15.37
$

As expected, both ASTs fire at the same absolute time, one minute after being scheduled. So far, so good.

------
Second run, set the clock 30 seconds backwards after the timers have been set.

$ spawn/nowait run timers
%DCL-S-SPAWNED, process GILLINGS_35306 spawned
$
Main waiting at 23-AUG-2006 14:14:44.82
$ show time
23-AUG-2006 14:14:47
$ set time="-0-0:0:30.00"
$ show time
23-AUG-2006 14:14:26
$
Delta AST fired at 23-AUG-2006 14:15:14.82
First wake at 23-AUG-2006 14:15:14.82
Absolute AST fired at 23-AUG-2006 14:15:44.82
Second wake at 23-AUG-2006 14:15:44.82


This time, the DELTA AST fired one minute (external) elapsed after being set. The apparent system time is only 30 seconds because the clock was changed.
The ABSOLUTE AST fired after 90 seconds (external) elapsed time. The apparent system time is 60 seconds. The timer has expired at the absolute system time requested.

-----------
Third run, set the clock 30 seconds forward after the timers have been set.

$ spawn/nowait run timers
%DCL-S-SPAWNED, process GILLINGS_45162 spawned
$
Main waiting at 23-AUG-2006 14:16:52.27
$ show time
23-AUG-2006 14:16:57
$ set time="+0-0:0:30.00"
$ show time
23-AUG-2006 14:17:33
$
$
Absolute AST fired at 23-AUG-2006 14:17:52.27
First wake at 23-AUG-2006 14:17:52.27
Delta AST fired at 23-AUG-2006 14:18:22.27
Second wake at 23-AUG-2006 14:18:22.27

Now the ABSOLUTE AST has fired 30 seconds (external) elapsed time after being set, but apparent system elapsed time of 60 seconds, ie: at the correct system absolute time requested.

The DELTA AST has fired 60 seconds (external) elapsed time, but at apparent system time of only 30 seconds because the clock was changed.

-----------

This behaviour seems reasonable to me (though maybe the $SETIME docs should be clarified with more detail).

Your specific question: "Is there anything B needs to do to insure the timer queues are adjusted so A will fire in 30 seconds as expected?"

No, there's nothing *B* can do, because it depends on what A requested - DELTA or ABSOLUTE.

A needs to decide what "will fire in 30 seconds" actually means, and if it cares about possible changes in the system clock while waiting. You may want to ask Messrs Einstein, Schrodinger & Heisenburg for advice, as this is a highly non-trivial question! ;-)

Do you mean 30 seconds according to some external, "universal frame of reference" time source? (in which case, the closest you'll get is to specify the $SETIMR daytim argument as a DELTA time), or, do you mean 30 seconds subjective time from the frame of reference of the system (in which case you should use an ABSOLUTE time)

Either may be correct, depending on what your program requires (on the other hand, if you ask Mr Schrodinger, BOTH may be correct, at least up to the subjective or absolute time an AST actually fires, then you have to work out how to dispose of the dead cat ;-)

[Bill Ostrander]

John,

Thanks! I appreciate the time you put into this. Indeed I was calculating the absolute time for the next AST to fire.

My timer routine fires once a minute at 30 seconds into the minute. The goal was to have the cycle keep firing once / minute even though the system time was changed an integral number of minutes.

After changing it to use delta time, the timer fires once/minute as desired despite adjustments the system clock. Thanks again.

--Bill

[Robert Gezelter]

Bill,

Remember that the AST firing only queues the process for execution. It does not truly change the base priority of the process.

If you are trying to ensure regularity, with minimum drift over time, the code will need to recompute the time interval based on the current absolute time.

If only an approximate interval is needed, then this is not needed. The time will gradually drift, which is completely natural.

- Bob Gezelter, http://www.rlgsc.com

[John Gillings]

FWIW,
I did find this documented more clearly in the Internals and Data Structrues Manual:


Internals & Data Structures Manual
11.3.1 "$SETIME System Time Recalibration Requests"

...

5. Each element in the timer queue (see Section 11.4) that specified a relative (or delta) time has its expiration time adjusted by the difference between the previous system time and the new system time. This modification prevents the actual relative time value from being changed by a modification to the system time. A timer queue element (TQE) containing an absolute time is not adjusted; this ensures that the TQE will come due at the time specified by the user. Bit TQE$V_ABSOLUTE in TQE$B_RQTYPE distinguishes an absolute request from a relative request: a zero inticates a relative request; 1, an absolute request. Section 11.4 describes the form and use of TQEs.