1мс это real time или еще нет?

Вопросы программного кода и архитектуры Linux

Модератор: Olej

strap89
Писатель
Сообщения: 24
Зарегистрирован: 23 июл 2020, 11:16
Контактная информация:

1мс это real time или еще нет?

Непрочитанное сообщение strap89 » 22 фев 2021, 08:50

Здравствуйте!
Интересует ваше мнение: если в работающую систему приходят прерывания с частотой 1кГц (т.е. период 1мс), требующие обработки и провал обработки недопустим (задержка выполнения тоже 1мс), такая система уже должна быть real-time или нет?
Я до последнего времени был уверен, что эта система требует real-time, причем жесткого real-time и реализация такой системы в обычной ос типа linux неминуемо приведет к проблемам. Но в отделе появляются новые, молодые, горячие головы, которые никогда не работали с real-time, но уверены на 100%, что linux справится. А не справляется? Купим процессор по-мощнее и все будет ок.
И я как-то уже потерял уверенность в необходимости real-time ос для реализации такой задачи. Очень интересует ваше мнение. Причем более всего об использовании linux в такой задаче (Что мне делать в настоящей rtos я и так представляю). Заранее спасибо.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: 1мс это real time или еще нет?

Непрочитанное сообщение Olej » 22 фев 2021, 13:02

strap89 писал(а):
22 фев 2021, 08:50
Интересует ваше мнение: если в работающую систему приходят прерывания с частотой 1кГц (т.е. период 1мс), требующие обработки и провал обработки недопустим (задержка выполнения тоже 1мс), такая система уже должна быть real-time или нет?
Я до последнего времени был уверен, что эта система требует real-time, причем жесткого real-time и реализация такой системы в обычной ос типа linux неминуемо приведет к проблемам. Но в отделе появляются новые, молодые, горячие головы, которые никогда не работали с real-time, но уверены на 100%, что linux справится. А не справляется? Купим процессор по-мощнее и все будет ок.
Вообще то, real-time никак не связан со скоростью, с абсолютными значениями времени реакции на какие-то события...
1мс - это много или мало? а 10 мс?
Это не имеет отношения к real-time характеристике, это понятие скорости.
Но вот вопрос распределения времени задержки реакции...
- как много % повторяющихся событий будут выходить за границу предельных 1 мс?
- насколько детерминировано время реакции?, сконцентрировано вокруг 0.5 мс, скажем ... а не размыто в диапазоне от 0.1 до 2.5?
- насколько критичен выход за предел 1 мс? насколько тяжёлые последствия это повлечёт?

Вообще то, в рамках Linux нельзя обеспечить hard realtime, нельзя в принципе!
А любые разговоры о soft realtime - это разговоры об "осетрине второй свежести". :-o :lol:

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: 1мс это real time или еще нет?

Непрочитанное сообщение Olej » 22 фев 2021, 13:28

strap89 писал(а):
22 фев 2021, 08:50
Я до последнего времени был уверен, что эта система требует real-time, причем жесткого real-time и реализация такой системы в обычной ос типа linux неминуемо приведет к проблемам.
Посмотрите тему Raspberry Pi: hard realtime Linux/Xenomai ... и вообще поищите всё контекстным поиском про проект Xenomai:
- это надстройка рядом с Linux обеспечивающая hard realtime ...
- но это не патч к Linux - события требующие realtime перехватываются и обрабатываются раньше Linux, а остальные, не требующие, оставляются Linux-у.

Но пересобирать ядро Linux под использование Xenomai - дело хлопотное и требующее затрат много времени ... это я сам делал, и врагу не пожелаю. :lol:
Об этом можете посмотреть здесь: Linux для embedded применений.

P.S. Там везде по темам, попутно с Xenomai, есть ссылки на связанные публикации а). с тем что считать realtime и как оно проявляется, б). какие проблемы с обеспечением realtime и в). таблицы и цифры какие реакции можно получать в системе с realtime и без него.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: 1мс это real time или еще нет?

Непрочитанное сообщение Olej » 22 фев 2021, 13:43

