[reSIProcate] Timer vulnerability

[Alan Hawrylyshen]

On Apr 12, 2005, at 12.38, kenho at bluebottle.com wrote:

> Alan,
>
> I presume the scenario you described is very real and is possible to 
> happen to QueryPerformanceCounter() and the likes, but GetTickCount()?
> Although I have verify this myself, MSDN library clearly states that 
> GetTickCount() returns the number of *milliseconds* that have elapsed 
> since the system was started (note that it also says on WinCE, it 
> excludes time suspended, but I failed to find similar statement 
> regarding other windows families).
>
> Ken
>
> Alan Hawrylyshen wrote:
>
>> One of the BIG problems with GetTickCount and families is that they 
>> no longer produce monotonically increasing results.
>> On devices with Intel SpeedStep technology (for example) or other 
>> power management technologies, the TickCount can move in very 
>> unpredictable ways. This results is wildly inaccurate timers. Care 
>> must be taken to select a replacement (if done) that does not make 
>> use of a fundamental that varies non-linearly.  On a plus side, we 
>> can get rid of any direct calls to time() since having a contained 
>> Time utility class is a Good Thing™.
>>
>> Alan
>>
>> a l a n a t j a s o m i d o t c o m
>>
>>

Ken;

I suspect that GetTickCount() may not suffer this exact problem, I just 
wanted to raise awareness of the problems we have seen in the past.  If 
GetTickCount is assured to be n-milliseconds since last restart, it may 
form a useful basis for the timer refactoring.  sysinfo() on linux may 
have a reasonable similar behaviour.  For solaris and other systems I'd 
recommend just implementing a layer over the gettimeofday() call like 
we already do. People can address this vulnerability as they see fit on 
those platforms.

Alan

a l a n a t j a s o m i d o t c o m