Message-ID: <4F6B65A7.9080605@t-online.de>
Date: Thu, 22 Mar 2012 18:47:19 +0100
From: Christian Franke <Christian DOT Franke AT t-online DOT de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Firefox/10.0.2 SeaMonkey/2.7.2
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: clock_getres(CLOCK_REALTIME, .) may return an outdated and too high resolution
References: <4F6A5D42 DOT 3030108 AT t-online DOT de> <20120322093340 DOT GW18032 AT calimero DOT vinschen DOT de>
In-Reply-To: <20120322093340.GW18032@calimero.vinschen.de>
Content-Type: multipart/mixed; boundary="------------090605070400060101080803"
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

--------------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--