X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Mon, 26 Mar 2012 10:51:59 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: clock_getres(CLOCK_REALTIME, .) may return an outdated and too high resolution Message-ID: <20120326085159.GJ2425@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4F6B65A7.9080605@t-online.de> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: 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 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. 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 > >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(). Yes, I'm going to do that. I think you're right on all accounts, I'm just feeling a bit uncomfortable with clock_setres always returning the coarsest resolution. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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