Re: Ada.Execution_Time

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 17 Dec 2010 13:50:26 +0200, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> On Fri, 17 Dec 2010 10:49:26 +0200, Niklas Holsti wrote:
>> 
>>> Dmitry A. Kazakov wrote:
>>>> CPU_Time has no physical meaning. 2s might be 2.5s
>>>> real time or 1 year real time.
>>> CPU_Time values have physical meaning after being summed over all tasks. 
>>> The sum should be the real time, as closely as possible.
>> 
>> 1. Not tasks, but threads + kernel services + kernel drivers + CPU
>> frequency slowdowns => a) wrong; b) out of Ada scope => cannot be mandated
> 
> I believe we are talking about the intended meaning of 
> Ada.Execution_Time.CPU_Time, not about how far it can be precisely 
> "mandated" (standardized).
> 
> Appendix D is about real-time systems, and I believe it is aimed in 
> particular at systems built with Ada tasks and the Ada RTS. In such 
> systems there may or may not be CPU time -- "overhead" -- that is not 
> included in the CPU_Time of any task. See the last sentence in RM D.14 
> 11/2: "It is implementation defined which task, if any, is charged the 
> execution time that is consumed by interrupt handlers and run-time 
> services on behalf of the system". In most systems there will be some 
> such non-task overhead, but in a "pure Ada" system it should be small 
> relative to the total CPU_Time of the tasks.

Yes, this is what I meant. CPU_Time does not have the meaning:

"CPU_Time values have physical meaning after being summed over all tasks. 
The sum should be the real time, as closely as possible."

Anyway, even if the sum of components has a physical meaning that does not
imply that the components have it.

> By "CPU frequency slowdowns" I assume you mean a system that varies the 
> CPU clock frequency, for example to reduce energy consumption when load 
> is low. This do not necessarily conflict with Ada.Execution_Time and the 
> physical meaning of CPU_Time, although it may make implementation 
> harder. One implementation could be to drive the CPU-time counter by a 
> fixed clock (a timer clock), not by the CPU clock.

I am not a language lawyer, but I bet that an implementation of
Ada.Execution_Time.Split that ignores any CPU frequency changes when
summing up processor ticks consumed by the task would be legal.

>> 2. Not so anyway under many OSes => again, cannot be mandated
> 
> Whether or not all OSes support the concepts of Ada.Execution_Time is 
> irrelevant to a discussion of the intended meaning of CPU_Time.

ARM usually does not intend what would be impossible to implement.

> "Simulation", "projection"... convey no meaning to me.

http://en.wikipedia.org/wiki/Discrete_event_simulation

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