Re: Ada.Execution_Time

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

Dmitry, from now on I am going to respond only to those of your comments 
that to me seem to make some kind of sense and have not been discussed 
before. From my omissions you may deduce my opinion of the remainder.

Dmitry A. Kazakov wrote:
>>> 2. It would be extremely ill-advised to use Ada.Execution_Time instead of
>>> direct measures for an implementation of time sharing algorithms.
Niklas Holsti replied:
>> If by "direct measures" you mean the use of some external measuring 
>> device such as an oscilloscope or logic analyzer, such measures are 
>> available only externally, to the developers, not within the Ada program 
>> itself.
Dmitry:
> You forgot one external device called real time clock.

And you seem to forget that Ada.Execution_Time may be implemented by 
reading a real-time clock. As has been said before.

Dmitry:
>>> I don't
>>> care how much processor time my control loop takes so long it manages to
>>> write the outputs when the actuators expect them.
Niklas:
>> You should care, if the processor must also have time for some other 
>> tasks of lower priority, which are preempted by the control-loop task.
Dmitry:
> Why? It is straightforward: the task of higher priority level owns the
> processor.

Do you mean that your system has only one task with real-time deadlines, 
and no CPU time has to be left for lower-priority tasks, and no CPU time 
is taken by higher-priority tasks? Then scheduling is trivial for your 
system and your system is a poor example for a discussion about scheduling.

Niklas:
>> For example, assume that the computation in a control algorithm consists 
>> of two consecutive stages where the first stage processes the inputs 
>> into a state model and the second stage computes the control outputs 
>> from the state model. Using Ada.Execution_Time or 
>> Ada.Execution_Time.Timers the program could detect an unexpectedly high 
>> CPU usage in the first stage, and fall back to a simpler, faster 
>> algorithm in the second stage, to ensure that some control outputs are 
>> computed before the deadline.
Dmitry:
> No, in our systems we use a different schema.

So what? I said nothing (and know nothing) about your system, any 
resemblance is coincidental. And there can be several valid schemas.

> The "fall back" values are
> always evaluated first. They must become ready at the end of each cycle. A
> finer estimation is evaluated in background and used when ready.

So your problem is different (the coarse values are the rule). Different 
problem, different solution.

> In general, real-time systems are
> usually designed for the worst case scenario,

Yes, but this is often criticized as inefficient, and there are 
scheduling methods that make good use of the difference (slack) between 
actual and worst-case execution times. These methods need something like 
Ada.Execution_Time. As has been said before.

> Consider a system with n-processors. The execution
> time second will be 1/n of the real time second.

No. If you have n workers digging a ditch, you must pay each of them the 
same amount of money each hour as if you had one worker. So the "digging 
hour" is still one hour, although the total amount of work that can be 
done in one hour is n digging-hours. You are confusing the total amount 
of work with the amount of work per worker.

With n processors the system can do n seconds worth of execution in one 
real-time second. But each processor still executes for one second. And 
as I understand the Ada task dispatching/scheduling model, one task 
cannot execute at the same time on more than one processor, so one task 
cannot accumulate more than one second of execution time in one second 
of real time.

(At the risk of introducing another side issue, I note that an 
automatically parallelizing compiler might make a task use several 
processors in parallel, at least for some of the time. But I don't think 
that RM D2.1 considers this possibility.)

> With shared memory it will
> be f*1/n, where f is some unknown factor.

I agree that variable memory access times, and other dynamic timing that 
may depend on the number of processors and on how they share resources, 
is a complicating factor in the analysis of CPU loads and 
schedulability. Indeed this is why I fear that the concept of "the 
execution time of task" is becoming fearsomely context-dependent and 
therefore problematic -- something that you disagreed with.

For the definition of Ada.Execution_Time, memory access latency is 
relevant only if the Ada RTS suspends tasks that are waiting for memory 
access, so that they are "not executing" until the memory access is 
completed. Most RTOSes do not suspend tasks in that way, I believe.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .