Mail Archives: cygwin/2012/03/22/13:48:11
--------------090605070400060101080803
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Corinna Vinschen wrote:
> On Mar 21 23:59, Christian Franke wrote:
>> clock_getres(CLOCK_REALTIME,&ts) queries the actual resolution through
>> NtQueryTimerResolution (&coarsest,&finest,&actual) during its
>> first call and returns this value unchanged afterwards.
>>
>> This returns a global Windows setting which may be temporarily
>> modified by other applications by using e.g. timeBegin/EndPeriod().
>> For example playing a flash video in browser sets the resolution to
>> 1ms. It is reset to default ~15ms when the browser is closed.
>>
>> As a consequence the actual resolution might be much lower than
>> reported by clock_getres() when clock_gettime() is used for
>> measurements later. It would IMO be better to return the 'coarsest'
>> instead of the 'actual' value.
> clock_getres already returns the coarsest time. Did you mean the
> setting in hires_ms::resolution, by any chance? It's using the
> actual setting right now.
No. Yes.
No, clock_getres(CLOCK_REALTIME, .) returns gtod.resolution() which
calls hires_ms::resolution().
Yes, I mean this function which returns the 'actual' value from
NtQueryTimerResolution(:-).
>> If clock_setres() is used, this setting should be returned instead
>> of the 'actual' value at the time of the setting.
> Well, I'm not overly concerned about clock_setres, given that it's
> probably not used at all :)
Yes, it is not POSIX and does not exist on Linux, FreeBSD, ...
It IMO is useful as CLOCK_REALTIME does only provide a rather coarse
default resolution on Cygwin.
>> BTW: GetSystemTimeAsFileTime() apparently provides the same
>> resolution (at least on Win7 x64). So the more complex use of
>> SharedUserData.InterruptTime may have less benefit than expected.
> On pre-Vista, the accuracy of GetSystemTimeAsFileTime is 15.625 ms,
> fixed. On Vista and later it seems to be 15ms or better, but its
> resultion is not constant anymore.
Here a run of a test program (attached) and some concurrent activities.
Program prints observable resolutions of 3 clocks (clock_getres()
results in parentheses):
[1] ./testres started/stopped to read default resolutions.
SystemTime CLOCK_REALTIME (getres) CLOCK_MONOTONIC (getres)
0.0156000 0.015600000 (0.015600000) 0.000000301 (0.000000301) ...
^C
[2] flash video started in SeaMonkey
[3] ./testres started
SystemTime CLOCK_REALTIME (getres) CLOCK_MONOTONIC (getres)
0.0010000 0.001000000 (0.001000000) 0.000000302 (0.000000301) ...
0.0005000 0.000500000 (0.001000000) 0.000000302 (0.000000301) [4]
0.0010000 0.001000000 (0.001000000) 0.000000301 (0.000000301) [5]
0.0156000 0.015600000 (0.001000000) 0.000000302 (0.000000301) [6]
Where:
[4] VM started in VirtualBox
[5] VM closed
[6] SeaMonkey closed
Conclusions:
- clock_getres() returns the 'actual' resolution from its first call.
IMO this is a bug.
- The actual resolution may change without notice unless an application
sets the min resolution (500us on this machine) itself.
- On Win7, GetSystemTimeAsFileTime() provides same resolution as
InterruptTime and timeGetTime(). Could not test this on older Windows
versions yet.
- Unlike on e.g. Linux, CLOCK_REALTIME does not provide a better
resolution than gettimeofday().
> But I'm not shure either, if the timeGetTime_ns shuffle has any positive
> effect. Given that we allow a jitter of 40 ms, we''re potentially worse
> off than by just calling GetSystemTimeAsFileTime and be done with it.
> Also, all processes would be guaranteed to be on the same time, not only
> the processes within the same session sharing gtod.
>
If this is also the case for older Windows versions, it would be
probably better to revert to GetSystemTimeAsFileTime().
Christian
--------------090605070400060101080803
Content-Type: text/plain;
name="testres.cc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="testres.cc"
I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDx0aW1lLmg+CiNpbmNsdWRl
IDx1bmlzdGQuaD4KI2luY2x1ZGUgPHdpbmRvd3MuaD4KCnN0YXRpYyBsb25n
IGxvbmcgZ2V0X3dpbjMyX3RpbWUoaW50KQp7CiAgRklMRVRJTUUgZnQ7CiAg
R2V0U3lzdGVtVGltZUFzRmlsZVRpbWUoJmZ0KTsKICBMQVJHRV9JTlRFR0VS
IGl0ID0geyB7IGZ0LmR3TG93RGF0ZVRpbWUsIGZ0LmR3SGlnaERhdGVUaW1l
IH0gfTsKICByZXR1cm4gaXQuUXVhZFBhcnQ7Cn0KCnN0YXRpYyBsb25nIGxv
bmcgZ2V0X3Bvc2l4X3RpbWUoaW50IGlkKQp7CiAgdGltZXNwZWMgdHM7CiAg
aWYgKGNsb2NrX2dldHRpbWUoaWQsICZ0cykpCiAgICByZXR1cm4gLTE7CiAg
cmV0dXJuIHRzLnR2X3NlYyAqIDEwMDAwMDAwMDBMTCArIHRzLnR2X25zZWM7
Cn0KCnN0YXRpYyBsb25nIGxvbmcgZ2V0X3Bvc2l4X3JlcyhpbnQgaWQpCnsK
ICB0aW1lc3BlYyB0czsKICBpZiAoY2xvY2tfZ2V0cmVzKGlkLCAmdHMpKQog
ICAgcmV0dXJuIC0xOwogIHJldHVybiB0cy50dl9zZWMgKiAxMDAwMDAwMDAw
TEwgKyB0cy50dl9uc2VjOwp9CgpzdGF0aWMgbG9uZyBsb25nIGd1ZXNzX3Jl
c29sdXRpb24obG9uZyBsb25nICgqZikoaW50KSwgaW50IGlkID0gLTEpCnsK
ICBsb25nIGxvbmcgciA9IH4wVUxMPj4xOwogIGZvciAoaW50IGkgPSAwOyBp
IDwgNTsgaSsrKSB7CiAgICBsb25nIGxvbmcgdDEgPSBmKGlkKSwgdDI7CiAg
ICBkbwogICAgICB0MiA9IGYoaWQpOwogICAgd2hpbGUgKHQyID49IDAgJiYg
dDIgPT0gdDEpOwogICAgaWYgKHQyIC0gdDEgPCByKQogICAgICByID0gdDIg
LSB0MTsKICB9CiAgcmV0dXJuIHI7Cn0KICAgIAppbnQgbWFpbihpbnQgYXJn
YywgY2hhciAqKmFyZ3YpCnsKICBwcmludGYoIlN5c3RlbVRpbWUgIENMT0NL
X1JFQUxUSU1FIChnZXRyZXMpICAgICBDTE9DS19NT05PVE9OSUMgKGdldHJl
cykiKTsKICBsb25nIGxvbmcgcjEgPSAtMSwgcjIgPSAtMSwgcjMgPSAtMTsK
ICBpbnQgY250ID0gMDsKICBmb3IgKDs7KSB7CiAgICBsb25nIGxvbmcgcjFu
ID0gZ3Vlc3NfcmVzb2x1dGlvbihnZXRfd2luMzJfdGltZSk7CiAgICBsb25n
IGxvbmcgcjJuID0gZ3Vlc3NfcmVzb2x1dGlvbihnZXRfcG9zaXhfdGltZSwg
Q0xPQ0tfUkVBTFRJTUUpOwogICAgbG9uZyBsb25nIHIzbiA9IGd1ZXNzX3Jl
c29sdXRpb24oZ2V0X3Bvc2l4X3RpbWUsIENMT0NLX01PTk9UT05JQyk7Cgog
ICAgaWYgKHIxID09IHIxbiAmJiByMiA9PSByMm4gJiYgbGxhYnMocjMtcjNu
KSA8PSAxKSB7CiAgICAgIHByaW50ZigiJXMlNWQiLCAoY250ID8gIlxiXGJc
YlxiXGIiIDogIiIpLCBjbnQpOyBmZmx1c2goc3Rkb3V0KTsKICAgICAgc2xl
ZXAoMSk7CiAgICAgIGNudCsrOwogICAgfQogICAgZWxzZSB7CiAgICAgIHIx
ID0gcjFuOyByMiA9IHIybjsgcjMgPSByM247CiAgICAgIHByaW50ZigiXG4l
LjdmICAgJS45ZiAoJS45ZikgICAlLjlmICglLjlmKSIsCiAgICAgICAgcjEv
MTAwMDAwMDAuMCwKICAgICAgICByMi8xMDAwMDAwMDAwLjAsIGdldF9wb3Np
eF9yZXMoQ0xPQ0tfUkVBTFRJTUUpIC8xMDAwMDAwMDAwLjAsCiAgICAgICAg
cjMvMTAwMDAwMDAwMC4wLCBnZXRfcG9zaXhfcmVzKENMT0NLX01PTk9UT05J
QykvMTAwMDAwMDAwMC4wKTsKICAgICAgZmZsdXNoKHN0ZG91dCk7CiAgICAg
IGNudCA9IDA7CiAgICB9CiAgfQoKICByZXR1cm4gMDsKfQogCg==
--------------090605070400060101080803
Content-Type: text/plain; charset=us-ascii
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--------------090605070400060101080803--
- Raw text -