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

Corinna Vinschen wrote:
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.

Sorry, I probably forgot to mention that NtSetTimerResolution returns the same useless actual value than NtQueryTimerResolution.

I would suggest:

    status = NtSetTimerResolution (period, TRUE, &actual);
    if (!NT_SUCCESS (status))
      { ... return -1; }
 -  minperiod = actual;
 +  minperiod = period;

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

The problem is that unlike the OS we don't have interrupts and probably don't want to start an extra thread which does timer calibrations.

It may be possible to implement a clock_gettime(CLOCK_REALTIME) which has the following properties (in most cases:-):
- Absolute time returned is in interval [GetSystemTime, GetSystemTime+coarsest)
- Differences between two returned times provide the resolution of the PerformanceCounter if the difference is small (tens of seconds).
I probably will have some time to check this next week.


-- Problem reports: FAQ: Documentation: Unsubscribe info:

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