On Thu, Feb 03, 2005 at 01:58:27PM +0300, Epiphanov Sergei wrote: > В сообщении от 2 Февраль 2005 19:10 Anton Farygin написал: > > Что интересно - разброс на 2.4 явно больше, но на 2.6 явно выше > > результат, но при этом точность намного выше. > > > > Так может быть что-то не так в методике тестирования ? > > > > При чем независимо от интервала превышение примерно 1ms. > > Я добавил в программу включение SCHED_FIFO с максимальным приоритетом, > но ничего не изменилось... > сборка: > g++ -O3 -o speed speed.cpp > > Запускаю под root, вижу следующее: > $ps axl | grep speed > F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND > 4 0 2560 2258 -100 - 2096 816 pause S<+ pts/9 0:00 ./speed > > Программа выдаёт следующее: > > Cur=1107427818.387305s, Prev=1107427818.356308s, delta= 30.997ms > Cur=1107427818.418299s, Prev=1107427818.387305s, delta= 30.994ms > Cur=1107427818.449293s, Prev=1107427818.418299s, delta= 30.994ms > Cur=1107427818.480286s, Prev=1107427818.449293s, delta= 30.993ms > Cur=1107427818.511280s, Prev=1107427818.480286s, delta= 30.994ms > Cur=1107427818.542274s, Prev=1107427818.511280s, delta= 30.994ms > Cur=1107427818.573269s, Prev=1107427818.542274s, delta= 30.995ms > Cur=1107427818.604261s, Prev=1107427818.573269s, delta= 30.992ms > Cur=1107427818.635257s, Prev=1107427818.604261s, delta= 30.996ms > > То есть либо что-то не так пишу, либо не понимаю ядро, либо ядро 2.6 использует > что-то иное для обеспечения близкого к realtime времени исполнения. На самом деле проблема в данном случае в различных алгоритмах пересчёта временных интервалов во внутренние единицы ядра в 2.4.x и 2.6.x. В 2.4.x в kernel/itimer.c были довольно простые функции tvtojiffies() и jiffiestotv(): static unsigned long tvtojiffies(struct timeval *value) { unsigned long sec = (unsigned) value->tv_sec; unsigned long usec = (unsigned) value->tv_usec; if (sec > (ULONG_MAX / HZ)) return ULONG_MAX; usec += 1000000 / HZ - 1; usec /= 1000000 / HZ; return HZ*sec+usec; } static void jiffiestotv(unsigned long jiffies, struct timeval *value) { value->tv_usec = (jiffies % HZ) * (1000000 / HZ); value->tv_sec = jiffies / HZ; } Для архитектуры i386 в ядрах 2.4.x было установлено HZ == 100 (период системного таймера полагался равным 10 мс). В функции tvtojiffies() округление всегда происходит вверх, чтобы интервал задержки всегда был не меньше запрошенного. В 2.6.x ситуация заметно изменилась и усложнилась. Прежде всего, частота системного таймера для i386 была увеличена в 10 раз - теперь HZ == 1000 (однако все внешние интерфейсы ядра, где раньше использовались jiffies, всё равно используют USER_HZ == 100 с соответствующим пересчётом во внутреннее представление). Однако теперь ядро учитывает тот факт, что реальная частота не совсем точно равна 1000 Гц. В файле include/asm-i386/timex.h определена константа CLOCK_TICK_RATE - входная частота таймера; для PC это 1193182 Гц. Последующий расчёт можно наблюдать в include/linux/jiffies.h. Делитель для таймера получается равным 1193, в результате реальная частота системного таймера равна приблизительно 1000.1526 Гц. Период системного таймера в наносекундах (TICK_NSEC) получается равным 999848 (а не 1000000, как можно было бы предположить, увидев HZ = 1000). В результате всего этого получается, что заданное в tv_usec значение 30000 округляется не до 30, а до 31 тика системного таймера - при таком значении TICK_NSEC это 30.995288 мс (а 30 тиков - 29.995440 мс). Меняя значение в tv_usec, можно обнаружить, что при уменьшении его до 29995 измеренная задержка на ядре 2.6.x действительно скачком уменьшается приблизительно на 1 мс. Чтобы определить, какой интервал для таймера в действительности был установлен ядром, можно после setitimer() вызвать getitimer() - настройки таймера хранятся во внутренних единицах ядра, поэтому getitimer() вернёт не то значение, которое было передано в setitimer(), а уже округлённое, которое и будет в действительности использоваться ядром.