Olej писал(а):
22 фев 2021, 13:02
Вообще то, в рамках Linux нельзя обеспечить hard realtime, нельзя в принципе!
Если категорически нужен hard realtime, то смотрите в сторону операционной системы QNX: QNX Neutrino.

Или вот здесь:
Изображение

Но это дорого...
И, последние 10 лет, я бы сказал: "неоправданно дорого" :lol:

P.S. Вообще, знакомство с QNX сильно просветляет в отношении realtime, когда оно нужно ... а ещё более - когда оно не нужно. :lol:

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: 1мс это real time или еще нет?

Непрочитанное сообщение Olej » 22 фев 2021, 13:51

strap89 писал(а):
22 фев 2021, 08:50
Интересует ваше мнение: если в работающую систему приходят прерывания с частотой 1кГц (т.е. период 1мс), требующие обработки и провал обработки недопустим (задержка выполнения тоже 1мс), такая система уже должна быть real-time или нет?
Вообще то, вопрос не совсем корректный.
Он должен бы звучать так:
- как много из общего числа реакций на событие (прерывание) может/допустимо быть за пределами 1 мс.? сколько допустимо: 1%? 0.1%? 1E-5%?
- как далеко за пределы 1 мс. может "затянуться" реакция: 1,2мс.? 2 мс.? 3 мс.?
- что произойдёт при задержке? насколько это критично?

P.S. Проблема кроется в том, что в многозадачной системе время реакции на событие не может быть абсолютно, на 100% детерминировано, предсказуемо - всегда, в самом любом realtime - будет некоторая статистика, "размазанность" задержки. Вот и вопрос в распределении, кривой этой статистики.

P.S. Однозадачная система MS-DOS была почти детерминированная по времени реакции ... да и то "почти" - потому что там могли быть фоновые TSR-задачи и ещё какие-то подспудные параллельности.

P.P.S. Абсолютно детерминированной по времени реакции может быть только хардверное устройство, реализованное на логических элементах ... или зашито в ПЛМ/ПЛИС/FPGA (Altera, ... теперь уже Intel), что то же самое.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: 1мс это real time или еще нет?

Непрочитанное сообщение Olej » 22 фев 2021, 14:26

strap89 писал(а):
22 фев 2021, 08:50
Но в отделе появляются новые, молодые, горячие головы, которые никогда не работали с real-time, но уверены на 100%, что linux справится. А не справляется? Купим процессор по-мощнее и все будет ок.
Быстрее процессор ускорит реакции.
Но только не пропорционально - быстрее процессор в 3 раза это вовсе не означает что ускорит реакции в 3 раза... всё гораздо медленнее и зависит от многих разных привходящих факторов (например: для нового процессора, скорее всего, понадобится и другая системная плата, окружение чипов, которое будет и вести себя совсем по-другому).
strap89 писал(а):
22 фев 2021, 08:50
(Что мне делать в настоящей rtos я и так представляю)
Проблема то ещё в том, что все RTOS имеют минимальный и убогий инструментарий разработки, и там с ним таким можно дров наломать гораздо больше чем с "нереальным" Linux. :-?

strap89
Писатель
Сообщения: 24
Зарегистрирован: 23 июл 2020, 11:16
Контактная информация:

Re: 1мс это real time или еще нет?

Непрочитанное сообщение strap89 » 22 фев 2021, 16:40

