X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org Message-ID: <4F6B65A7.9080605@t-online.de> Date: Thu, 22 Mar 2012 18:47:19 +0100 From: Christian Franke 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" X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list 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--