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,TW_LR,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY
X-Spam-Check-By: sourceware.org
Message-ID: <4F70A0C9.5060208@t-online.de>
Date: Mon, 26 Mar 2012 19:00:57 +0200
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> <4F6B65A7 DOT 9080605 AT t-online DOT de> <20120326085159 DOT GJ2425 AT calimero DOT vinschen DOT de>
In-Reply-To: <20120326085159.GJ2425@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Corinna Vinschen wrote:
> On Mar 22 18:47, Christian Franke wrote:
>> Corinna Vinschen wrote:
>>> 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.
> I see your point, but what bugs me a bit is the fact that
> clock_getres(CLOCK_REALTIME) and clock_setres(CLOCK_REALTIME) will
> always return the same value coarsest, regardless what value has been set.

If clock_setres was called and succeeded, then clock_getres(.) should 
return the value set before.

If clock_setres was not called, the coarsest value is IMO the only value 
that can be guaranteed.

The actual value returned by NtQueryTimerResolution is simply useless in 
this context: It is the minimum of all resolutions currently set by all 
running processes. It may change at any time. There is apparently no way 
the query the current setting of the current process.


clock_gettime is part of the POSIX realtime extensions. On Linux it 
requires -lrt which implies -lpthreads. So if clock_gettime is used we 
can probably assume that the program wants a finer resolution.

This leads to a possible alternative if clock_setres is not used: On 
first call of clock_gettime/getres set a finer (the finest?) resolution 
and return this with clock_getres.

Drawback: The finer resolution will persist until this process and all 
childs terminate. This may have unknown impact on performance, power 
management or whatever.

This could be fixed by resetting the resolution to default if 
clock_gettime is no longer used for some time (e.g. >= 10min).

Drawback: Even more complexity :-)


> I added this comment to clock_setres at one point:
>
>    /* Convert to 100ns to match OS resolution.  The OS uses ULONG values
>       to express resolution in 100ns units, so the coarsest timer resolution
>       is<  430 secs.  Actually the coarsest timer resolution is only slightly
>       beyond 15ms, but this might change in future OS versions, so we play nice
>       here. */
>
> So, what if the OS really returns bigger values in coarsest at one
> point?  I know, I know, that's unlikely to the point of non-existence.
>
>> - Unlike on e.g. Linux, CLOCK_REALTIME does not provide a better
>> resolution than gettimeofday().
> We can only use what the OS provides.  Starting with Windows 8 there
> will be a new function call GetSystemTimePreciseAsFileTime:
> http://msdn.microsoft.com/en-us/library/windows/desktop/hh706895%28v=vs.85%29.aspx

This would provide an easy solution for >= Win8: clock_gettime returns 
GetSystemTimePreciseAsFileTime, clock_getres returns constant 1us.

Christian


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