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: Thu, 30 Dec 2010 21:23:25 +0200 Organization: Tidorum Ltd Message-ID: <8o44hfFsarU1@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> <8o0p0lF94rU1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net eMkZme4mf9MNW48jEsUT2wQsVWCosFjxo3OakTR4CtUSR64y0c Cancel-Lock: sha1:vfsjp5IE5S9BqQm6n2fJEaxDz+I= User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) In-Reply-To: Xref: g2news2.google.com comp.lang.ada:17236 Date: 2010-12-30T21:23:25+02:00 List-Id: Dmitry A. Kazakov wrote: > On Wed, 29 Dec 2010 14:48:20 +0200, Niklas Holsti wrote: > >> Dmitry has agreed with some of my statements on this point, for example: >> >> - A task cannot accumulate execution time at a higher rate than real >> time. For example, in one real-time second the CPU_Time of a task cannot >> increase by more than one second. > > Hold on, that is only true if a certain model of CPU_Time measurement used. > There are many potential models. The one we discussed was the model A: > > Model A. Get an RTC reading upon activation. Each time CPU_Time is > requested by Clock get another RTC reading, build the difference, add the > accumulator to the result. Upon task deactivation, get the difference and > update the accumulator. [ cut ] > Note that in either model the counter readings are rounded. Windows rounds > toward zero, which why you never get more load than 100%. But it is > thinkable and expectable that some systems would round away from zero or to > the nearest bound. The RTEMS CPU Usage Statistics function in fact rounds up: "RTEMS keeps track of how many clock ticks have occurred which [should be "while"] the task being switched out has been executing. If the task has been running less than 1 clock tick, then for the purposes of the statistics, it is assumed to have executed 1 clock tick. This results in some inaccuracy but the alternative is for the task to have appeared to execute 0 clock ticks." (Quoted from http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.9.4/share/rtems/pdf/c_user.pdf, page 285). I think that rounding up may indeed be better (safer) for real-time scheduling and monitoring purposes. But of course this is just changing the direction of the inaccuracy, the principle stands. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .