Отвлечёмся от амерофинских русофобских срачей и обратим внимание на официальное включениеPREEMPT_RT в основную ветку. Честно говоря, мне не доводилось использовать этот патч в деле, но я что-то слышал. Кто в теме, подскажите, таки QNX теперь не нужон?
Здравствуйте, cppguard, Вы писали:
C>QNX теперь не нужон?
Если в Linux будет гарантия, что время выполнения системных функций, без которых определенному софту, не обойтись, ни при каких условиях (кроме отказа основного железа) не превысит определенного максимума, то можно будет рассмотреть.
ВР>>а для всяких домашних спистоперделок, юзайте C>Для этого и real-time не нужен
я делал софтовый ИК приемник на линуксе, на GPIO приходили единицы и нули с декодера, вопрос в том чтобы правильно замерить их длительность, без chrt срабатывало в половине случаев, с chrt — в 90%, что уже было приемлемо
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Великий Реверс, Вы писали:
ВР>а для всяких домашних спистоперделок, юзайте
Для домашних свистоперделок обычно и ESP хватает с честным реалтаймом.
Здравствуйте, ononim, Вы писали:
O>я делал софтовый ИК приемник на линуксе, на GPIO приходили единицы и нули с декодера, вопрос в том чтобы правильно замерить их длительность, без chrt срабатывало в половине случаев, с chrt — в 90%, что уже было приемлемо
Не работал с real-time данными. Для таких задач разве не нужен какой-то прецизионный таймер/осциллятор?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если в Linux будет гарантия, что время выполнения системных функций, без которых определенному софту, не обойтись, ни при каких условиях (кроме отказа основного железа) не превысит определенного максимума, то можно будет рассмотреть.
Здравствуйте, cppguard, Вы писали:
C>Не работал с real-time данными. Для таких задач разве не нужен какой-то прецизионный таймер/осциллятор?
Нет. Нужна гарантия, что твои команды будут выполняться не дольше некоторого конкретного времени.
Здравствуйте, alpha21264, Вы писали:
A>А промах в TLB?
Нет разницы, что и где. Есть гарантия верхней границы — можно говорить о hard real-time, нет гарантии — только о soft real-time, который уже и так есть.
Здравствуйте, Vzhyk2, Вы писали:
V>Здравствуйте, cppguard, Вы писали:
C>>Не работал с real-time данными. Для таких задач разве не нужен какой-то прецизионный таймер/осциллятор? V>Нет. Нужна гарантия, что твои команды будут выполняться не дольше некоторого конкретного времени.
Вторая часть твоего ответа вовсе не означает "нет". Самый простой реалтайм — это цикл с одинаковыми действиями (чтение входов, вычисление итеративного алгоритма (например, тот же оценочный фильтр состояния — state estimation) динамической системы, например, ракеты, и в конце итерации запись управляющего сигнала на вход актуаторам.
Соответственно, каждая итерация управления триггерится по таймеру, и если таймер будет гулять туда-сюда, это скажется на ошибке прогнозирования, и вообще может завести систему не туда. Конечно, при этом и у чтения входов, и у записи выходов есть свой джиттер, но на уровне вычислительной системы все команды должны иметь максимальное время выполнения. Но это опять таки, не спасёт от хренового таймера.
Здравствуйте, Евгений Музыченко, Вы писали:
A>>А промах в TLB?
ЕМ>Нет разницы, что и где. Есть гарантия верхней границы — можно говорить о hard real-time, нет гарантии — только о soft real-time, который уже и так есть.
Я знаю. Просто промах TLB — это не "системная функция" и вообще не функция. Программист про неё вообще не знает.
Это действие, которое происходит по инициативе процессора, и которое может произойти на любой команде доступа в память.
И по идее Линукс должен сказать — мы гарантируем доставку данных с... механического винчестера.
Вот написал и сам вздрогнул. Как это можно гарантировать?! Он же механический!
O>>я делал софтовый ИК приемник на линуксе, на GPIO приходили единицы и нули с декодера, вопрос в том чтобы правильно замерить их длительность, без chrt срабатывало в половине случаев, с chrt — в 90%, что уже было приемлемо C>Не работал с real-time данными. Для таких задач разве не нужен какой-то прецизионный таймер/осциллятор?
Там импульсы длительностью в одну две миллисекунды — собственно это значения которые надо было различать. Различал из юзерспейсовой апликухи через GPIO. Время чем мерял — уже не помню. Но работало для той задачи приемлемо. Задача — рапсознание сигналов с пульта чтоб музчкой управлять. Для атомного реактора конечно так делать не надо.
Как много веселых ребят, и все делают велосипед...
A>Я знаю. Просто промах TLB — это не "системная функция" и вообще не функция. Программист про неё вообще не знает. A>Это действие, которое происходит по инициативе процессора, и которое может произойти на любой команде доступа в память. A>И по идее Линукс должен сказать — мы гарантируем доставку данных с... механического винчестера.
Промахи тоже можно посчитать где и сколько их может произойти максимально в данном пути исполнения. Ну а если система такая толстая что их посчитать не представляется возможным — это проблемы исключительно такой системы.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если в Linux будет гарантия, что время выполнения системных функций, без которых определенному софту, не обойтись, ни при каких условиях (кроме отказа основного железа) не превысит определенного максимума, то можно будет рассмотреть.
Как я понимаю, на современных x86-х системах этого в принципе нельзя гарантировать из-за Intel Me/AMT AMD PSP и что там еще напридумывали.
Здравствуйте, alpha21264, Вы писали:
A>промах TLB — это не "системная функция"
Это системная функция в чистом виде, просто используемая неявно. Если система не обрабатывает такие ситуации, то либо софт их обрабатывает самостоятельно, либо они приводят к аварийной ситуации (отказу).
A>Программист про неё вообще не знает.
Программисту, не знающему о таких вещах, не следует работать в области real-time.
A>И по идее Линукс должен сказать — мы гарантируем доставку данных с... механического винчестера. A>Вот написал и сам вздрогнул. Как это можно гарантировать?! Он же механический!
Именно. Поэтому в критичном коде применяется фиксация кода/данных в памяти, что исключает запросы на подкачку.
Здравствуйте, Michael7, Вы писали:
M>на современных x86-х системах этого в принципе нельзя гарантировать из-за Intel Me/AMT AMD PSP
Тут надо смотреть, в каких условиях все эти средства могут получать управление. Насколько я знаю, сами по себе, без внешнего запроса, они не активизируются. Если так, то ситуацию, в которой они активизируются спонтанно, можно приравнять к критическому отказу аппаратуры, и всего делов. Лишь бы вероятность активизации встроенного средства не слишком превышала вероятность аппаратного отказа по другим причинам.
Здравствуйте, student__, Вы писали:
__>Соответственно, каждая итерация управления триггерится по таймеру, и если таймер будет гулять туда-сюда, это скажется на ошибке прогнозирования, и вообще может завести систему не туда. Конечно, при этом и у чтения входов, и у записи выходов есть свой джиттер, но на уровне вычислительной системы все команды должны иметь максимальное время выполнения. Но это опять таки, не спасёт от хренового таймера.
А вот это уже задача писать реалтаймовую программу корректно на оси (или без нее) которая тебе гарантирует реалтайм.
Если ось тебе такого не гарантирует, то реалтаймовую прогу ты не напишешь.
Здравствуйте, cppguard, Вы писали:
ВР>>а для всяких домашних спистоперделок, юзайте C>Для этого и real-time не нужен
Для всяких музыкальных редакторов, рекордеров, реалтайм-эффектов и т.д. нужен.
На Линухах всё это не живёт, только на виндах и макоси, из-за наличия реалтаймовых приоритетов потоков.
