Re: accuracy

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:r5rrsmngabou$.nc73hmyyugax.dlg@40tude.net...
> 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);

That's documented as applying to "Multimedia timers", whatever those are. I
wouldn't want to assume it would work on thread times and the like which
have nothing to do with multimedia. Besides, why wouldn't the maximum
accuracy alway be used if it is possible? What possible value is there in
using a less accurate time (given that you still have to do the math on
every switch no matter what the accuracy is involved)??

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

Why? Ada.Real_Time is built on top of the performance counters, so is all of
your tasking programs.

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

I don't think so, I tried my profiling code there, too, and didn't get any
more accuracy.

...
> > 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.

Humm, I find that nearly impossible to believe. I'd expect some other cause
(*any* other cause) before I believed that. (Outside of device drivers,
anyway, which would be a lousy place to use this sort of timing.) I guess
I'd have to see a detailed example of that for myself before I believed it.

                                                   Randy.