Re: [boost] Low-level precision timer proposal

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2006-05-16 03:46:24

Peter Dimov wrote:
> John Maddock wrote:
>> Silex wrote:
>>> I found out that there's already
>>> <boost/date_time/microsec_time_clock.hpp>, but on windows it uses
>>> GetSystemTimeAsFileTime().
>>>
>>> This raises a potential issue: I don't know if
>>> GetSystemTimeAsFileTime() works at millisecond resolution like
>>> QueryPerformanceCounter() does, and I don't know if
>>> QueryPerformanceCounter() returns some kind of epoch.. the docs are
>>> rather lowly-documented on this.
>>
>> Ah, I suspect there may be problems with the CPU clock changing speed
>> with some of these timers, I'm not sure though...
>
> The problem with GetSystemTimeAsFileTime is that it can jump an hour
> forward/backward as DST kicks in/out.
>
> The problem with QueryPerformanceCounter is that
> QueryPerformanceFrequency
> is not (AFAIK) required to return the same value every time. It may
> be CPU clock based, and a low power CPU can vary its frequency
> depending on load.

I guess that's true. However I seem to recall that the Linux 2.4 kernel
based gettimeofday on rdtsc, so I wonder how reliable gettimeofday really is
on portable computers. Perhaps some other implementation is selected for
certain platforms.

The QPF docs state that the frequency never change while the system is
running, which is rather ambiguous. The word "frequency" could simply refer
the value returned by QPF and not the actual hardware counter; "while the
system is running" might, or might  not include going back and forth to/from
sleep mode/hibernation. For uniprocessor systems QPC is most often not
rdtsc-based, so those should pose lesser problems.

My guess is that a monotonic timer solution based on QPC/QPF should be
good enough for at least 90% of all applications. It's not the ultimate, but 
a
library could provide a class parameterized on the actual implementation
(boost could provide the QPC / gettimeofday implementations
out-of-the-box as the default values under the different platforms). This, 
in
combination with providing a disclaimer that explains the limitations under
Windows, should be sufficient. People needing better than this could roll
their own implementation.

As for implementing a high-res calendar time provider under Windows - I
frankly think that it's next to impossible to implement a general-purpose
implementation that works for the all the different possible hardware
configurations. Perhaps a custom driver would make it possible. For specific
hardware configurations I _do_ think it's possible - but I still wouldn't
leave any guarantees until after doing some system-specific testing and
verification. Perhaps not even then - it is hard to test whether the results
are actually correct or not.

>
> We don't have a good TIME_MONOTONIC solution, and we really do need
> one for the threading library.

I guess the TIME_MONOTONIC stuff would mostly be used for sleep(). As there
is no way to explicitly make a thread sleep less than the clock tick under
Windows[*] - why do we need a high-res monotonic counter solution for the
thread library? Or did I misunderstand you (probably)?

> FWIW, I have found timeGetTime pretty reliable on Windows as a
> monotonic
> time provider. It only has 1ms resolution, though.
>

That might very well be a good solution. OTOH, I've never had any problems
with using QPC myself.

Just my 0.02EUR.

// Johan

[*] Ok, not strictly true:
- Sleep(0) causes a yield which _could_ return within a clock tick if no
other threads are in the ready state. But that's not strictly a sleep.
- A thread waiting for I/O will be activated whenever the I/O is
completed (normal restrictions apply with regards to priorities etc).