таймеры в линукс

Для точности порядка миллисекунд со строгим срабатыванием нужна система реального времени. Может для тебя "позже" - это не так страшно? Для ядра с kernel.org опоздание в пределах 10мс будет нормой, с пиками до 200мс и более, всё зависит от степени и характера загрузки системы. Самый простой способ улучшить ситуацию - поставить ядро -rt, эту ветку собровождает Ingo Molnar, но оно не даст жёсткого реального времени. Более радикальный путь - переход на RTAI - появятся жёсткие гарантии срабатывания таймера с отклонениями в пределах малого (определяемого экспериментально для каждой машины) интервала.

Да, мне тоже интересно. Вообще по экспериментам в 2.4 вообще всё было плохо, а в 2.6 его собственные таймеры (add_timer/mod_timer) даже ничего, миллисекунды по крайней мере неплохо держат. То есть если перенести в ядро критическую часть, может быть и удастся сделать. Хотя, могу ошибаться.

Раньше это было патчем -hrt, совсем недавно их включили в ядро (2.6.16 IIRC). HRT-таймеры имеют разрешение порядка микросекунд, доступны в userspace через стандартные POSIX-интерфейсы timer_{create,delete}.

http://www.tglx.de/projects/hrtimers/archive/ANNOUNCE

> поставить ядро -rt, эту ветку собровождает Ingo Molnar, но оно не даст жёсткого реального времени.

Можно подробнее? Что не так, в каких условиях?

Насколько я понимаю, high-resolution timer'ы дают только более точное указание момента срабатывания, и смысл только в новом общем API, потому что для x86, например, и так можно измерять интервалы с точностью до такта процессора с помощью команды rdtsc.

Что касается режима ядра, то в нём задержки должны быть незначительно меньше, чем для realtime userspace-задачи (имею в виду "realtime-планировщик", который есть и в обычных ядрах), отключающией прерывания на важных участках, поэтому если на микросекунды счёт не идёт, то переносить код в ядро не стоит.

Мое понимание работы ОС явно отличается от понимания молодого поколения :/

> high-resolution timer'ы дают только более точное указание момента срабатывания, и смысл только в новом общем API, потому что для x86, например, и так можно измерять интервалы с точностью до такта процессора с помощью команды rdtsc.

Вот именно - _срабатывания_. Как ты отмеришь момент срабатывания с помощью rdtsc? Занятое ожидание на максимальном приоритете?

> Что касается режима ядра, то в нём задержки должны быть незначительно меньше, чем для realtime userspace-задачи (имею в виду "realtime-планировщик"

Всё так, но...

> отключающией прерывания на важных участках

Причем здесь это? Если кто-то отключил прерывания (IIRC, планировщик этого не делает), то нахождение в ядре не спасет.

> поэтому если на микросекунды счёт не идёт, то переносить код в ядро не стоит.

Смотря сколько микросекунд, смотря какое железо... Чем меньше кода в ядре - тем лучше.

> Вот именно - _срабатывания_. Как ты отмеришь момент срабатывания с помощью rdtsc? Занятое ожидание на максимальном приоритете?

"срабатывание" для программиста - это момент входа в нужную процедуру обработки. Дальше, думаю, понятно, что делать с rdtsc.

>> отключающией прерывания на важных участках

> Причем здесь это? Если кто-то отключил прерывания (IIRC, планировщик этого не делает), то нахождение в ядре не спасет.

Я написал это, чтобы подчеркнуть, что в userspace можно организовать критические секции не хуже, чем в режиме ядра.

>> Вот именно - _срабатывания_. Как ты отмеришь момент срабатывания с помощью rdtsc? Занятое ожидание на максимальном приоритете?

>"срабатывание" для программиста - это момент входа в нужную процедуру обработки. Дальше, думаю, понятно, что делать с rdtsc.

Как определить момент, когда вызвать эту процедуру? Так, как я написал? Впрочем, если не хочешь отвечать...

> в userspace можно организовать критические секции не хуже, чем в режиме ядра.

Вроде о критический секциях речь не шла... Кроме того, у нас, наверное, разное определение "критической секции" 8)