Re: clock_getres() and real resolution

[Richard Cochran <richardcochran@gmail.com>]

On Thu, Feb 09, 2012 at 11:32:16AM -0800, Dmitry Antipov wrote:
> On 02/09/2012 10:40 AM, Richard Cochran wrote:
> 
> >I thought this list was about Linux kernel development, but now it
> >seems to be about Sun's old bugs.
> 
> This Sun (probably) has ~100000x more accurate hrtimers than it's said,
> and it's a bug. My panda board (with 32K timer enabled) has ~30000x
> less accurate hrtimers than it's said, and it's not a bug. Great.

If I understand you correctly, what you are looking for is a way to
get a promise from the OS regarding a real time deadlines, right?
But that is a different question than the timer unit resolution:

Q: What is the finest timer duration that I may request?
A: One nanosecond (answer by getres).

Q: What kind of real time deadline will my system provide?
A: Nobody knows for sure.

Just because the OS claims timer resolution X does mean that your
application can assume, "okay, I'll just set my periodic task at
duration X and the OS will take care of the rest." The only thing the
user can count on is that the timer expiration will not come _before_
the deadline. The nanosleep man page puts its like this:

   If the interval specified in req is not an exact multiple of the
   granularity underlying clock (see time(7)), then the interval will
   be rounded up to the next multiple.  Furthermore, after the sleep
   completes, there may still be a delay before the CPU becomes free
   to once again execute the calling thread.

I agree that getres does not provide very useful information. Under
Linux, it merely indicates the present of high resolution timer
support.

The practical solution to what you are asking for is overall system
testing tuning, and this is unfortunately manual labor.

Richard