[sisyphus] timers on 2.6.x vs 2.4.x (was: Re: USB on 2.4.x)
Sergey Vlasov
=?iso-8859-1?q?vsu_=CE=C1_altlinux=2Eru?=
Чт Фев 3 15:33:06 MSK 2005
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(), а уже округлённое,
которое и будет в действительности использоваться ядром.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип : application/pgp-signature
Размер : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url : <http://lists.altlinux.org/pipermail/sisyphus/attachments/20050203/e04fe307/attachment-0003.bin>
Подробная информация о списке рассылки Sisyphus