[sisyphus] timers on 2.6.x vs 2.4.x (was: Re: USB on 2.4.x)

[Sergey Vlasov <vsu@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 4113 bytes --]

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(), а уже округлённое,
которое и будет в действительности использоваться ядром.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]