Отвлечёмся от амерофинских русофобских срачей и обратим внимание на официальное включение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 не нужен
Для всяких музыкальных редакторов, рекордеров, реалтайм-эффектов и т.д. нужен.
На Линухах всё это не живёт, только на виндах и макоси, из-за наличия реалтаймовых приоритетов потоков.
O>>Промахи тоже можно посчитать где и сколько их может произойти максимально в данном пути исполнения. ЕМ>А смысл их считать, если невозможно гарантировать время обработки промаха?
Почему невозможно? Я не про случай когда страницу надо прочитать из свопа (своп понятное дело надо отключить). Ведь TLB miss это совсем не обязательно Page Fault.
Из википедии:
These are typical performance levels of a TLB:[17]
Size: 12 bits – 4,096 entries
Hit time: 0.5 – 1 clock cycle
Miss penalty: 10 – 100 clock cycles
Берешь объем памяти, необходимый для исполнения заданной функции (код и данные), делишь на 4096 и умножаешь на 100 — получаешь худший случай потерь на TLB misses.
Как много веселых ребят, и все делают велосипед...
C> Кто в теме, подскажите, таки QNX теперь не нужон?
Ближайшие пару лет еще нужен. Дальше — будем посмотреть. Это как с io_uring, вроде б epoll уже не нужен, но это только если с шашкой наголо. Как несложно заметить, io_uring уже скоро в школу пойдет, но глобальной адопции пока не случилось.
Такими величинами, слава богу, всегда можно пренебречь, равно как и промахами кэша. То, что не прощает случайных потерь в сотни тактов, на железе общего назначения не делают.
Здравствуйте, SkyDance, Вы писали:
C>>QNX теперь не нужон?
SD>Ближайшие пару лет еще нужен. Дальше — будем посмотреть.
И что будем смотреть? Вероятность того, что ОС общего назначения, пусть даже и с патчами/ограничениями, сможет использоваться там, для чего сделана специализированная ОС, стремится к нулю. Просто потому, что даже если и получится однажды допилить линукс до RT OS, никто не возьмет на себя ответственность постоянно следить за тем, чтобы ничего не поломали впоследствии.
Любая RT OS — это же сплошь ограничения. Этого нельзя, того нельзя, это надо делать только так, и никак иначе, и т.п. Все это можно поддерживать в адекватном виде только в жестко ограниченной и регламентированной команде.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Любая RT OS — это же сплошь ограничения. Этого нельзя, того нельзя, это надо делать только так, и никак иначе, и т.п. Все это можно поддерживать в адекватном виде только в жестко ограниченной и регламентированной команде.
Если придерживаться POSIX, то между Linux и QNX есть какая-то разница?
ЕМ>И что будем смотреть? Вероятность того, что ОС общего назначения, пусть даже и с патчами/ограничениями, сможет использоваться там, для чего сделана специализированная ОС, стремится к нулю. Просто потому, что даже если и получится однажды допилить линукс до RT OS, никто не возьмет на себя ответственность постоянно следить за тем, чтобы ничего не поломали впоследствии.
Так ведь и с QNX та же беда. Проще поддерживать одну систему, чем две, так что если будет некий вариант Linux, который поддерживается, возможно, что на QNX забьют и оно умрет.
Здравствуйте, Vzhyk2, Вы писали: V>А вот это уже задача писать реалтаймовую программу корректно на оси (или без нее) которая тебе гарантирует реалтайм. V>Если ось тебе такого не гарантирует, то реалтаймовую прогу ты не напишешь.
Вот ты пишешь "на оси (или без нее)". Т.е. можно убрать это и заменить на "без оси", и прочитай написанное.
Имеет оно смысл по-русски?
Здравствуйте, SkyDance, Вы писали:
SD>Так ведь и с QNX та же беда.
Та же, но не та же. QNX гораздо проще Linux, в смысле, там в ядерные компоненты не пихают кучи фич, а только самый минимум.
>Проще поддерживать одну систему, чем две, так что если будет некий вариант Linux, который поддерживается, возможно, что на QNX забьют и оно умрет.
На QNX и забивают, и там, где его можно Линуксом заменить это уже произошло, и уже давно и без всяких RT версий.
Но QNX до сих пор жива.
Конечно, в современном мире всё может быть, т.к. инженерией начиннают заниматься обезъяны (падающий боенг).
Здравствуйте, student__, Вы писали:
__>Но QNX до сих пор жива.
Кстати, если вы в курсе, то что с ним сейчас?
Я смутно помню (но могу и ошибаться), что он переходил в собственность BlackBerry и из него вроде как попытались сделать из неё какую-то мобильную ОС.
Но что сейчас я не в курсе. Сайт https://blackberry.qnx.com вроде вполне живой, с новостями, но читать и вникать просто нет времени.
Если можете — расскажите в 2-х словах — что там сейчас.
Здравствуйте, cppguard, Вы писали:
C>Если придерживаться POSIX, то между Linux и QNX есть какая-то разница?
Если делать софт строго в рамках POSIX, без использования особенностей системы, то вряд ли можно получить от QNX что-то большее, чем более предсказуемое распределение процессорного времени, чем в линуксе.
Здравствуйте, SkyDance, Вы писали:
SD>Проще поддерживать одну систему, чем две, так что если будет некий вариант Linux, который поддерживается, возможно, что на QNX забьют и оно умрет.
Квалификация, потребная для поддержки ядра Linux, способного на адекватный real-time, сильно выше квалификации, потребной для поддержки ядра в состоянии "работает, не падает, сильно не тормозит". В этой ситуации QNX умрет не раньше, чем умрут задачи, решаемые с ее помощью на UNIX-like системах.
Здравствуйте, syrompe, Вы писали:
S>Системы управления для самопальных CNC/3D принтеров теперь меньше танцев требовать будут? S>Или тут не про это?
Там ардуинки и подобное рулят и никаких линухов с виндами и в помине нет и танцев с бубнами в плане реалтайма нет. Точнее есть на уровне раздачи задач для печати стаду принтеров и отображения процесса печати на уебстраничке.
Здравствуйте, Михаил Романов, Вы писали:
МР>Здравствуйте, student__, Вы писали:
МР>Если можете — расскажите в 2-х словах — что там сейчас.
Я тоже не в курсе. Википедия говорит, что выходят новые версии (там ФС какую-то добавили, удовлетворяющую автопромному safety стандарту). Знаю, что поставщики типа nvidia до сих пор поддерживают QNX.
Когда я пришёл в контору, в которой до сих пор работаю, от QNX отказались в пользу сборки на базе проекта yocto Linux. Впрочем, реалтайм в наших проектах (инфотейнмент в авто, не особо ответственная его часть) нужен так же, как он нужен на ноутбуках, потому что тачки превращаются просто в компы на колёсах, с функцией вождения (как мобильные телефоны превратились в карманные компы с функцией звонков). Низкоуровневые контроллеры все либо со своими прошивками, либо специализированные ОС, но всё равно отвечающие отраслевым стандартам. А вот на тачскрине возюкать и показывать картинку — это можно на чём угодно (кроме, может быть, таких вещей, как камера заднего вида, но это исключение). Просто инфотейнмент очень хайповая отрасль, вбирает в себя кучу фич, на которые клюют потребители, и Линукс как система "для всего" не особенно ответственного, но привлекающая к себе внимание разрабов со всей вселенной, прекрасно подходит для такого хайпа.
Здравствуйте, Евгений Музыченко, Вы писали:
SD>>Проще поддерживать одну систему, чем две, так что если будет некий вариант Linux, который поддерживается, возможно, что на QNX забьют и оно умрет.
ЕМ>Квалификация, потребная для поддержки ядра Linux, способного на адекватный real-time, сильно выше квалификации, потребной для поддержки ядра в состоянии "работает, не падает, сильно не тормозит". В этой ситуации QNX умрет не раньше, чем умрут задачи, решаемые с ее помощью на UNIX-like системах.
__>А вот на тачскрине возюкать и показывать картинку — это можно на чём угодно (кроме, может быть, таких вещей, как камера заднего вида, но это исключение).
Ну сейчас стало модно всю приборку экранами заменять.
В том числе спидометр/тахометр и все лампочки с check engine.
Я так полагаю, что ваш продукт на Линуксе сюда уже не зайдет ибо если спидометр зависнет на 20 км/час, то ай...
Здравствуйте, syrompe, Вы писали:
S>Ну сейчас стало модно всю приборку экранами заменять. S>В том числе спидометр/тахометр и все лампочки с check engine. S>Я так полагаю, что ваш продукт на Линуксе сюда уже не зайдет ибо если спидометр зависнет на 20 км/час, то ай...
Вот это очень интересный момент. У меня Chevrolet Volt 2015, интерфейс что на приборке, что на мультимедиа вырвиглазный. Захотелось мне проникнуть внутрь и попробовать накатить линукс. Так вот в ходе исследований выяснилось, что на приборке, где real-time вполне нужен, уже ипользуется Linux, а в мультимедиа, где нафиг реальное время не упало, работает QNX Приборка пока сбоев не давала, а вот мультимедиа зависат/тупит регулярно.
Здравствуйте, syrompe, Вы писали: S>Ну сейчас стало модно всю приборку экранами заменять. S>В том числе спидометр/тахометр и все лампочки с check engine. S>Я так полагаю, что ваш продукт на Линуксе сюда уже не зайдет ибо если спидометр зависнет на 20 км/час, то ай...
вы путаете instrument cluster (где приборы) и infotainment (где навигация и прочие аппы), это совершенно разные системы, и рулятся они разными ОС и традиционно на разных ECU, даже если экран выглядит как одно единое целое на всю ширину салона
QNX стала бесплатной для некоммерческого использования.
Обожаю такие моменты, когда сперва все полимеры просраны, а потом начинается пожар в одном месте и срочные реформы. Учитывая, сколько компаний в automotive перешли на линукс, даже полное открытие исходников QNX не спасёт её от скорого забвения.
Приборка пока сбоев не давала, а вот мультимедиа зависат/тупит регулярно.
