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