X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Tue, 27 Mar 2012 11:10:51 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: clock_getres(CLOCK_REALTIME, .) may return an outdated and too high resolution
Message-ID: <20120327091051.GB30721@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> <20120326085159 DOT GJ2425 AT calimero DOT vinschen DOT de> <4F70A0C9 DOT 5060208 AT t-online DOT de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <4F70A0C9.5060208@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: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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

On Mar 26 19:00, Christian Franke wrote:
> Corinna Vinschen wrote:
> >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.

Uh, right, I misunderstood.  I reverted the change to clock_setres.

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

Not really.  The usage of clock_gettime only implies that somebody wants
to measure time in a certain way depending on the used clock.  It does
not imply any resolution requirements.  And POSIX does not require any
specific resolutions, rather they are "implementation-defined".

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

Nah, let's not go that route.  If you want a finer resolution by
default, I think there might be some other solution...

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

As far as I can tell from a quick debug session, the implementation
of the underlying RtlGetSystemTimePrecise function is based on a spiffy
combination of the standard clock tick with the performance counter.
I'm not very good at assembler debugging, but the essence is access
to some known and some unknown time values from SharedUserData, a
call to RtlQueryPerformanceCounter, and a bit of arithmetic.

Maybe we can implement something similar without waiting for W8?  Does
anybody have code to combine a not so precise clock with a more precise
counter to create a more precise clock?


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