next_period = start + n*period; versus next_period = next_period+period;

For cyclic processes, at least in Ada literature such as

Section Two 9.3 of "Ada 95 Rationale: The Language, The Standard Libraries",
#3

and

page 23 (Adobe Acrobat page 27) of
Alan Burns, Brian Dobbing, Tullio Vardanega, "Guide for the use of the Ada
Ravenscar Profile in high integrity systems., University of York Technical
Report YCS-2003-348, January 2003,
which is the
same as the reprint in "Ada Letters", June 2004,

it is recommended to use relative timeouts based on addition for the
periods such as:

with System; is like #include
with Ada.Real_Time;
use type Ada.Real_Time.Time;
package body Additionbased_Example is

task type Cyclic(Pri : System.Priority; Cycle_Time : Positive) is
pragma Priority(Pri);
end Cyclic;

task body Cyclic is
Next_Period : Ada.Real_Time.Time;
Period : constant Ada.Real_Time.Time_Span :=
Ada.Real_Time.Microseconds(Cycle_Time);
begin
-- Initialization code
Next_Period := Ada.Real_Time.Clock + Period;
the current time\.
loop
delay until Next_Period; -- wait one whole period before executing
-- Non-suspending periodic response code
--
Next_Period := Next_Period + Period;
end loop;
end Cyclic;

end Additionbased_Example;

however someone I am acquainted with swears by multiplication as in
delay until Next_Period; where Next_Period := Start + Iteration*Period;
instead, and demonstrated an example where it is more accurate. The
following MATLAB excerpt illustrates this:

">step=0.0001834567890123;
>next=0;, for k=1:1000000, next=next+step;, end;
>next

next =

183.4568

>step*1000000

ans =

183.4568

>next-step*1000000

ans =

2.8158e-009

>%I.e. non-zero."

So, why do the documents referenced above use an approach more susceptible
to rounding errors? The Ada 95 rationale examples were specifically given
in the context of being more accurate than another approach (having the
Ada 83 delay keyword and a relative time).

David Brach's paper "User experiences with the Aonix Ada RAVEN
Ravenscar Profile implementation" in "Ada Letters" December 2002
(apparently a reprint from the proceedings of the 11th international
workshop on Real-time Ada) has an alternative way of specifying
the times but it is still addition-based and for the purposes of
this discussion it seems to be equivalent to
Next_Period := Ada.Real_Time.Clock + Period;.

* Paul Colin Gloster:

however someone I am acquainted with swears by multiplication as in
delay until Next_Period; where Next_Period := Start + Iteration*Period;
instead, and demonstrated an example where it is more accurate. The
following MATLAB excerpt illustrates this:

Time_Span doesn't use floating point arithmetic in Ada, and this
effect doesn't occur.

Tue, 26 2004 19:16:54 +0200, Florian Weimer wrote:

* Paul Colin Gloster:
>
>however someone I am acquainted with swears by multiplication as in
>delay until Next_Period; where Next_Period := Start + Iteration*Period;
>instead, and demonstrated an example where it is more accurate. The
>following MATLAB excerpt illustrates this:
>
Time_Span doesn't use floating point arithmetic in Ada, and this
effect doesn't occur.

Right. However there could be other issues to consider:

1. The example given uses conversion of integer time cycle to time span. It
can become a source of cumulative error when 1 microsecond has no exact
representation in Time_Span. That depends on the underlying hardware.

2. What happens when the task misses a deadline? Usually it should skip one
"tick" and go to the next one.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Dmitry A. Kazakov wrote:

[snip]
>
Right. However there could be other issues to consider:
[snip]
>
2. What happens when the task misses a deadline? Usually it should skip one
"tick" and go to the next one.
>

Maybe yes, maybe no. I have built several system where if you run long
in one frame, you try to catch up the next one. For example, I may have
an 80 Hz task running. It is connected to a 1553 bus where at 1 Hz, I
get more messages than any other 80 Hz frame. If I overrun that one
frame (out of 80), I don't mind running the next frame a little late.

It all depends on the application being designed and the safety (or
accuracy) considerations of that design.

Wed, 27 2004 08:46:29 -0500, Mark H Johnson wrote:

Dmitry A. Kazakov wrote:
>
>[snip]
>>
>Right. However there could be other issues to consider:
>[snip]
>>
>2. What happens when the task misses a deadline? Usually it should skip one
>"tick" and go to the next one.
>>
Maybe yes, maybe no. I have built several system where if you run long
in one frame, you try to catch up the next one. For example, I may have
an 80 Hz task running. It is connected to a 1553 bus where at 1 Hz, I
get more messages than any other 80 Hz frame. If I overrun that one
frame (out of 80), I don't mind running the next frame a little late.
>
It all depends on the application being designed and the safety (or
accuracy) considerations of that design.

Yes, if you change the requirements. (:-)) However, surely, it is
questionable whether jitter and even more so, a small absolute time lag is
a real issue in say 80-100% cases. In my ignorance I always had an
impression that guys developing controllers are just too lazy. They are
pushing the problems with their bad models to us, pure programmers! (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Dmitry A. Kazakov wrote:

Wed, 27 2004 08:46:29 -0500, Mark H Johnson wrote:

>>It all depends on the application being designed and the safety (or
>>accuracy) considerations of that design.
>
>
Yes, if you change the requirements. (:-)) However, surely, it is
questionable whether jitter and even more so, a small absolute time lag is
a real issue in say 80-100% cases. In my ignorance I always had an
impression that guys developing controllers are just too lazy. They are
pushing the problems with their bad models to us, pure programmers! (:-))
>
Nah. I just don't try to build brittle systems. Jitter is a fact of
life. A 1 msec jitter on start time may be K in one case but completely
unacceptable in another. I know one system with a 50 usec window (every
12.5 msec) to receive a message otherwise it will go into "safe mode"
and take several minutes to recover. We don't even TRY to feed that data
with a software interrupt handler - we set up the transfer in advance
and use a hardware trigger to send the data.

In the case of missing a deadline, the action still should be
application specific.