Спасибо за развернутый ответ! Правда я малость запутался в ваших соображениях и попутно возникающих вопросах. зависть теперь гложет, я так не умею. Но попробую написать то что смог уловить.
Я наверно действительно должен был сразу более конкретно осветить решаемую проблему, тогда вопросов стало бы сразу меньше.
Итак. Разговор идет об оборудовании с замкнутой обратной связбю. По-простецки о пид-ркгуляторе. Область приененения: испытания авиационных конструкций на прочность. Используется модульная система управления нагружением по 16 каналов.
короткое ТТХ самой модуля системы: 48 каналов АЦП с общей пропускной способностью от 50 кГц (ну от 48 точнее), 16 каналов ЦАП и под 60 каналов дискретного ввода-вывода (реле). ПИД-регулятор классический, без особых затей. Уже по испытанному: большая часть работы ацп/цап перекладывается на систему, данные снимаются по DMA, к системе приходит запрос на прерывание 1 раз в мс. Требование главное: прерывание должно быть обработано до прихода следующего прерывания (через 1 мс). За это время со всех каналов ацп данные должны быть считаны (пока предполагается что средствами dma, без участия процессора), пид-регулятор обсчитан по всем 16 каналам и данные выданы на ЦАП. Ну некоторая обвязка по дискретным каналам ввода-вывода (небольшая). И вСЕ это должно уложиться до прихода следующего прерывания. Т.е. задержка - теже 1 мс (или 0.5? В теории я не силен). Сам код существует (написан), отлажен в работе на однозадачных системах (почти исключительно на на dos, если точнее). Быстродействия системы хватает фактически при любом быстродействии (но все в рамках однозадачной dos или доступной мне rtos). Провал прерывания в имеющейся ситуации приведет к задержке выполнения в 2мс. Для пид- регулятора, конечно, это не фатально, работоспособность система не потеряет, но принцип регулирования требует свести эти события к 0.
Поэтому я собственно и был уверен в необходимости использования rtos системы. Про xenomai я уже прочитал, прочитав о ней у вас на форуме (спасибо вам за их появление). У меня тоже большие сомнения в моих способностях установить это сооружение и заставить его работать.
Но здесь я тоже в заложниках реализации. В общем-то реализация для rtos написана, писать ее еще раз меня как бы вынуждают молодые кадры производства linux, боюсь ваши замечания о неразумности этого подхода не будут для них авторитетны. К тому же у меня словесно не получается внятно описать проблемы реализации обычной системы. Но использование rtos тоже особо не вдохновляет из-за убогости api, как вы тоже правильно написали. Зато работает!!!
Спасибо еще раз за ответы, мне было очень важно услышать ваше мнение.
P.S. Система rtos, имеющаяся у меня в наличии - onTime RTOS (http:/www.on-time.com). Только не надо сразу много сарказма, я сам знаю, что это не гениальное творение rtoso-строения, просто имея лицензию на это ПО мне показалось возможным его использовать. Документация там тоже достаточно аскетичная, но гораздо доступнее чем для linux (с моей, конечно, точки зрения). Реализация соответственно тоже несложная.

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: 1мс это real time или еще нет?

Непрочитанное сообщение Olej » 22 фев 2021, 18:01

strap89 писал(а):
22 фев 2021, 16:40
По-простецки о пид-ркгуляторе. Область приененения: испытания авиационных конструкций на прочность. Используется модульная система управления нагружением по 16 каналов.
короткое ТТХ самой модуля системы: 48 каналов АЦП с общей пропускной способностью от 50 кГц (ну от 48 точнее), 16 каналов ЦАП и под 60 каналов дискретного ввода-вывода (реле). ПИД-регулятор классический, без особых затей. Уже по испытанному: большая часть работы ацп/цап перекладывается на систему, данные снимаются по DMA,
По поводу всех этих дел (ввода-вывода) посмотрите ещё в сторону GPIO - это достаточно новое приобретение Linux (в смысле поддержки), если вы ещё не обратили внимание, то это может вам заметно помочь.
strap89 писал(а):
22 фев 2021, 16:40
к системе приходит запрос на прерывание 1 раз в мс. Требование главное: прерывание должно быть обработано до прихода следующего прерывания (через 1 мс). За это время со всех каналов ацп данные должны быть считаны (пока предполагается что средствами dma, без участия процессора), пид-регулятор обсчитан по всем 16 каналам и данные выданы на ЦАП. Ну некоторая обвязка по дискретным каналам ввода-вывода (небольшая). И вСЕ это должно уложиться до прихода следующего прерывания. Т.е. задержка - теже 1 мс (или 0.5? В теории я не силен). Сам код существует (написан), отлажен в работе на однозадачных системах (почти исключительно на на dos, если точнее). Быстродействия системы хватает фактически при любом быстродействии (но все в рамках однозадачной dos или доступной мне rtos). Провал прерывания в имеющейся ситуации приведет к задержке выполнения в 2мс. Для пид- регулятора, конечно, это не фатально, работоспособность система не потеряет, но принцип регулирования требует свести эти события к 0.
Ну, наверное, свести не совсем к 0, но совсем к малой величине, скажем 10E-5 ...
На случай исключительно редких провалов свыше 1 мс, можете попробовать реализовать обработку последовательности запросов в очередь:
- вновь пришедшее прерывание фиксируется (например, передавая в DMA новый обменный буфер), но обработка его откладывается до завершения текущего (задержавшегося)...
- текущая обработка завершается и данные выдаются на выход (задержавшись, скажем, на 1.2мс)...
- тут же переходим на обработку отложенного прерывания (которое и завершится раньше метки 2 мс отпущенных на 2 прерывания).

