From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,cae92f92d6a1d4b1 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ada.Execution_Time Date: Tue, 28 Dec 2010 16:46:20 +0200 Organization: Tidorum Ltd Message-ID: <8nubhsF6e8U1@mid.individual.net> References: <4d05e737$0$6980$9b4e6d93@newsspool4.arcor-online.net> <1wmsukf0wglz3$.odnzonrpayly.dlg@40tude.net> <6n1c5myuf2uz$.10jl3ln7il3aq.dlg@40tude.net> <8n0mgnFv2sU1@mid.individual.net> <1n3o55xjdjr9t.1u33kb75y2jfl$.dlg@40tude.net> <8n1142Fto2U1@mid.individual.net> <1o5cbm4b1l20d$.19winbma6k5qw.dlg@40tude.net> <8n4mskF7mmU1@mid.individual.net> <8nm30fF7r9U1@mid.individual.net> <1akm5muxu9zni.mu91b7pubqw0$.dlg@40tude.net> <8nrg25FoucU1@mid.individual.net> <2k07hwmh6123.1pgx57welw9of$.dlg@40tude.net> <8nsa76Fj4rU1@mid.individual.net> <1j9i6trxinqtg$.renlw9wdtpsf.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net tx5Viw8oSWejOHg+dRLf6Ar438Ht1W0M/13ZxGUs8MLwBPT65z Cancel-Lock: sha1:HcgQgbUnOrseNmtxqNDd0qIg2EU= User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) In-Reply-To: <1j9i6trxinqtg$.renlw9wdtpsf.dlg@40tude.net> Xref: g2news2.google.com comp.lang.ada:17165 Date: 2010-12-28T16:46:20+02:00 List-Id: 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 . @ .