Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #6670

Re: Time measuring on Windows

Show all headers | View raw

On 2016-05-29 18:32, BartC wrote:
> On 29/05/2016 16:16, Dmitry A. Kazakov wrote:
>> On 2016-05-29 11:53, BartC wrote:
>>> I need to measure how long short processes take to execute.
>>>
>>> All the docs point to using QueryPerformanceCounter() (as opposed to
>>> using, for example, the RDTSC machine instruction).
>
>>> but the problem is they are inconsistent.
>>
>> They are consistent, we are using performance counter for fine time
>> measurements. The time in seconds is obtained with
>> QueryPerformanceFrequency. Ticks do not make sense. 8ms is too short for
>> statistically correct measurements, e.g. when your thread loses
>> processor it will not return until next 10ms on a busy machine.
>
> Thanks, using QueryPerformanceFrequency I can now convert the QPC result
> to milliseconds.
>
> By using Sleep(N) as the task, I found that QPC gives results that are
> scattered by up to 10 milliseconds, sometimes more (although Sleep()
> seems to have its own considerable overheads when N is small).

Right, this is the effect of timer resolution. You cannot sleep for less 
than the timer resolution value. Which is 10ms by default. It depends on 
when you call Sleep in relation to the coming timer interrupt. The 
interrupt in effect will cause rescheduling, and that will wake up of 
the thread. So you have +0 to 10ms sleep time. If you called Sleep (0) 
you would have a similar effective sleep time as for Sleep (N) when N < 
Timer resolution. There is some statistical bias towards zero, but that 
is beside the point.

Using timeBeginPeriod you can reduce this to +0..1ms.

> I also found that C's clock() function only seems to be updated very
> 15msec or so. So maybe, there's a connection.

That's right. You should never use Windows system time functions. I 
suppose that clock() calls to the Windows system time API. System time 
is based on the time source derived from the timer, and thus its 
accuracy is 10ms by default, regardless the declared resolution, 
whichever it be.

If you want reliable and accurate time stamps you need to use 
QueryPerformanceCounter with a background thread synchronizing system 
UTC time with the performance counter ticks. It collect the performance 
counter and system time readings, throw out the artifacts caused by 
process switching, and average counter to the system time conversion 
coefficients (e.g. to FILETIME, a 64-bit 100ns resolution time). This is 
not trivial, but doable. This way you can get time stamps of ns 
resolution and accuracy.

I have developed a commercial C++ class library for this purpose. So I 
cannot give you more details regarding the algorithms.

> But by first waiting for a clock() transition, then starting to measure,
> QPC results were more consistent. Not perfect, but I think now more
> usable, and more precise than clock() for these short tasks.

The performance counter has the accuracy of the front bus tact, 
approximately. Which lies in the ns area. The system time has the 
accuracy of the timer interrupt, which is 10ms by default. So feel the 
difference!

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

Back to comp.programming | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Time measuring on Windows BartC <bc@freeuk.com> - 2016-05-29 10:53 +0100
  Re: Time measuring on Windows "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2016-05-29 17:16 +0200
    Re: Time measuring on Windows BartC <bc@freeuk.com> - 2016-05-29 17:32 +0100
      Re: Time measuring on Windows "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2016-05-29 19:04 +0200

csiph-web