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

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

[Paul Colin Gloster]

For cyclic processes, at least in Ada literature such as

Section Two 9.3 of "Ada 95 Rationale: The Language, The Standard Libraries",
WWW.AdaIC.org/standards/95rat/RAThtml/rat95-p2-9.html#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,
HTTP://WWW.CS.York.ac.UK/ftpdir/reports/YCS-2003-348.pdf 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; --with 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; --Ada.Real_Time.Clock
                                                   --returns 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 ObjectAda 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;.

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

[Florian Weimer]

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

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

[Dmitry A. Kazakov]

On Tue, 26 Oct 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

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

[Mark H Johnson]

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

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

[Dmitry A. Kazakov]

On Wed, 27 Oct 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

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

[Mark H Johnson]

Dmitry A. Kazakov wrote:

> On Wed, 27 Oct 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 OK 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.

   --Mark