Re: accuracy

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

On Fri, 9 Mar 2007 19:39:30 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p87mtsns4of0.hhld0y03415s.dlg@40tude.net...
> ...
>> As for GetThreadTimes, its absolute precision is 1ms.
> 
> No, it is 10ms. The interface offers more precision than is actually
> provided.

You can force it to 1ms using

   timeBeginPeriod (1);

This what any tasking Ada program should not forget do, when it starts
under Windows. I hope that GNAT RTL does this...

(I am too lazy to check it, but probably XP already has 1ms as the default)

>> Its suggested
>> absolute accuracy should be one time quant (which duration depends on the
>> system settings). The later does not hold, because the error is in fact not
>> bounded.
> 
> I believe that the function was intended for profiling and performance
> monitoring, and it surely is not different than any other technique I've
> ever seen used for that. All such techniques give you a statistical
> approximation to the real behavior. You just have to run them long enough to
> make the results statistically significant.

(under the condition that the error mean is 0, which unfortunately is not
the case)

> It's theoretically possible for a thread to run in sync so that it never
> gets a tick, but I've never seen (or heard of) an instance of that happening
> in a real program being profiled. On a real DOS or Windows system, there is
> too much asynchronous going on for any "lock-step" to continue for long.

Which theoretical case hit me. We performed a QoS studio of our distributed
middleware and wished to measure the time its services require for
publishing and subscribing, separately from delivery times. To our
amazement times of some services were solid 0, no matter how long and how
many cycles we run the test! I started to investigate and discovered that
mess.

> In any case, it is statistical analysis that has to be applied here; it's
> clear that the error can be reduced by lengthening the runtime (presuming
> that you are willing to assume, as I am, that behavior is essentially random
> if looked at over a long enough time period).

(plus some assumption about the error mean. Otherwise the averaged result
can be any.)

> OTOH, I don't want to use Ada.Execution_Times to control a program's
> behavior. (I think that's a bit dubious, given that a hardware change would
> invalidate the assumptions, and typically the important thing is the
> response time: which depends on the wall-time, not the CPU time. But a
> self-contained embedded system has more control than a program running on
> Windows, so it might make sense somewhere.)

I believe there are logical/philosophical reasons why a program shall not
change its behavior depending on its ... behaviour. (:-))

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