clock_getres and Kernel 2.6

i'm using ubuntu 11.04 now and using v2lin to port my program from vxWorks tolinux. I have problem with clock_getres().

with this code:

struct timespec res;
clock_getres(CLOCK_REALTIME, &res);

i have res.tv_nsec = 1 , which is somehow not correct.

Like this guy showed: http开发者_运维技巧://forum.kernelnewbies.org/read.php?6,377,423 , there is difference between kernel 2.4 and 2.6.

So what should be the correct value for the clock resolution in kernel 2.6

Thanks

According to "include/linux/hrtimer.h" file from kernel sources, clock_getres() will always return 1ns (one nanosecond) for high-resolution timers (if there are such timers in the system). This value is hardcoded and it means: "Timer's value will be rounded to it"

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/include/linux/hrtimer.h

269 /*
270  * The resolution of the clocks. The resolution value is returned in
271  * the clock_getres() system call to give application programmers an
272  * idea of the (in)accuracy of timers. Timer values are rounded up to
273  * this resolution values.
274  */
275 # define HIGH_RES_NSEC          1
276 # define KTIME_HIGH_RES         (ktime_t) { .tv64 = HIGH_RES_NSEC }
277 # define MONOTONIC_RES_NSEC     HIGH_RES_NSEC
278 # define KTIME_MONOTONIC_RES    KTIME_HIGH_RES

For low-resolution timers (and for MONOTONIC and REALTIME clocks if there is no hrtimer hardware), linux will return 1/HZ (typical HZ is from 100 to 1000; so value will be from 1 to 10 ms):

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/include/linux/ktime.h#L321

321 #define LOW_RES_NSEC            TICK_NSEC
322 #define KTIME_LOW_RES           (ktime_t){ .tv64 = LOW_RES_NSEC }

Values from low-resolution timers may be rounded to such low precision (effectively they are like jiffles, the linux kernel "ticks").

PS: This post http://forum.kernelnewbies.org/read.php?6,377,423 as I can understand, compares 2.4 linux without hrtimers enabled (implemented) with 2.6 kernel with hrtimers available. So all values are correct.

Try to get it from procfs.

cat /proc/timer_list

Why do you think it is incorrect?

For example, on modern x86 CPUs the kernel uses the TSC to provide high resolution clocks - any CPU running at higher than 1Ghz has a TSC that ticks over faster than a tick per nanosecond, so nanosecond resolution is quite common.