Прецизионный таймер в Linux, Нужен таймер менее 10mS Опции

[vzn]

Добрый день.
Подскажите как в Linux можно реализовать посылку сигнала SIGALRM в мое приложение с периодом
порядка 100us(микросекунд).

Настройка обычного таймера в Linux согласно man предполагает минимальный период 10 ms.

Вариант с перекомпиляцией ядра для уменьшения времени отклика не подходит.

Какие еще могут быть способы реализовать таймер?

[Harbour]

Да ну ? Есть такая фигня как гарантированный deadline - запутят на той non-rt оси какой-нить низкоприоритетный процесс, который заюзает ram+swap на 100% - и скажем bye-bye этому "realtim'у", пусть даже секундному и никакие posix расширения не спасут.

[Olej]

Да ну ?

http://qnxclub.net/files/articles/RemarksO...TheMargins.html

[vzn]

Спасибо всем за дельные советы.

Пока я остановился на следующем решении основаном на использовании rdtscl()(#include <asm/msr.h>). Оно конечно не оптимальное, но для моих условий пока подходит.

Привязал исполнение моей real-time задачи не к SIGALRM, а к счетчику тактов процессора.
То есть задача должна выполнятся например каждые 100us.
Для этого оцениваем, сколько тактов нашего процессора в этих 100us. Часть тактов выполняем задачу (задача выполняется менее чем за 100us) часть тактов ждем ничего не делая, пока не на тикает оставшееся количество тактов. Все в обычном цикле.

При исполнении только моего приложения и ничего кроме него, решение дает приемлемый результат по точности. Если исполняется еще что-либо, то происходят сбои.

[Olej]

Пока я остановился на следующем решении основаном на использовании rdtscl()(#include <asm/msr.h>). Оно конечно не оптимальное, но для моих условий пока подходит.

Привязал исполнение моей real-time задачи не к SIGALRM, а к счетчику тактов процессора.
То есть задача должна выполнятся например каждые 100us.
Для этого оцениваем, сколько тактов нашего процессора в этих 100us. Часть тактов выполняем задачу (задача выполняется менее чем за 100us) часть тактов ждем ничего не делая, пока не на тикает оставшееся количество тактов. Все в обычном цикле.

При исполнении только моего приложения и ничего кроме него, решение дает приемлемый результат по точности. Если исполняется еще что-либо, то происходят сбои.

Вы то же самое могли бы сделать и по схеме с сигналами или любым другим асинхронным уведомлением (это и проще по коду, и точнее будет - затраты на вычисления уйдут из цикла активного ожидания):
- запускаете пустой цикл с rdtscl() (это на самом деле 1 команда RDTSC на x86)...
- и как только счётчик перевалит через заранее фиксированное значение - kill() самому себе ... SIGUSR1 или SIGRTMIN ...
- а в обработчике сигнала - запуск своей кратковременной задачи.
Или, если так больше нравится - всё то же можно выполнить в 2-х потоках.

Есть такая фигня как гарантированный deadline - запутят на той non-rt оси какой-нить низкоприоритетный процесс, который заюзает ram+swap на 100% - и скажем bye-bye этому "realtim'у", пусть даже секундному и никакие posix расширения не спасут.

В общем ... оно и правильно. Но свопирование во всех (нормальных : FreeBSD, Linux) OS можно запретить для задачи - это обязательное условие для таких задач... так же как в QNX - оно всегда запрещено (или всегда отсутствует, если кому так больше нравитс ).
Но вопрос, заданный в этой теме - он не относится к какой-либо OS, он будет возникать везде... даже в уже "некуда далее RT" QNX - можно уменьшить шаг системного времени до 10мксек (а минимальный интервал, как я уже говорил, вы принципиально не сделаете меньше 20мксек) - но всегда найдётся кто-то, кому понадобится временной шаг в ... 7 мксек . И опять та же история: нельзя разрешить 2 события, временной интервал которых меньше шага системного времени ... независимо RT это OS или не RT.