Igor and all,

Several things...

1) First of all Windows is not a RTOS.

2) Hardware on which Windows runs, introduces additional timing quirks
related mostly with energy saving that influence 'software' time
measurements.

3) The only function that will report the least fake results for
measuring time differences is GetTickCount(). All other timing
functions are software implementations provided by Windows, included
QueryPerformanceCounter related ones, to make believe that high
precision is possible on a non RTOS.

4) GetTickCount() has different precision on different systems. Trying
to measure timer sub precision time-spans is actually just a matter of
faith, It can't be actually measured, even if fake timing methods are
used to make believe that Windows is a RTOS.

5) GetTickCount() runs a hell faster than any other Windows timing
method, which in any case internally will call GetTickCount() at least
once and run additional code to fake precision which Windows doesn't
have.

6) Timing a timer function is tricky. And one thing that you shall not
do when attempting to do so is introduce functions which don't have a
fixed execution time. In the TimerIssue.cpp test you provided in first
message you have a Sleep(2) statement inside a loop. Even when you are
instructing Windows to sleep for 2 ms, Windows will do its best to
achieve that sleep time but it won't be able to satisfy that request
on all hardware. On a 55ms precision hardware it may represent a worst
case wait of nearly 110ms. Tricky ;-) but plain true.

Given all the above and enough background widely available, I
sincerely recommend for Windows systems _not_ changing libcurl
internal usage of GetTickCount() in favour of any other Windows timing
mechanism.

Daniel Stenberg wrote:

> One thing that also struck me is that libcurl already has a provision
> (since 7.18.2) that makes it add 1000 microseconds to the check time,
> so if the timeout fires off less than 1 millisecond before the actual
> timeout shouldn't be a problem. Can you (Igor) confirm that you're
> using at least this version and that this addition really doesn't help?
> Are you perhaps more than 1000 microsekunds off?

As a matter of fact for Windows, in order to not miss _any_ timing
event on any system, most probably we should account for timing errors
(or imprecision) of 100 miliseconds for any time difference
measurement.

Whether we have a libcurl problem (bug) somewhere related to how all
this is taken in consideration is something I have no time at all to
look up in a short time frame.

Cheers

-- 
-=[Yang]=-
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html