Добавить очередь запросов к готовому (почти) коду будет совсем не сложно.
strap89 писал(а):
22 фев 2021, 16:40
Но здесь я тоже в заложниках реализации. В общем-то реализация для rtos написана, писать ее еще раз меня как бы вынуждают молодые кадры производства linux, боюсь ваши замечания о неразумности этого подхода не будут для них авторитетны. К тому же у меня словесно не получается внятно описать проблемы реализации обычной системы. Но использование rtos тоже особо не вдохновляет из-за убогости api, как вы тоже правильно написали. Зато работает!!!
На чём (язык) это, кстати, у вас написано? Классический C ANSI? C++?
Компилятор какой? У GCC много разных опций оптимизации - пересмотрите их...

Я это написал к тому, что имея код (основу кода) ранее написанный, на его основе переписать по-новой будет совсем не так трудоёмко.
А сохранить неизменным код, написанный ... лет 10 назад под какие-то железо-систему - ещё никому не удалось, это будет только напрасно потраченное время. :-?
strap89 писал(а):
22 фев 2021, 16:40
Документация там тоже достаточно аскетичная, но гораздо доступнее чем для linux
А тут вы ошибаетесь!
Для Linux (и по языкам программирования + POSIX API + библиотекам реализующим) документация - исчерпывающая.
Если не хватает - значит плохо искали. :lol:

Аватара пользователя
Olej
Писатель
Сообщения: 21338
Зарегистрирован: 24 сен 2011, 14:22
Откуда: Харьков
Контактная информация:

Re: 1мс это real time или еще нет?

Непрочитанное сообщение Olej » 22 фев 2021, 18:08

strap89 писал(а):
22 фев 2021, 16:40
P.S. Система rtos, имеющаяся у меня в наличии - onTime RTOS (http:/www.on-time.com). Только не надо сразу много сарказма, я сам знаю, что это не гениальное творение rtoso-строения, просто имея лицензию на это ПО мне показалось возможным его использовать.
По всяким "минималистским" ;-) средам исполнения (многие из которых претендуют на RT) посмотрите ещё на этот форум и С.-Петербурга ELECTRONIX.

strap89
Писатель
Сообщения: 24
Зарегистрирован: 23 июл 2020, 11:16
Контактная информация:

Re: 1мс это real time или еще нет?

Непрочитанное сообщение strap89 » 22 фев 2021, 18:58

Что-тоя совсем затупил, написал целый опус, отправил. Опус ушел, и не дошел.
Ладно. ontime rtos работает в окружении microdoft visual studio и на ее же отладчике. Я использую c++, могу asm. Необходимости возни с оптимизацией я пока не вижу. Тут вопрос-то простой: либо я использую linux, делаю оптимизацию, использую хитроумные схемы и в итоге получаю результат: чем мощнее машина тем резвее отклик (т.е. не успеваем?, берем машину по-мощней и будет все ок, пряио де жа вю), но отказов не избежать , либо используем однозадачную ос, получаем свой гарантированный, таймер 1мс без отказов, но живем в убогом окружении на корявом api. На мой взгляд решение было очевидное, но вот уже вы меня опять в сомнения вводите, предлагая различные варианты реализации, отбрасывая начальное утверждение: на linux писать real-time нельзя!

Ответить

Вернуться в «Linux изнутри»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 4 гостя