Clock_getres и Kernel 2.6

Ответ 1

В соответствии с файлом include/linux/hrtimer.h из исходных текстов ядра clock_getres() всегда будет возвращать 1ns (одна наносекунда) для таймеров с высоким разрешением (если в системе есть такие таймеры). Это значение жестко запрограммировано, и это означает: "Значение таймера будет округлено до него"

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

Для таймеров с низким разрешением (и для часов MONOTONIC и REALTIME, если нет аппаратного обеспечения hrtimer), linux вернет 1/HZ (типичный HZ от 100 до 1000, поэтому значение будет от 1 до 10 мс):

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 }

Значения таймеров с низким разрешением могут быть округлены до такой низкой точности (фактически они похожи на jiffles, ядро ​​linux "тикает" ).

PS: Этот пост http://forum.kernelnewbies.org/read.php?6,377,423, как я понимаю, сравнивает 2.4 linux без встроенных hrtimers с ядром 2.6 с доступными hrtimers. Поэтому все значения верны.

Ответ 2

Попробуйте получить его от procfs.

cat/proc/timer_list

Ответ 3

Как вы думаете, что это неправильно?

Например, на современных процессорах x86 ядро ​​использует TSC для обеспечения часов с высоким разрешением - любой процессор, работающий на частоте выше 1 ГГц, имеет TSC, который гаснет быстрее, чем галочка на наносекунду, поэтому наносекундное разрешение довольно распространено.