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: 
 g2news1.google.com!news3.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Ada.Execution_Time
Date: Thu, 30 Dec 2010 15:34:08 +0200
Organization: Tidorum Ltd
Message-ID: <8o3g2hF15tU1@mid.individual.net>
References: <ie1ih9$d02$1@news.eternal-september.org>
 <ie2v2k$aps$1@tornado.tornevall.net> <ie3gjn$oj$1@news.eternal-september.org>
 <4d05e737$0$6980$9b4e6d93@newsspool4.arcor-online.net>
 <ie91co$cko$1@news.eternal-september.org> <iebe2t$eua$1@munin.nbi.dk>
 <1wmsukf0wglz3$.odnzonrpayly.dlg@40tude.net>
 <iedfud$ul1$1@news.eternal-september.org>
 <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>
 <bboyk178uyce.1jx52xgjoblk1$.dlg@40tude.net>
 <8nm30fF7r9U1@mid.individual.net> <ifb2ts$l0m$1@munin.nbi.dk>
 <8o0p0lF94rU1@mid.individual.net> <aooml6t0ezs4.4srxtfm9z00r.dlg@40tude.net>
 <8o1k6vFbd7U1@mid.individual.net>
 <1k7xzi2uradva$.atlfxh9h94qb$.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 jbrI5Swd7lkg0z1aqgM5WADM67I/NDPMN26TI2/0aavq/JwFbE
Cancel-Lock: sha1:nv9xWmArtmjz24sFB8QekzH2vRQ=
User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328)
In-Reply-To: <1k7xzi2uradva$.atlfxh9h94qb$.dlg@40tude.net>
Xref: g2news1.google.com comp.lang.ada:16257
Date: 2010-12-30T15:34:08+02:00
List-Id: <comp.lang.ada>

Dmitry A. Kazakov wrote:
> On Wed, 29 Dec 2010 22:32:30 +0200, Niklas Holsti wrote:
> 
>> Dmitry A. Kazakov wrote:
>>> Model C. Asynchronous task monitoring process
>> That sounds weird. Please clarify.
> 
> For example, in the kernel you have a timer interrupt each n us. Within the
> handler you get the current TCB and increment the CPU usage counter there
> by 1. CPU_Time returned by Clock yields Counter * n us. This is a quite
> lightweight schema, which can be used for small and real-time systems. The
> overhead is constant.

Yes, that is one possible implementation, and not a bad one, although 
the CPU_Tick will probably be relatively large, and may have some 
jitter. The definition of Ada.Execution_Time.CPU_Tick as the *average* 
constant-Clock duration would come into play.

In principle this implementation is not much different from the simple, 
hardware-driven, directly readable counter of nanoseconds or CPU clock 
cycles. The only difference is that here the "counter" is driven by a 
timer-generated interrupt, not by a hardware clock generator, and it is 
easier to make task-specific counters.

>> Again, it holds within the accuracy of the measurement method and the 
>> time source, which is all that one can expect.
> 
> The error is not bound. Only its deviation is bound, e.g. x seconds per
> second of measurement.

Yes, as for different unsynchronized clocks in general. I don't think 
this is a problem for the intended uses of Ada.Execution_Time, as I 
understand them.

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