This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: clock_getres(CLOCK_REALTIME, .) may return an outdated and too high resolution

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:

> >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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]