-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test 573 failing in original mingw #1531
Comments
Oops. With only millisecond resolution on the timer and everything happening within that single millisecond, the connect time is (correctly) evaluated to be zero... which the test doesn't like. A connect is supposed to take at least a tiny amount of time! =) One (lame) way to fix this could be to have A better way would probably be to use a timer on windows with better resolution... |
Setting a timer resolution smaller than the default in Windows (usually 15ms, Server versions may differ) will set it for all programs and also increases battery drain. There is a way to get RDTSC in Windows (Query Performance Counter API) however that will vary with processor speed I believe so for example you take a measurement and then the processor speed changes and changes back before you take another measurement, I don't think it's accurate for telling time in a case like that (I'm thinking SpeedStep, maybe I'm wrong). |
@jay According to the QueryPerformanceFrequency documentation, "the frequency of the performance counter is fixed at system boot." |
If a sub-15-millisecond timer is a problem, then I think I favor my first suggestion: we change the internal time stamps to count microseconds and then we can just add a microsecond or something if it seems to store a zero elapsed time. |
@MarcelRaad thanks. I just finished reading Windows documentation Acquiring high-resolution time stamps which I recommend to anyone who wants to know more about this. |
This gives us accurate precision and it allows us to avoid storing "no time" for systems with too low timer resolution as we then bump the time up to 1 microsecond. Should fix test 573 on windows. Remove the now unused curlx_tvdiff_secs() function. Maintains the external getinfo() API with using doubles. Fixes #1531
So #1549 is basically my take at the approach I mentioned. |
This gives us accurate precision and it allows us to avoid storing "no time" for systems with too low timer resolution as we then bump the time up to 1 microsecond. Should fix test 573 on windows. Remove the now unused curlx_tvdiff_secs() function. Maintains the external getinfo() API with using doubles. Fixes #1531
I did this
./runtests.pl -p 573
fails during comparison of connect time:
connect time 0.000000e+000 is < epsilon 1.084202e-019
log
curl/libcurl version
operating system
Windows 7 x64 Enterprise
The text was updated successfully, but these errors were encountered: