Компания Canonical объявила о завершении тестирования пакетов с ядром Linux для систем, работающих в режиме реального времени. Пакет с real-time ядром признан готовым для повсеместного использования и больше не позиционируется как экспериментальный...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=58651
Как это проверить, что оно "обеспечивающих снижение задержек и позволяющих добиться предсказуемого времени обработки событий"? Где тесты и отчёты, Зин?
Ну поставить планку в 10 мин - так гарантированно практически любое событие обработается за исключением отдельных нюансов..
> обработается за исключением отдельных нюансов..Hard realtime отличается от всего остального именно отсутствием вот таких нюансов. Простите, а вон тот опасный промышленный процесс точно подождет? Или таки е...т?! А дрон точно может подождать? Или впечатается в землю? Автопилот подождет? Или размажет водителя об грузовик?
И вот в этом месте нас очень сильно интересует наличие таких нюансов, которые и отличают RealTime системы от обычных. И мерж патчей RT_LINUX о том чтобы в линуксе такие нюансы извести, хотя бы на уровне ядра.
Да мы создаем будущее. И в этом будущем, как и в Sci-Fi компьютеры управляют всем. И вот тут нас очень сильно волнует как это работает. И можем ли мы доверить свои тушки своим компьютерным системам.
Вы, как большие специалисты, вероятно можете сами проверить, а потом рассказать мужикам работает или нет.
> Вы, как большие специалисты, вероятно можете сами проверить, а потом рассказать
> мужикам работает или нет.Мужикам вон то не надо. А вот мне пригодится так то - я как раз линухом с уклоном в управляющие системы занимаюсь. Так что - сможем, не переживайте. С системщиной у меня выше среднего и на честное слово в таких вещах я никому не верю.
И да, я вполне в состоянии снять тайминги системы "внешним наблюдателем" допустим. Которого не обманешь и который на якорь не встанет. Накатаю мониторинговую фирмвару микроконтроллеру, которая всегда готова, в том числе и отклик системы мерять, да померяю вот именно со стороны, с какими интервалами система со мной взаимодействует и какой worst case был. А пустив эн таких штук под реалистичной нагрузкой я через определенное время получу довольно интересную подборочку статистики отмеряной незавсимыми железками. Но пока это все не в приоритете. И я уж точно не буду убунтовское ядро использовать. Да и убунту. Их видите ли в коммерческие применения - неудобно, на уровне трейдмарков и правил использования репок. Это такой толстый намек что чем договариваться с каноникалом проще соседний дебиан взять ;)
>[оверквотинг удален]
> А дрон точно может подождать? Или впечатается в землю? Автопилот подождет?
> Или размажет водителя об грузовик?
> И вот в этом месте нас очень сильно интересует наличие таких нюансов,
> которые и отличают RealTime системы от обычных. И мерж патчей RT_LINUX
> о том чтобы в линуксе такие нюансы извести, хотя бы на
> уровне ядра.
> Да мы создаем будущее. И в этом будущем, как и в Sci-Fi
> компьютеры управляют всем. И вот тут нас очень сильно волнует как
> это работает. И можем ли мы доверить свои тушки своим компьютерным
> системам.То ли я сарказма не понял ибо слишком толсто, то ли...
А о каких нюансах речь ? -Разрабы гарантируют что система, при прочих равных, запустит энный обратный вызов в течение какого-то срока( например, Азур РТОС ака Тред-Икс, гарантирует, что функция-обработчик прерывания запустится не более чем через 400 тактов от события ).
Тут - ну допустим, будет 400 000 000 000 тактов, в течение которых гарантированно будет произведён обратный вызов. Что не так ? Чем не жОская гарантия ? -Та же Фри-РТОСь и этого не гарантирует
> А о каких нюансах речь ? -Разрабы гарантируют что система, при прочих
> равных, запустит энный обратный вызов в течение какого-то срока( например,Линукс как таковой не делает обратные вызовы, кроме может быть сигналов процессам. Однако в вон тех патчах допустим шедулер может дать реалтайм процессу именно реалтайм гарантии, что на интервале X данный процесс получит никак не менее Y процессорного времени. И это именно гарантии специфичные для именно реального времени уже, а не что-то иное. И уже можно говорить о том что процесс получает контроль и не теряет его больше чем на вот столько вот. Что делает это уже достаточно потребным для некоторых управляющих систем.
Чтобы дать эти гарантии надо довольно много чего. И пересмотр раздачи времени процессам. И смену обработки IRQ чтобы никто не мог застопорить систему надолго хоть там что. И преемптабельность всех частей кернела.
> Азур РТОС ака Тред-Икс, гарантирует, что функция-обработчик прерывания запустится не более
> чем через 400 тактов от события ).Линукс все же несколько более крупная система и там главное действо не в обработчиках прерываний происходит. А в юзеровских задачах. В прерываниях работа с железками которая вообще в "юзерскую" логику не входит особо.
> Тут - ну допустим, будет 400 000 000 000 тактов, в течение
> которых гарантированно будет произведён обратный вызов. Что не так ? Чем
> не жОская гарантия ? -Та же Фри-РТОСь и этого не гарантируетЕсли это время всегда выдерживается - окей, это реалтайм. Просто очень неспешный. Ну вот такие аллигаторы, летают низенько. Реально ессно там более потребные времянки будут.
Ну это же не жесткое реальное время, АЭС ты на такой системе не построишь всё равно.
Для АЭС под это дело нужны свои процессоры. На процессорах интела, амд, арма, риска и т.д. нельзя, они это даже в лицензии пишут, что запрещено использовать их процы для высокоточных устройств, медицинских аппаратов, спутников и научных машин. И ответственность они за подрыв аэс во сферической в вакууме франции из-за интела в контуре они не возьмут. А если по существу, то процы для аэс ни одна развитая страна в мире уже не производит, только Россия, Китай.
Никто специализированный процессоры для АЭС не производит. Просто все критические функции возлагаются на ПЛИС или МК таким образом, чтобы, во-первых, они дублировались 4-5 раз, во-вторых, чтобы многозадачных компонентов с конкурирующими критическими задачами вообще не было.
Сбор данных так же дублирован 4-5 раз. Поэтому нормальной является картина, когда оператор может один и тот же показатель посмотреть на трех разных индикаторах и визуально убедиться, что только один из МК, ПЛИС или датчиков вышел из строя.
АЭС - это не тот объект, который можно доверить одной системе даже с самой продвинутой RT OS. У одного оператора в распоряжении, обычно 4-5 служебных компьютера. В штатной ситуации он может использовать каждый для отображения разной информации. Но они полностью взаимозаменямы.
Теоретически, достаточно трех компьютеров (если проблема с одним, но на двух других информация совпадет). А практически, если один из трех выйдет из строя, то сравнивать показатели двух других уже смысла не будет, а мгновенно отремонтировать или заменить третий - невозможно. Отсюда и 4-5.
> Теоретически, достаточно трех компьютеров (если проблема с одним, но на двух других
> информация совпадет). А практически, если один из трех выйдет из строя,
> то сравнивать показатели двух других уже смысла не будет,Вообще-то будет: обнаружение сбоя -> safe state. Ну да, в этом случае уже более радикально и интрузивно, про нонстоп речь уже не идет.
Вот только если учесть, что после сброса аварийных стержней и/или вливания замедлителя нейтронов в первый контур (safe state), реактор запускать минимум две недели (обычно - месяц), а все это время и зарплату персоналу платить и энергию не продавать, то выгодней продублировать лишний раз, чем хотя бы один раз получить убытки от простоя из-за экономии на дублировании.
> Вот только если учесть, что после сброса аварийных стержней и/или вливания замедлителя
> нейтронов в первый контур (safe state), реактор запускать минимум две недели...не такой уж плохой вариант, по сравнению с новым Чернобылем или хоть тримайл-айлэндом каким, сколько там перезапуск занимает? :)
> (обычно - месяц), а все это время и зарплату персоналу платить
> и энергию не продавать, то выгодней продублировать лишний раз, чем хотя
> бы один раз получить убытки от простоя из-за экономии на дублировании.Оно как бы да, не то место где экономить уместно.
Уместно экономить или нет, как правило, решает владелец кошелька.
> Уместно экономить или нет, как правило, решает владелец кошелька.В случае АЭС это видите ли чуть сложнее, потому что йопс на АЭС нагибает интересы больно уж много кого. И регламенты на это дело жесткие. У всех. Там владельцу кошелька единолично художествовать все же никто не даст, да еще например международный магатэ есть бонусом.
> да еще например международный магатэ есть бонусом.Бесполезная организация без задач.
С точки зрения инвестора, кроме OSART аудит безопасности на АЭС проводить больше некому. Уж слишком эта сфера монополизирована. Проводить аудит строителем АЭС недопустимо, его конкурентом - слишком субъективно, не проводить аудит - рисковать инвестициями.
> Бесполезная организация без задач.Унылый наброс без скилла, анон.
>Никто специализированный процессоры для АЭС не производит.НИИСИ производит.
В linuxcnc помнится 3-5 микросекунд задержки на прерывание достигается сравнмтельно легко. Берется многоядерный проц и одно ядро (физическое, с учетом как распределены кэши и тд) изолируется под реалтаймовое приложение. Все остальное бегает как обычно на других ядрах. Там есть тестовая приблуда чтобы измерять время между двумя обработчиками прерываний, они там битик ставят/считывают с параллельного порта, даже график строит распределения времени между обработчиками. На дохлом двухядерноом атлончике 2600 получалось типа 10 микросекунд, стабильных, без единого разрыва в течении десятков минут.
А с ARM пробовали сравнивать?
у старёхоньких советских МК уже была реакция доли мкс при частотах ~10 МГц. Куда делись современные гигагерцы?!
> у старёхоньких советских МК уже была реакция доли мкс при частотах ~10
> МГц. Куда делись современные гигагерцы?!Откройте для себя микроконтроллеры. Все то же самое но - сильно лучше. Гигагерцев там конечно же нет - максимум сотни мегагерц, чтобы память поспевала за ядром и не было вот тех здоровенных кешей которые вносят сильную непредсказуемость в время реакции.
А если ну капец как надо есть FPGA, там очень быстро (единицы наносекунд, если не доли) можно. Для понимания - народ допустим пуляет свой радиосигнал или лазер, ловит отраженку, делает вывод о расстоянии. Вот только свет быстрый и если у системы клок 100МГц - она в принципе не оперирует юнитами кратными менее чем трем метрам тогда.
Если на МК при прерывании сохранять в стек все регистры, коих там может быть несколько десятков. То на 100МГц доли микросекунд на выполенение всего обработчика прерывания не всегда получаются. И это не считая неопределенностей, которые вносятся DMA.
Так что да, если нужны наносекунды - то ПЛИС.А вообще вспоминаю конец 80-х, когда я еще студентом занимался на кафедре АФАР-ами. Там то надо не просто что-то посчитать, а в реальном времени систему дифуров решать. Проблему решили тупо и в лоб, не заруливая исходные аналоговые сигналы напрямую на АЦП, а предварительно интегрируя их на прецизионых ОУ. Не исключаю, что и сейчас подобные задачи есть прямой смысл решать на ОУ.
> Если на МК при прерывании сохранять в стек все регистры, коих там
> может быть несколько десятков.Фирма ARM на этот счет придумала прикольные фокусы. Например:
1) Проц автоматически сохраняет несколько регистров.
2) Проц гарвард на уровне физики и поэтому фетчит код из флеша в то же время пока идет запись в SRAM.
3) Кто сказал что их ВСЕ надо сохранять? Они регламентировали ABI и на его уровне условились что вот эти регистры для параметров caller, эти можно рушить, эти нельзя. И сохранять надо лишь часть.
4) Микроконтроллерные ядра умеют довольно нахальный фокус. Tail chaining. При входе в IRQ если проц пушил состояние в стек и более приоритетное прилетело - ну он тогда сразу в него пойдет, скипнув переклюк контекста. И при возврате сразу провалится в менее приоритетное, скипнув восстановление и пересохранение. Более того - при выходе в фон если новый IRQ прилетел быстрей чем восстановили состояние, на это забивается и он опять сразу в IRQ заваливается. Так что при IRQ Storm микроконтроллерный арм нехило оптимизирует скорость IRQ, как раз скипая сохранение-рестор: ведь состояние фона уже сохранено. Ну да, фон при шторме IRQ встанет на якорь, но скорость обработки IRQ будет очень даже, латенси входа в IRQ таким манером может быть считанные циклы.
5) Многие вещи можно подпереть железом, таймерами, DMA и всем таким. А прикиньте, можно по таймеру выгрузить в GPIO какой через использование DMA, заранее подготовив блок данных. Проц даже не узнает что это было - кроме IRQ в стиле "мы тут послали весь блок, давайте еще".> То на 100МГц доли микросекунд на выполенение всего обработчика прерывания
> не всегда получаются.Если надо совсем жестко влезть можно еще
1) Вырубить IRQ нафиг.
2) Заглушить DMA если спертый им цикл шины был критичен.
3) Интенсивно поллить/записывать потребный ресурс фоном монопольно.
4) Бонус это interleave кода и данных по нескольким устройствам памяти.Да, при этом 1-задачность - зато все ресурсы монопольно доступны вот этому коду. Без сохранения состояний и проч. Исследователи так исползуют 1 процик для вторжения в мир другого, оперируя вполне сравнимыми таймингами. Ну вон там STM32 vs power glitching где 32L и проч Level 2 защиты до Level 1 даунгрейдят, сбивая питание именно в момент чтения чипом фузов.
> И это не считая неопределенностей, которые вносятся DMA.
Тут все просто: чем сложнее система тем она менее предсказуема. С другой стороны если DMA удалось припахать - входа в IRQ вообще нет, он просто мувнет данные туда или сюда. И все. Это вообще имеет минимальный латенси само по себе, в пределах единиц цикла шины. А мы там где-то потом уже посмотрим, если вот именно немедленная, именно реакция все же не интересовала, только регистрация факта или что-то такое.
> Так что да, если нужны наносекунды - то ПЛИС.
Если вот именно совсем - то да. Но их неудобно програмить, с опенсорсными тулчейнами так себе, и порой доходит до того что для высокоуровневой координации софт-ядро поднимают, чтобы общую координацию делать там. Для меня FPGA больно уж экзотичны и с опенсорсными тулчейнами не очень, или нету или какая-нибудь наколенная питонодрянь.
> заруливая исходные аналоговые сигналы напрямую на АЦП, а предварительно интегрируя их
> на прецизионых ОУ. Не исключаю, что и сейчас подобные задачи есть
> прямой смысл решать на ОУ.Как бы сейчас стало модно встраивать 1-2 ОУ и (аналоговых) компаратора прям в чип микроконтроллера. Даже если вон то не надо, то даже просто ток померять, точно и быстро - ну, как бы, высокоомные шунты не рулят а милливольты с низкоомного выковыривать лучше все же после усиления, а не так что в полутора младших разрядах ADC колупаться. А заодно выход может быть на ADC или IRQ или куда там (актуальнее для компаратора) сразу.
> 1) Проц автоматически сохраняет несколько регистров.Какая разница, если каждая запись в RAM все равно машинный цикл, даже если он один такт? Тот же STM32 25 слов (при наличии FP) хреначит в стек и столько же потом вытаскивает. А это, простите, уже 50 тактов.
> 2) Проц гарвард на уровне физики и поэтому фетчит код из флеша в то же время пока идет запись в SRAM.Во-первых, по разному бывает. На том же STM32 порой нужно выполнять код из RAM. Во-вторых, ко времени выполнения обработчика прерываний это имеет очень косвенное отношение.
> 3) Кто сказал что их ВСЕ надо сохранять?Если просто в вызываемой функции, то только в соответствии с ABI. Но в обработчике прерываний, уж простите, как минимум все регистры, которые будут в этом обработчике использованы. Вне зависимости от ABI.
> 4) скипнув восстановление и пересохранениеПо сравнению с программно доступными регистрами - копейки. Причем речь уже о частном случае. Векторов прерываний у МК не так уж много. Даже в STM32 - по одному вектору на 8 GPIO.
> Если надо совсем жесткоМы же про время выполнения обработчика прерываний говорим. А так да, сам бывало на критические задачи STM8 или ATTINY ставил в таком монопольном режиме. До Paduk так до сих пор и не добрался, хотя подобные задачи - уж точно для них. При цене то в 2-3 цента за корпус.
> Как бы сейчас стало модно встраивать 1-2 ОУЭто редкость. У ST только в STM32G4/L4. Да и для вышеописанной задачи два ОУ ничем не помогут. Даже самые простенькие лабораторные прототипы АФАР требовали сотню-другую ОУ. А уж серийные - свыше тысячи.
> Какая разница,Большая. Во первых всего несколько записей и несколько циклов. Во вторых их делает железо без разбавки этого инструкциями для нескольких регистров. Так что через несколько циклов обработчик IRQ получает контроль и это к тому же будет стандартное сишное ABI, так то, прикольно придумано.
> если каждая запись в RAM все равно машинный цикл,
Этих машинных циклов довольно скромно может быть, если надо именно это. А на reentry когда зашивалиись и не успели состояние восстановить - и того меньше, железо достаточно сообразительно чтобы стопнуть восстанов на середине, и проскипать сохранение, т.к. не успели же снести сохраненное с прошлого раза еще.
> даже если он один такт? Тот же STM32 25 слов (при наличии FP)
> хреначит в стек и столько же потом вытаскивает. А это, простите, уже 50 тактов.Простите но вы не в теме.
Во первых лично я пользуюсь M0/M3 где FP нет, в т.ч. и потому: мне больше предсказуемость надо чем bulk performance. Более мелкая и простая система проще в осознании и понимании worst case. А самые жесткие сертификаты для критичных применений у STMок у M0/M0+ вообще: там проще всего надежность и предсказуемость системы от и до изучить было, потому и.
Во вторых насколько я помню, плавучка в M4 опциональна, даже в M4F. Можно и не сохранять.
В третьих даже если сохранять - они сделали там какой-то забавный чит, когда большая часть регистров плавучки может быть сохранена в фоне, ПОСЛЕ того как IRQ handler получил управление. Они это как-то типа фонового сохранения обозвали. Я не особо интересовался, т.к. предпочитаю не создавать себе проблем и использую M0/M3.
> Во-первых, по разному бывает. На том же STM32 порой нужно выполнять код из RAM.
Это несколько экзотика. И там еще флеха не обязана поспевать за ядром на всем ходу, есть wait states, а префетчер и 64-бит шина это аннулирует только частично, и вносит небольной но все же джиттер. Но все же, interleaving шин есть и латенси в целом довольно умеренный может быть.
Для большей предсказуемости можно флеху с 0 wait states гонять - но тогда 24МГц максимум.
> Во-вторых, ко времени выполнения обработчика прерываний это имеет очень
> косвенное отношение.И тем не менее, латенси у упомянутых культурная и близко не стояла с ужастиками про которые вы вещали.
> Если просто в вызываемой функции, то только в соответствии с ABI.
Если мы про IRQ то там сохраняет само железо, пойнт в том что мы скипаем явные команды push/pop разгружая I-bus для более полезных вещей. Это и латенси улучшает в том числе. А бонусом обработчик IRQ - просто сишная функция. То что ему ABI железо cделало он не знает.
Если мы про основной код, у современных оптимизеров могут быть свои идеи на этот счет. Они могут вообще заинлайнить маленький кусочек актуальный в именно ЭТОМ контексте от всей функции, просчитав что это выгоднее, что тут всегда вот так, и вообще заскипав call функции как таковой, и все пляски, вместо этого врезав тот кусочек который бы в этом кейсе выполнялся как несколько команд. Особенно LTO это дело любит.
> Но в обработчике прерываний, уж простите, как минимум все регистры, которые будут
> в этом обработчике использованы. Вне зависимости от ABI.При том их еще до входа железка сама пушнула за считанные такты, входных параметров у (void) точно нету, и что-то пушить именно в коде хэндлера придется только если ему ABIшных регистров мало окажется. И если это сильно актуально можно и на асмовый код посмотреть. А если совсем уж приперло, играем мизера, запасу нет, можно и на асме хэндлер выписать, тогда уже точно с гарантиями.
> По сравнению с программно доступными регистрами - копейки.
Однако компилер так то в курсе правил ABI и первым делом упихивается в него. Но можно и на асме выписать если совсем приспичило. Я не развалюсь, право - обработчики IRQ обычно простые и быстрые так то стараются делать.
> Причем речь уже о частном случае.
Если мы полезли такты считать, мы всяко конкретную систему анализируем - в другой железке это может быть иным прямо на уровне их железа, там надо изучать уже их систему и их особенности и лимиты.
> Векторов прерываний у МК не так уж много.
У STM32F0/1xx - около 80 штук бывает. Я б сказал, нормальненько так. Кстати там еще и можно более приоритетным менее приоритетного задвигать, и кстати сохранение контекста при этом уже не потребуется, уже сделано для менее приоритетного так то.
> Даже в STM32 - по одному вектору на 8 GPIO.
Описание EXTI этот сэр явно не читал. Все не так: есть эн обработчиков для именно 1 лапки, куда можно приаттачить именно 1 лапку, а есть shared, общие для сразу нескольких, но опять же, никто не запрещает с собой договориться что там только 1 лапку разруливаем. А другие - на другие обработчики. Ну да, у меня бонус: я "фулстэк". Могу гибридные решения: если становится неудобно софту, переделаю роутинг печатки. Если неудобно железу/разводке, я могу пересмотреть конфигурацию в софте. У фулстэка есть преимущества, более плотный контроль над системой и возможность сделать себе удобно и логично - среди них.
> Мы же про время выполнения обработчика прерываний говорим. А так да, сам
> бывало на критические задачи STM8 или ATTINY ставил в таком монопольном режиме.Да я и на STM32F1 так пару раз делал. А чего б ему.
> До Paduk так до сих пор и не добрался, хотя подобные задачи - уж точно для них.
> При цене то в 2-3 цента за корпус.Я не гоняю масспрод миллионами юнитов имеючи интерес больше к кастом деву и подобному, так что мне всякая китайская пакость не особо сдалась. С атмелками я немного могу поразвлечься по старой памяти но смысла в них когда STM32 есть я честно говоря почти не вижу. "Bang per buck" у атмелов какой-то не спортивный уж очень на фоне вон тех. А если кому мелочь надо то G0 в 8 лапом корпусе появился. Вот так вот можно в SO-8 чип с DMA получить :)
> Это редкость. У ST только в STM32G4/L4.
Кто посмел с314ть опамп в моих L15x?!
> требовали сотню-другую ОУ. А уж серийные - свыше тысячи.
Кошмар какой, парад антитехнологичности. Теперь я понимаю почему Маск в своем старлинке кастомные чипы beamformer от STM поставил. Их там полсотни всего чтоли, по 1 на свой патч вроде.
> Какая разница,
> Большая.Сами себе противоречите. Шина выборки команд из флеша автономна от шины доступа к RAM. Поэтому без разницы, одной командой Вы 25 слов хреначите в стек или 25-ю. Время тоже самое получите.
> лично я пользуюсь M0/M3 где FP нет
Это к чему? Частные случаи бывают разные, но речь то об общем случае.
> Можно и не сохранять.
Пруф? В PM0214 "When using floating-point routines, the Cortex-M4 processor automatically stacks the architected floating-point state on exception entry."
> они сделали там какой-то забавный чит, когда большая часть регистров плавучки может быть сохранена в фоне, ПОСЛЕ того как IRQ handler получил управление
Пруф? В PM0214 читаю обратное: "When stacking is complete, the processor starts executing the exception handler."
> Если мы про IRQ то там сохраняет само железо, пойнт в том что мы скипаем явные команды push/pop разгружая I-bus для более полезных вещей.
Но на загрузку шины доступа к RAM это не влияет никак, как и на время выполнения обработчика прерывания. К тому же из регистров общего назначения автоматически сохраняются только R0-R3 и R12. Если в обработчике нужны остальные - извольте сохранять их в стек вручную.
> Для большей предсказуемости можно флеху с 0 wait states гонять - но тогда 24МГц максимум.
Где меньше микросекунды на обработчик прерывания уже становится фантастикой. Так как только автоматическое стекирование 8 слов и автоматическим восстановлением из стека этих же 8 слов - уже 16 тактов.
> Кошмар какой, парад антитехнологичности.
Ваше предложение для чего-то вроде "Дарьял" (4000 элементов АФАР), с которым я тогда работал?
У современной "Воронеж" их может быть раза в два-три больше.
> есть эн обработчиков для именно 1 лапки, куда можно приаттачить именно 1 лапкуВ M3 их всего 16, что для ряда задач катастрофически мало.
> Да я и на STM32F1 так пару раз делал. А чего б ему.
Автобус тоже можно в качестве такси использовать, "А чего б ему" )))
> Ну да, у меня бонус: я "фулстэк".
Вы просто не знаете, что такое "фулстэк" )))
Это я fullstack. От датчиков и МК до GUI на node.js у пользователя в браузере, через Kafka, Big Data и ML.
> Сами себе противоречите.Или знаю чуть больше вас по теме.
> Шина выборки команд из флеша автономна от шины доступа к RAM.
Cortex M0 например фон нейман в том числе и по шине, у него 1 на всех и он с этого будет в сильном минусе. А идея в более-менее совместимом выводке. Так что если про ОБЩИЙ СЛУЧАЙ... в общем случае хардварное zero-code секвенсирование эффективнее софтварного. Алсо вполне валидно если DMA в это время сходит в флеш и утянет константы в периферию, bus master же.
> Поэтому без разницы, одной командой Вы 25 слов хреначите
> в стек или 25-ю. Время тоже самое получите.Инженеры фирмы ARM попродвинутее вас будут и свое дело знают.
> Это к чему? Частные случаи бывают разные, но речь то об общем случае.
А, вот так? Ну тогда вон там мой ответ в том же стиле. Я просто M4F не пользовался, но краем глаза видел блабла в TRM и рядом что если плавучкой не ползоваться то можно отключить сохранение этого совсем, а если пользоваться - "lazy" фоновое сохранение есть.
> Пруф? В PM0214 "When using floating-point routines, the Cortex-M4 processor automatically
> stacks the architected floating-point state on exception entry."Если "when using" не случается - там вроде есть бит какой-то запрещающий вон то. Но у M0/M3 такой проблемы нет вообще и хотя они "частные случаи", я больше вхож в эти случаи, активно ворочаю высокоскоростными прерываниями, не имею с этим траблов и поэтому не согласен с вами.
> Пруф?
Раз https://community.arm.com/arm-community-blogs/b/architecture...
Два https://stackoverflow.com/questions/65269724/why-is-the-irq-...
> В PM0214
"Смотрю в книгу, вижу..."
> Но на загрузку шины доступа к RAM это не влияет никак,
Да, но там лишь несколько регистров. По вон той линке кстати и точные числа циклов. M4 даже шустрей без плавучки, но для меня он здоровый слишком в него вкуривать и рулить вон тем всем.
> как и на время выполнения обработчика прерывания.
Чудес не бывает, если IRQ пользуется регистрами время на шине RAM на их сохранение придется потратить.
> К тому же из регистров общего назначения автоматически сохраняются только R0-R3 и R12.
Этого хватит по минимуму чтобы начать что-то делать.
> Если в обработчике нужны остальные - извольте сохранять их в стек вручную.
Сложные (и медленные) обработчики IRQ так то плохая практика.
> Где меньше микросекунды на обработчик прерывания уже становится фантастикой.
Скорость и предсказуемость часто живут по разную сторону улицы.
> Ваше предложение для чего-то вроде "Дарьял" (4000 элементов АФАР),
> с которым я тогда работал?ASIC отлить, как вон те. Впрочем если штучно - это еще терпимо. Но надежность такой шляпы будет никакая. Тысячи чипов и контактов это капец.
> их может быть раза в два-три больше.
Эти люди умеют показать как именно инженерить не стоит. Я усвоил.
> В M3 их всего 16, что для ряда задач катастрофически мало.
Это про внешние прерывания чтоли? На мой вкус "в общем случае" более 16 IRQ на внешних лапах это уже какая-то экзотика. У меня не было ни 1 проекта где я бы в такой лимит уперся вообще.
> Автобус тоже можно в качестве такси использовать, "А чего б ему" )))
Ну как бы задача либо решается за обозримое время устраивающими методами, либо нет. И если автобус подкатил и согласен на это а такси хрен его знает где - ну вы ждите такси а я поехал.
> Вы просто не знаете, что такое "фулстэк" )))
> Это я fullstack. От датчиков и МК до GUI на node.js у
> пользователя в браузере, через Kafka, Big Data и ML.Таким жестким крапом я не оперирую. Просто потому что мне он отвратителен. А вот мордочку в чем-то типа lwan.ws в каком одноплатничке я нарисую. И дистр на нем запущу. Да еще с околосабжевыми адаптациями, когда оно таки будет надежной управляющей системой по своей природе.
Зато как видите отличие в деталях обеспечивает ... отличия в деталях. Я знаю свои системы. И их лимиты. Можете ли вы то же сказать по кафку - хз. Я просто имею дело с тем что умещается в мою голову и где я могу что-то кому-то гарантировать в результате. Прежде всего понимание моих систем и отсутствие глупых промашек, в том числе и самому себе для начала. Ну вот видите, вы с вашей кафкой на латенси IRQ срезались. А я свои системы знаю.
Еще вот кстати https://www.state-machine.com/doc/ARM-AN298.pdf попалось. Подробное освещение топика фирмой ARM в апноте. А лично я M4F не использую вот как раз чтобы всем этим мозги не греть, для меня это именно реалтаймные системы с шустрой реакцией а не числодробилки. Поэтому M4 - уже перебор для меня и моих целей как таковой, только систему усложняет в понимании.
Остались во временах систем типа MS-DOS.
> В linuxcnc помнится 3-5 микросекунд задержки на прерывание достигается сравнмтельно легко.
> Берется многоядерный проц и одно ядро (физическое, с учетом как распределены
> кэши и тд) изолируется под реалтаймовое приложение.В настоящем realtime вопрос - о том какие ГАРАНТИИ у нас при этом есть. Linuxcnc это не так уж критично. Но кто вам обещал что выделенный проц не уйдет в обработчик SMI# какой - забыв вас спросить что вы думали про это? Ну ладно, если это ARM и бутлоадер открытый там еще на это можно уповать, но на обычном компе с проприетарным BIOS/EFI вы вообще не знаете кто и почему SMI может вызвать и сколько worst case... и даже запретить это нельзя, ос просто ставится перед фактом что некто спер X времени проца. И все. Поэтому x86 заведомо не годная для настоящего реалтайма платформа. Можно заворкэраундить, конечно, но довольно сложно.
А так вы на самом деле мк хотели с такими аппетитами. Там и пару сотен наносекунд можно предсказуемо окучить. Даже меньше если очень надо (но лучше FPGA тогда взять).
> 2600 получалось типа 10 микросекунд, стабильных, без единого разрыва в течении
> десятков минут.10 микросекунд. Да фу на вас - я на мк каждые 10 мкс в IRQ проваливался предсказуемо, там это почти вечность, достаточно чтобы сохранить состояние, войти в IRQ, сделать что-то, свалить оттуда - и даже фону что-то еще останется. Но вообще так не надо делать, фу такими быть. Даже если это и работает.
Нет. Хард реал тайм и реал тайм -- это две большие разницы. Линукс при всем моём почтении не может 7арантировать ничего. Да и если что -- перезагрузка Линукса явно не уложится в отведённые интервалы.
> Нет. Хард реал тайм и реал тайм -- это две большие разницы.
> Линукс при всем моём почтении не может 7арантировать ничего.Вообще-то тот набор патчей это как раз о именно гарантиях, именно в стиле достаточно жесткого реалтайма. Там и реворк шедулера процессов на тему, и перетряс всего что может якорить кернел, вплоть до printk (внезапно).
> Да и если что -- перезагрузка Линукса явно не уложится в отведённые интервалы.
Это вы видео загрузки линукса за 0.3 секунды не видели просто, он там не грузится, он включается, там на видео ресет жмут несколько раз для иллюстрации. А чего, это тоже линукс. Просто оптимизированый под вот именно это. В иных случаях это может быть не так уж и важно если системы дублированые. Пока оно там ребутается рулить просто будет дублер.
Протестируй и отчитайся. В трёхдневный срок.
Этим rt патчам более 10 лет и оно не для десктопа
Не свисти, находясь в трансе. От реалтайм ядра на десктопе повышается отзывчивость, но ухудшается работа энергосбережения(из-за замены мутексов на спинлоки). Хотя в настоящее время разницы по отзывчивости всё меньше и меньше, ибо самое важное уже перенесли в апстрим. Ещё можешь lowlatency попробовать. Очень близко к реалтайму, особенно на десктопе.
Он таки не очень свистит - те патчи на индустриаловку ориентированы. В последних майнлайнах их почти все в основное ядро взяли, и - знаете - именно жесткий, именно реалтайм, когда срыв deadline не допустим вообще совсем - он таки далеко не халявная штука. В том смысле что фичи которые могут заякорить систему приходится бустать, ряд оптимизация перфоманса радикально вырубать, и проч.Вплоть до того что они например в свежих ядрах хотели совсем вырубить printk(). Сначала его просто буферами подперли на случай если IO медленнее чем темп печати в коде, что довольно типично для "отладочного uart" например. Но буфер может закончиться и тогда сообщения либо терять, либо нарушать реалтаймные гарантии паузя код. В любом случае гарантированость теряется и они решили что раз так то возможно имеет смысл совсем отрубить фичу чтобы уж точно не заякорила именно реалтайм. А то что дебажить станет менее удобно...
>Как это проверить, что оно "обеспечивающих снижение задержек и позволяющих добиться предсказуемого времени обработки событий"?Проверить какой минимальный буфер можно выделить в jackd до появления первого xrun
Ждём выпуск Astra Linux RealTime Edition :-)
Напомните им только из версии "~ubuntu" убрать, чтобы хотя бы выглядело, будто они сами что-то собирают.
кому нужна поделка под тотальным контролем товарища майора?
Astra Linux это военизированный Debian, а не Ubuntu.
> Astra Linux это военизированный Debian, а не Ubuntu.Ну не скажи. Это бинарные пакеты, понадёрганные из разных дистров, в то числе и из Ubuntu, и слитые в одну репу.
Военизированного там нет ничего, кроме сертификации МО.
>Военизированного там нет ничегоНе знаю как сейчас, но раньше там были иконки с касками и солдатами и красная звезда на логотипе)
> Не знаю как сейчас, но раньше там были иконки с касками и солдатами и красная звезда на логотипе)А на фуражке на моей
Серп и молот, и звезда.
Как это трогательно!PS: не видел их UI, но с охотой верю.
Если не понимаете и не знаете что такое mandatory access control (MAC), то да - для таких как вы астровцы только и делают что тырят пакеты. Кто соображает в MAC, те понимают что такое астровский Parsec как конкурент AppArmor и SELinux. Значит патчить весь софт для работы системы мандатного доступа.
Ну, да, взять обычный кернеловый Smack (Simplified Mandatory Access Control Kernel), обвесить его правилами, всё подряд запрещающими, назвать всё это гордо Astra Parsec - очень продуктивно и самостийно! А потом, конечно, "патчить весь софт", потому что сами себе позапрещали всё подряд, но людям-то надо работать, а не в окошечках варнинги читать
А как найти связь SMACK и PARSEC?
Красава) размазал его по стенке)
Вся мандаторная система Астры построена поверх SeLinux, которая разработана АНБ. Я ничего отличного от SeLinux там не нашёл. На рабочем месте астра уже 3й год стоит."Как нам преодолеть эту маленькую боль?"(с)
Где же вы нашли в Астре SELinux? Там PARSEC.
> Если не понимаете и не знаете что такое mandatory access control (MAC), то да - для таких как вы астровцы только и делают что тырят пакеты. Кто соображает в MAC, те понимают что такое астровский Parsec как конкурент AppArmor и SELinux. Значит патчить весь софт для работы системы мандатного доступа.Дорогой, не надо мне вешать лапшу про безопасность Астры.
Такие вещи, как AppArmor, SELinux и ваш Parsec -- не более чем надстройки для увеличения безопасности дистрибутива. Чтобы от них был прок, у вас должна быть стабильная база. А для этого -- надо ХОТЯ БЫ начать собирать пакеты самостоятельно, а не тупо дёргать бинарные пакеты из разных дистров.
Вы же клепаете свой дистрибутив настолько на oтъeбиcь, что после установки -- даже нет готовых к использованию строк в /etc/apt/sources.list (а их ещё фиг найдёшь в ваших довольно посредственных доках), не установлен пакет ca-certificates (с фига ли?), не сконфигурирована сеть (ну хоть бы dhcp на eth0 поставили, а то что это такое -- я могу в инсталляторе указать необходимость установки демона ssh, но работать он не будет, поскольку единственный сконфигурированный интерфейс -- это loopback).
И это я ещё молчу о том, что вы даунгрейдите версии пакетов без инкремента эпохи, из-за чего ваш долбанный дистрибутив в принципе не способен обновляться штатными средствами APT. Молчу о том, пакеты locales-all и locales у вас имеют разные версии, хотя вообще-то они собираются из одного src-пакета и разные версии иметь не могут. Причём второй -- к чертям поломанный. А ведь это самая база, ё-моё. Вообще не вспоминаю о том, что чтобы отправить вам баг на багтрекер, нужно сначала купить там аккаунт. А если связаться с вашими менеджерами и сообщить им о проблеме, получишь ответ вида "вы всё врёте, у нас всё идеально, идите нaxep".
Вот серьёзно, при таком подходе к построению дистрибутива вы ещё смеете заикаться о какой-то там безопасности? Единственные хорошие люди у вас -- это продажники, они своё дело знают. А с технической стороны у вас сидят одни только безграмотные обезьяны, ламеры, которые не заслуживают ни единого хвалебного слова.
Да! Я час убил на чтобы чтобы настроить обновление свежеустановленной Астры продираясь через доку на сайте Астры.
Это забор для тех, кто не купил саппорт?
Пусть напишут свои патчи, тогда будем ждать. А взять готовые чужие - это плагиа^W импортозамещение.
Если даже оставить в стороне вопрос о том, насколько оно, ядро, в действительности реалтаймовое, остаётся вопрос о том, как эту реалтаймовость будет использовать софт, для которого задержки имеют значение (тот же астериск, или по для видеостриминга), если оно писалось под обычное ядро?
Да никак. Это для эмбедок, ЧПУ и автономок всяких типа БПЛА. Берёшь ядро, пишешь спецом под него с учётом всех особенностей.
Там совсем другие ОС используются. Самое реальное применение реал тайм линукса это для музыкантов, чтобы у них звук быстрее в колонки вылетал.
Есть пакет linuxcnc, используется для управления станками, ему важно постоянное короткое время сервоцикла для управления движением. оно как раз работает на rt ядре.
И какие же другие ОС там используются? расскажи...
В БПЛА часто стоит LynxOS, MicroC/OS-II, FreeRTOS. Последний например в новых DJI.
> В БПЛА часто стоит LynxOS, MicroC/OS-II, FreeRTOS. Последний например в новых DJI.Телеметрию китайским тулсам джы хорошо шлет, так что благодарные пользователи очень радовались тому что это научились ловить не только китайцы. Сразу дроновод стал опасной профессией :)))
И правильно ишь чо удумали летать где хочется. Им и запрет по GPS координатам и всё такое, а они всё летают и летают.
> И правильно ишь чо удумали летать где хочется. Им и запрет по
> GPS координатам и всё такое, а они всё летают и летают.Время такое, "игра эндера" почему-то очень популярна за пределами кинотеатров. Наверное, секрет в том что очень соблазнительно вместо себя железку отправить иногда. Вон там некто едва увернувшийся от подарка аж 5 раз очень "радовался" "фиче", которую оказывается "партнеры" раскололи и стали таргетированую рекламу прямо в пультик wannabe-эндера присылать. А с другой стороны экрана эндеры жирно троллят: мол, что за лохи! А мы тут уже научились им фирмвары переливать без такой фичи - конкуренты не одупляют почему реклама не таргетируется, какая печалька.
> И какие же другие ОС там используются? расскажи...Ну, вот, например, вот эта: https://en.wikipedia.org/wiki/RTEMS#Uses
В реальности на станках автоматической линии пайки использовалась windows. Windows NT на японском установщике 2003 года выпуска и windows XP, на 2х других частях линии.
Windows не является операционной системой реального времени.
Это CAM или какой-то интерфейс. У него ещё должна быть часть которая непосредственно двигает клешнями. Она может быть вообще без ОС как ардуина для простоты это можно назвать firmware.
> Windows не является операционной системой реального времениДля soft-realtime подходит.
Нет там никакой винды. Ты перепутал SCADA и реал тайм контроллер. Которые связаны полевыми шинами. Контроллёр про твой Шиндошс вообще понятия не имеет.
Короткий ответ: нет.
Правильные печи, авионика, атомка, медицина, умные боеприпасы: соответствие международным стандартам хард реал тайм? Нет? Спасибо, мы вам перезвоним, до свидания.
> насколько оно, ядро, в действительности реалтаймовоеты читать умеешь? С патчами -rt оно становится по-настоящему риалтаймовым, вот насколько. Без них - нет, не риалтаймовое.
Все критерии реалтаймовости в студию. А потом ещё гарантии от интелла и амд насчёт времени выполнения инструкций.
> Все критерии реалтаймовости в студию.Для жесткого реалтайма - время реакции не хуже чем X в совершенно любых условиях. То-есть не важно какие там камнепады, апдейты, активность и проч - система либо отвечает за X либо нет. Это бинарная величина: гарантии либо держатся, либо нет. Всегда.
Нет. Это только одно из 4х условий. А за этими основными -- ещё полтора десятка требований.
> Нет. Это только одно из 4х условий. А за этими основными --
> ещё полтора десятка требований.Ну это главное. Без него остальное не важно уже. И с вот именно этим так то довольно много проблем.
> С добавлением к названию "-rt" оно становится по-настоящему риалтаймовым, вот насколько.Поправил за тебя.
Слышь юморист, яндекс как-то выкаытвал описание как московское метро на этом поезда гоняет. В ПЛК и на серверах там "realtime linux", представляешь? И вот оно в реальном времени трекает где какой поезд у него и рулит движением оных, так то. И патчи там ну вот те самые как раз.
Нет. В контроллерах Симатик Сименс С400 никаких линуксов и в помине нет. Там даже QNX нет.
И без аппаратного ключа хрен ты прошивку обновить.
> Нет. В контроллерах Симатик Сименс С400 никаких линуксов и в помине нет.А таки была презентация яндекса где они вот именно линух использовали, и в плк, и на серверах. И описание как это все взаимодействует. Я бы такое сам не придумал, ищите в поискаре, на какой-то яндекс конфе это было.
Ну и систем такого плана на линухе сейчас уже и без этих - есть. И RT_LINUX так то им в основном надо.
> А таки была презентация яндекса где они вот именно линух использовали, и
> в плк, и на серверах. И описание как это все взаимодействует.
> Я бы такое сам не придумал, ищите в поискаре, на какой-то
> яндекс конфе это было.
> Ну и систем такого плана на линухе сейчас уже и без этих
> - есть. И RT_LINUX так то им в основном надо.Ещё раз: Сименс Симатик 400й серии. Никакого Линукса, Шиндошса там и в помине нет и никто их туда не пустит. Да и памяти там нет.
> Ещё раз: Сименс Симатик 400й серии. Никакого Линукса, Шиндошса там и в
> помине нет и никто их туда не пустит. Да и памяти там нет.Еще раз, поискарь вам в помощь - яндекс врядли врать на своих конфах станет. Вроде даже и тут новость была. Правда там упоминалось вроде что это экспериментальное внедрение. А рядом был и рассказ что есть RT_LINUX. Откуда он и попал под мое внимание так то, как фича.
У Сименс есть такая штука WinAC - программный контроллер под windows + RT-расширение IntervalZero. В ПК можно добавлять сименс-карты для поддержки полевых шин, а можно и без них, по tcp-протоколу через сетевую карту - если полевые устройства поддерживают tcp. Применяются в промышленности. Такую штуку можно развернуть и в vmware для теста.
Очень рад за них. А только сколько там времени до прохождения следующего поезда, чтобы стрелку передвинуть? Десятки секунд.
Нет. Такое ядро в промышленном применении использовать нельзя.
Оно не гарантирует хард реал тайм. В поделках гаражных -- на свой страх и риск. В серию -- убить на месте сразу.
> Нет. Такое ядро в промышленном применении использовать нельзя.Промышленные применения так то разные бывают. В том числе и по уровню критичности. Хотя конечно убунтуйское ядро там использовать как впрочем и убунту - ну да, идейка для суицидника, который хочет проверить не посадят ли за жирный продолб в тюрьму.
Ну с учетом того, что x86 начиная с 386 проца, не может быть нормальным процом для RT ,а так все хорошо.
Почему?
Какая прелесть, простой вопрос "Почему?" набрал уже (на 16:00 15.02.2023) уже три минуса.
А вот мне тоже интересно, что что не так с i386, почему он не подходит для rt?
> i386, почему он не подходит для rt?потому что он не rt.
> Почему?Потому что уйдет он в SMM# IRQ по хрен его знает какому критерию - и сколько он там по максимуму отвисать мог - только проприетарное фирмваре с обработчиком SMM IRQ и знает. И отключить SMM IRQ система не может - систему просто вышибает более привилегированный "ring -1" и потом она как максимум может констатироват что "кто-то спер эн времени проца". Предотвратить это ОС не может.
И как вы на такой платформе кому-то что-то гарантировать собираетесь насчет времен реации, интересно?
QNX-цы лохи оказывается. Им надо было опеннетовского иксперта сначала спросить, что такое нормальный проц для RT, прежде чем начинать свою RTOS пилить в том числе и для 386 проца. А, подождите... Иксперт, вероятно, тогда еще в детском садике куличики из песка лепил или лягушек через соломинку надувал - некогда ему было консультировать глупых дядек. Или, возможно, разработчики всех обманули со своей RTOS, утверждая, что она RT.
Да, кагбэ, и кроме QNX дофига ОСРВ, которые работают на x86: https://en.wikipedia.org/wiki/Comparison_of_real-time_operat...
> QNX-цы лохи оказывается. Им надо было опеннетовского иксперта сначала спросить, что такое
> нормальный проц для RT, прежде чем начинать свою RTOS пилить в
> том числе и для 386 проца. А, подождите... Иксперт, вероятно, тогда
> еще в детском садике куличики из песка лепил или лягушек через
> соломинку надувал - некогда ему было консультировать глупых дядек. Или, возможно,
> разработчики всех обманули со своей RTOS, утверждая, что она RT.Ну начиная с 80386 действительно много чего изменилась и у QNX.
Один момент, я бы сказал говорил не за весь x86 процессоры, а больше про платформу. Другой момент, что x86 редко когда можно увидеть вне платформы intel, особенно современную реализацию.Банальный SMM, убери его и все станет хорошо. Правда ой, оказывается у нас есть еще одна система RT в чипсете , на текущий момент переработка minix 3 (и в целом ME). Ой , а еще оказываются бывает поддержка гипервизоров и понеслось говно по бочкам. Ну и надо уточнять про какой Rtos в итоге идет речь и насколько этот RTOS будет RTOS на самом деле. Еще интересно посмотреть в документацию QNX и почитать, что же они там пишут про свой Rtos в отношении x86 процов, там для многих просто будет откровение видимо.
> Банальный SMM, убери его и все станет хорошо.А, лол, как его убрать то? Его чипсет/железо вызывают по только им ведомым критериям и системная фирмварь вышибает операционку с треском, а та предотвратить это не может :). Ну наверное можно свой обработчик SMI в чем-то типа coreboot, и жесткий RTFM на железо - но для x86 это такой квест получается что проще будет ARM какой-нибудь взять, там достичь такого будет в 20 раз проще. Там полно систем с открытым системным фирмваре от и до, SMI нету, в общем все куда проще.
> нас есть еще одна система RT в чипсете , на текущий
> момент переработка minix 3 (и в целом ME).Она на отдельном проце живет и реалтайму не мешает.
> Ой , а еще оказываются бывает поддержка гипервизоров
Гипервизор можно обнаружить если это надо.
> многих просто будет откровение видимо.
А как же. Одно дело клеить беджик и другое дело соответствовать ему.
В крайнем случае можно особенный PC более дружественный к RT.
И есть всякие Vortex86. И я офигел - в России кажется делают слабые и старого стандарта X86, которые космически устойчивые.
>в России кажется делают слабые и старого стандарта X86, которые космически устойчивые.КомДив он называется. Радиационно стойкий процессор.
> В крайнем случае можно особенный PC более дружественный к RT.Угу, одноплатник с ARM называется :). Там и системное фирмаваре открытое и предсказуемое, и стартовать может со скоростью ракеты, и подлян нету, и в целом никаких ring -1 и прочих management engine. Куда как потребнее для вон тех развлечений.
> И есть всякие Vortex86.
Это для некромансеров-извращенцев всяких, имхо. Линуха можно просто на чем-то более приличном запускать.
Вот да, в такие новости надо сразу писать -- если у вас не осталось материнки до 2012 года выпуска, то не грузитесь вам это ядро нафиг не нужно.Все эти миниксы в материнках пустили латенси по ....
> Все эти миниксы в материнках пустили латенси по ....У этих миниксов так то отдельное выделенное ядро. Активное кстати даже когда комп типа-выключен, от дежурки питается :). А вы думаете как оно комп по сети включает, ос перекатывает и проч в всяких AMT/vPro и проч?! Так что латенси оно не сильно портит, разве что доступами к памяти. А вот секурити системы... эээ...
А SMM с его SMI# и ring -1 пустивший латенси и предсказуемость системы для ring0 есть аж с самого начала ака i386, кажись.
Чушь написал. Кроме проца -- там ещё и вачдогов пару стоит. И чипы весьма своеобразные, которые от твоего 386 камня на камне не оставляют. И режимы работы у такой системы, мягко говоря -- своеобразные.
Конечно, на ширпотреб ты накатить QNX можешь. Только такую систему ты можешь пользовать только как калькулятор и у себя дома. Потому что QNX сразу распознает подмену и ты её не заставишь рулить промышленным оборудованием.
> Чушь написал. Кроме проца -- там ещё и вачдогов пару стоит.Вачдог так то даже на многих x86 писюках можно завести, а уж на ARM/MIPS так на каждом первом практически.
> QNX сразу распознает подмену и ты её не заставишь рулить промышленным оборудованием.
Странно, у меня вообще на виртуалке с QEMU завелась и я ее жэсточайше развел прицепив мой софт на компорт и прикинувшись "ее" промышленной железкой. А оно мной, типа, рулит соответственно. Это я логику ее работы и протокол изучал. После чего я естественно запилил свой "compat"/"emulator" этого самого.
Тебя никто не заставляет использовать виртуальную память. Хотя сабж конечно же её использует и не является системой жесткого реального времени.
> Тебя никто не заставляет использовать виртуальную память. Хотя сабж конечно же её
> использует и не является системой жесткого реального времени.Вообще ядро можно собрать и без оверкомита, и без виртуальной памяти если оно вам надо.
Всё-равно это не будет хард реал тайм фор индастри продакшн реди.
> Всё-равно это не будет хард реал тайм фор индастри продакшн реди.Современные RT_LINUX патчи уже довольно близки к точке когда Linux сможет быть довольно правдоподобным подобием RTOS. Но да, изначально он для этого не создавался, поэтому идет довольно тяжело и медленно а результат похуже более специфичных продуктов. Однако повыпереть VxWorks какой и тому подобное из ряда мест он явно в состоянии будет.
Начал или вернул то что было изначально, но потом выкинули как "ненужное"? :)
Реально это очень полезное начинание.
Тут вопрос не во времени реакции как таковом, а в его предсказуемости.Штатный линукс запросто может миллиард пакетов обработать без задержек, а потом выдать задержку на 100-200 миллисекунд.
Холивары по поводу "реальное время это микросекунды или миллисекунды" бессмысленны, так как в каждой задаче - свои требования для реального времени.
Я видел систему реального времени с ограничением по реальному времени - 4 секунды для максимальной задержки обработки событий.С данными патчами, линукс можно стабильно применять там, где "реальность" времени измеряется десятками миллисекунд.
Микросекунд, уважаемый, микросекунд. Причем не десятков, а единиц. 100 кгц частота прерываний достигается обычным компом из магазина за углом.
> Микросекунд, уважаемый, микросекунд. Причем не десятков, а единиц. 100 кгц частота прерываний
> достигается обычным компом из магазина за углом.Понимаешь, 100кГц прерываний - это прекрасно но... но... вопрос в том насколько это стабильно и гарантировано. Вот смотри, допустим есть сигнал, с битами 100 000 раз в секунду. Его другая система шлет. Ты будешь всегда попадать в нужный бит чтобы его поймать или синтезировать?
А для понимания разницы даже несчастные аттини делают ПРОГРАММНО поток 1.5 Мбита известный как low speed usb. И там нельзя погодить, если прощелкать пакет хост в конце концов обидится на таймауты ремоты и скинет девайс. Заметьте: полтора миллиона битов в секунду программно с жесткими таймингами. На мизерной копеечной фиговине. А вы негарантированными 100 000 кичитесь на здоровом ящике. Все познается в сравнении. И вас в 15 раз делает тинька копеечная.
и сколько времени решает ваша тинька, например, квадратное уравнение? как там у нее с числами с плавающей запятой - какова разрядность/скорострельность?
> и сколько времени решает ваша тинька, например, квадратное уравнение?Вполне может быть что и дольше чем гроб на гигагерцах, особенно если это надо оптом и много а не 1 раз. Если 1 раз - там вариантв возможны, вплоть до хардкода ответов для ограниченного диапазона в таблицу, тогда скорость решений может быть довольно неплохой :). А вы думали мкшникии всегла честно считают какой-нибудь синус? Ага, ща. И да, какой-нибудь SRAM там может быть на частоте ядра и лукап мало того что быстрый так еще за ПРЕДСКАЗУЕМОЕ время. Ну вот например считается у вас это за 5 тактов - и баста. И ответ всегда есть за вот именно 5 именно этих юнитов времени. А у вас?
> как там у нее с числами с плавающей запятой - какова разрядность/скорострельность?
Там с этим разумеется швах, чудес не бывает. Это минимальный 8-битный примитивный чип, оптимизированный на вот именно управляющие задачи, предсказуемость и время реакции. Это не лучший инструмент для ворочания сложной математики и уж тем более плавучки. Там ROM так то мизер, но вы же понимаете что есть "высшая нервная деятельность" а есть "базовые рефлексы". Когда вы отдергиваете руку от огня вы ж не задумываетесь о том что ее надо отдернуть. Вы просто отдергиваете ее. Потому что если вы будете раздумывать - клешня пожарится. Ну вот мк ближе к этому уровню. Предлагаете позволить большому мозгу насладиться всеми прелестями жарки клешни, не снабдив его условными рефлексами? И вот это "отдергивание клешни" очень кстати в всяких опасных, жестко реалтаймных и тому подобных вещах так то, когда система гарантировано и быстро реагирует на тот или иной процесс :)
На таких системах вычисления не проводят. Все контрольные значения просчитаны заранее и зашиты намертво.
Дело не в скорости. Дело в гарантиях времени. И Линукс их дать не может.
А таки сабжевые патчи довольно сильно это дело лечат. В том числе и по части вот именно шедулинга процессов допустим. Когда речь уже идет что на сегменте X задача _гарантировано_ получит не менее Y времени, и все такое.Думаю мало кто будет спорить что обычным ос общего назначения ТАКИЕ заморочки не требуются и тут мы уже говорим по RTOS-specific вещи. Сабжевые патчи это обыгрывают.
Нет. Требования к реальному времени в каждом приложении разные. В железках на заводе -- общее требование 1мс. Шиндошс даёт девиацию от 4 до 20 мм. Линукс, теоретически, с таким ядром мог бы подойти. Но нет, потому что Линукс не сертифицирован для промышленного применения.
А скажем, для голосовой массовой связи -- норм. Но опять же: не в службах спасения или телеуправления.
По хорошему для системы реального времени надо считать такты процессора. Но как только тебе нужна хоть какая-то многозадачность там начинаются очень большие ньюансы.
Такты в современных процессорах штука весьма условная
Ну да нужны ещё правильны процессоры с правильными тактами это определенно не помешает.
> Ну да нужны ещё правильны процессоры с правильными тактами это определенно не помешает.А называется это "микроконтроллер". И производится миллиардами. То что их не очень сильно видно не означает что их нет. На них все и держится. Ну как, открывая кран вы же не задумываетесь что где-то трубы, где-то насосы, где-то трансформатор для этого насоса и провода...
> Такты в современных процессорах штука весьма условнаяПоэтому есть такие штуки как микроконтроллеры. Это иногда позволяет очень странную магию. Ну вот для AVR все потактово просчитали и смогли USB low speed 1.5 мбита в софте ворочать. У них не было usb изначально - но его программно сделали. В очень жестком реальном времени разгребая и создавая довольно быстрый в общем то сигнал. Полтора миллиона раз в секунду лапками осмысленно и правильно дергать - без возможности подождать (протокол нарушится, пакет побьется) - это нормальный такой квест за реалтаймом. И настоящие мастера реалтайма могут и вот так.
И по этой причине даже у ARM есть например Cortex M0/M3 - без жирных кешей, спекулятивности и проч. Так что если стало сильно надо - можно хучшие времена реакции с именно точностью до вот именно тактов системного клока просчитать. Чем навороченнее система тем это сложнее разумеется, поэтому простые ядра там и в фаворе. Скажем для совсем критичных применений STMicro сертифицировал в основном свои чипы на M0+. Они проще всего и поэтому предсказуемее всего.
задумался, сколько занимает процессорного времени современная ОС в смартфоне - ужаснулся
Сейчас, не понимающие что такое операционная система реального времени эксперты, будут рассказывать почему rt патчи не нужны или наоборот как они играть в игры и слушать музыку помогут.
А они реально не могут помочь?
Для самоделок поможет. Для производства -- нет.
> Для самоделок поможет. Для производства -- нет.не болтайте ерундой
https://support.industry.siemens.com/cs/document/109766374/s...
Да, даже до сименса дошло, в отличие от местных слоупоков :). Но опеннетчики заедут в HP со своим принтером а в сименс - своим ПЛК. Поучить их делать это :)
> Но опеннетчики заедут в HP со своим принтеромшильдик там свой будет, а принтер китайский с Linux
>> Для самоделок поможет. Для производства -- нет.
> не болтайте ерундой
> https://support.industry.siemens.com/cs/document/109766374/s...А теперь сами почитайте, что это за железо, и чем оно отличается от китайского ширпотреба. И заодно попробуйте ответить себе почему такой ценник. И почему такие ящики -- не продаются в ближайшем хозмаге. И в дальнем тоже.
И обратите своё внимание: ДЛЯ ЧЕГО используются эти ящики.> Support for further SIMATIC IPCs and PROFINET will soon be provided.
Вам рассказать, для чего Сименсу там поддержка PROFINET или сами догадаетесь?
> что это за железопромышленный ПК
> чем оно отличается от китайского ширпотреба
гарантированными характеристиками
> ДЛЯ ЧЕГО используются эти ящики
для промышленных коммуникаций, очевидно
https://simatic-market.ru/catalog/Siemens-CA01/10021869/#100.../
> Для самоделок поможет. Для производства -- нет.
так в итоге - сименс самоделки делает или вы просто обделались ?
> Вам рассказать, для чего Сименсу там поддержка PROFINET или сами догадаетесь?А вон там в кернеле не так давно запилили интересный такой эзернет, если 2 интерфейса есть, можно 2 кольца собрать. Пакет пуляется сразу в оба. Даже если 1 кольцо перебито, данные продолжают летать, латенси файловера равна нулю. А комитер чудной фичи, так то, Эйрбас.
В общем пока господа лечат как линукс не пожходит, Маск летает на нем в космос, корпы с мировыми именами видимо, вот, в самолеты ставят, и все такое.
я не понял - они какие-то там пакеты предоставили или само риилтайм ядро выкатили?
Собрали в виде rt и засунули в пакет.
> Собрали в виде rt и засунули в пакет.Патчи RT_LINUX применили и опакетили. Это несколько больше чем "собрали в виде".
Реалтаймовые патчи под линукс лезут так глубоко в ядро, что их невозможно накатить на произвольную версию ядра. Эти патчи пилятся под конкретное ядро, причем не последней свежести (потому что не угнаться). Видимо убунта допилила патчи под конкретное ядро для своего lts дистрибутива. Разумное решение - так они охватывают дополнительный кусок рынка.
Почему бы, не перейти на частичный ролинг релиз, или на другие виды ролинг релизов?
Потому что никакой вменяемый производитель таким пользоваться не будет.
> Почему бы, не перейти на частичный ролинг релиз, или на другие виды ролинг релизов?И что это даст кроме головняка? Для тех кто это хотел арчик есть но там система умеет делать себе харакири если не повезет.
Зачем? VxWorks и QNX же есть.
Платно, дорого, проприетарно.
Мне бесплатно диск по почте выслали.
> Зачем? VxWorks и QNX же есть.Условия у этих господарей дикие а фичность в пролете.
Потому что для моей поделки на малинке:
1) Я не смогу поставить QNX
2) В моей штучной подделке мне нужны гарантии. Если моя машинка весом 850 гр уткнётся в забор -- никто не пострадает.
Как говорил товарищ Ленин. Учится, учится и ещё раз учится!
> Потому что для моей поделки на малинке:
> 1) Я не смогу поставить QNX
> 2) В моей штучной подделке мне нужны гарантии. Если моя машинка весом
> 850 гр уткнётся в забор -- никто не пострадает.Ну вообще Маск так то на орбиту летает с x86 и линуксом. Другое дело что во первых он в состоянии нанять нормальных инженеров. Во вторых там не только x86... В третьих там более 1 компьютера параллельно работают.
Марсоход по Марсу с VxWorks ходит.
> Марсоход по Марсу с VxWorks ходит.Ну а Space Dragon, вот, линуксом обошелся. Так что Vx будут ждать веселые времена с потерей дофига рыночной доли в их сегменте.
А есть еще куча смежных сегментов. Ну вон модемчики сотовые. На апп ядре линух для "ui" (at commands, usb, CDC-ACM/CDC-Ether, webpage, ... ) и прочего. На cell modem ядре - Vx т.к. там часть протокола GSM и реалтайм жмет. Как вы думаете кто скоро лишится этих кастомеров? Почему-то мне кажется что уж туда реалтам-линукс затолкают влет. Да и что самое плохое в модеме может случиться? Потеряет пару пакетов раз в час? Это переживаемо накрайняк, а заодно как раз обладатели жабы оттестят грабли на не очень критичных системках.
> Ну вообще Маск так то на орбиту летает с x86 и линуксом.чтобы твитнуть с низкой орбиты, а вообще нет - микросхемы для космоса специальные делают, например QML-V вариант atmegas128 для копеечной atmega стоит $3000
> чтобы твитнуть с низкой орбиты,С бортовых компьютеров космических кораблей твиты таки не пишут. Не для этого они.
> а вообще нет - микросхемы для космоса специальные делают,
Что - нет? Вот прямо тут на опеннете была новость про то что, как и где в SpaceDragon.
> например QML-V вариант atmegas128 для копеечной atmega стоит $3000
Правда у вон того - кроме x86 есть и ряд микроконтроллерных штук, резервирование, а морда на хроме подперта хардварными кнопками "на всякий". Но вообще надежные системы можно делать и из не идеально надежных элементов.
А именно space grade актуально скорее спутникам, особенно тем, которые болтаются на орбитах с ломовым уровнем радиации (орбиты в этом плане разные бывают). Там commodity железу придется тяжко, конечно, и туда его не отправляют надолго висеть, спутник помрет.
> Что - нет? Вот прямо тут на опеннете была новость про то что, как и где в SpaceDragon.в статье есть неувязка
https://www.zdnet.com/article/from-earth-to-orbit-with-linux.../
они вначале пишут что бортовой компьютер это обычные x86, но потом
> Because the first stage of the Falcon 9 lands itself, its chips don't need to be radiation hardened.
вопрос - а на чём работает то что в настоящий космос улетает ? Про полёты на луну или марс и говорить нечего - там нет ионной оболочки и магнитоного поля земли.
> в статье есть неувязка
> они вначале пишут что бортовой компьютер это обычные x86, но потомНичему не противоречит. Сильная защита от радиации актуальна тому что в космосе надолго остается, особенно - некоторым спутникам которые на специфичных орбитах, где магнитное поле Земли их не защищает от потоков частиц от солнца, вот там - жестко, да. На земной орбите есть некоторые особо неудачные места.
> вопрос - а на чём работает то что в настоящий космос улетает
Настоящим космосом считается все что выше 100 километров. У амеров даже 80. Но так то марсолетик ingenuity на квалкоме, кажется, обычном, на марсе рассекал. И если он помрет то скорее от кончины акума работающего в жестких режимах, или типа того имхо. Летать чем-то типа квадрика в разреженной атмосфере все же тяжко.
> ? Про полёты на луну или марс и говорить нечего -
> там нет ионной оболочки и магнитоного поля земли.А вот вертолетик Ingenuity таки на квалкоме кажется собрали. Правда он и не расчитан на особо долговременную жизню, не думаю что у него батарейка долго протянет в режимах потребных для полетов в редкой атмосфере.
> Ничему не противоречит.как не противоречит если они пишут что не знают на чём работает часть ракеты находящаяся в космосе
> We don't know, however, what chips the Falcon 9 uses.
> Of course, while those ancient chips work for the station's command and control multiplexer demultiplexer (C&C MDM), they're not much good for anything else. For ordinary day-in and day-out work, astronauts use HP ZBook 15s running Debian Linux, Scientific Linux, and Windows 10.в космосе обычные x86 только твитнуть с ноута и на возвращаемой первой ступени, это нифига не бортовой компьютер
> Но так то марсолетик ingenuity на квалкоме, кажется, обычном, на марсе рассекал.
опять инфа из заголовка статьи ? там как в анекдоте - в ж.пу засовывают один палец а облизывают другой
> Правда он и не расчитан на особо долговременную жизню
что значит не расчитан ? подозреваю что стоимость доcтавки даже пары килограмм на марс на порядки превышает цены микросхем space grade
> как не противоречит если они пишут что не знают на чём работает
> часть ракеты находящаяся в космосеТем не менее, x86 с линухом летает в космос. Как бортовой компьютер. Соответственно так можно было. А то что у каждого решения есть свои лимиты, границы применимости, целесообразности и tradeoffs - ну надо же, какая неожиданность. И теперь Linux это один из инструментов в этой палитре. Такая ерунда.
> в космосе обычные x86 только твитнуть с ноута и на возвращаемой первой
> ступени, это нифига не бортовой компьютерДаже тут была новость про это и там явно сказано что несколько бортовых компьютеров именно рулят. И это x86 с линухом. Правда, с резервированием, а по пути еще микроконтроллеры. И нет, с бортовых компьютеров в твиттер не чирикают.
Более того - глядя на то как эйрбас специфичный диалект кольцованого эзернета через 2 интерфейса с 0 временем файловера комитнул в линух я подозреваю что это им тоже не для бортовой развлекательной системы надо было.
> опять инфа из заголовка статьи ?
Опять же в тушке статьи неплохое инфо о железе было. А также о челенджах специфичных для именно марса - дубак и тощая атмосфера.
> что значит не расчитан ?
То и значит - это такой себе эксперимент. Бонусный. Сколько проработает, столько и проработает. Его вообще делали чуть не студни. Как раз посмотреть как более-менее обычные земные технологии там себя поведут, видимо. Это тоже некое знание.
> подозреваю что стоимость доcтавки даже пары килограмм
> на марс на порядки превышает цены микросхем space gradeНе поможет - space grade акумуляторы не сильно лучше земных. А чтобы оно взлететь смогло это всяко LiIon должен быть, остальное слишком тяжелое и мало энергии. Ну а сколько литийион протянет в крайне жестких режимах характерных для коптеров? Ну явно не десятилетия. Тем более что там атмосфера тощая и летать еще сложнее, да еще заряжаться надо от солнца которого там так то меньше чем на земле. И никакие космические микросхемы не отменят что это нахальный эксперимент "на грани". Посмотреть прокатит ли вообще. Кстати прокатило и оно уже несколько раз летало такое красивое. Не следил живое ли оно до сих пор - но там такие соотношения что десятилетия оно не проживет в виде способном к полету, более одноразово чем сам марсоход сделано. И видимо изучение границ применимости земных технологий и их проблем часть плана. Если марс серьезно заселять это надо знать.
> Тем не менее, x86 с линухом летает в космос. Как бортовой компьютер.ISA там наверно x86 - бортовые компьютеры МКС и без Маска на ней давно работают, больше интересовала реализация - процессоры явно не из ближайшего маркета. Резервирование всегда было основным методом повышения надёжности так что Linux используют не только в космосе. Дешевле и надёжней несколько обычных резервных систем иметь чем одну с космической ценой :)
Зачем оно Убунту? ОС с режимом реального времени нужен только в промышленности.
Та не, я давно с РТ патчами юзаю ядро. Игрухи как бы проворнее говорили будут. Ведьмак3 норм был. Остальные хз,но вероятно также.D
> Та не, я давно с РТ патчами юзаю ядро. Игрухи как бы
> проворнее говорили будут. Ведьмак3 норм был. Остальные хз,но вероятно также.DТы скорее "low latency" ядро используешь. Зафиг тебе с твоим ведьмаком RT_LINUX с гарантиями выполнения для реалтаймных задач, право? Это не твой уровень.
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_RT_BASE=y
CONFIG_HAVE_PREEMPT_LAZY=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT__LL is not set
CONFIG_PREEMPT_RTB=y
# CONFIG_PREEMPT_RT_FULL is not set
CONFIG_PREEMPT_COUNT=y#
# CPU/Task time and stats accounting
Это кернел какой версии? А то примерно в 6.1...6.2 чтоли заметную часть RT_LINUX втянули в майнлайн, понимание что есть PREEMPT_RT поменялось. Теперь там это как-то так стало:
│ -> General setup │
│ (1) -> Preemption Model (<choice> [=y]) │
│ -> Fully Preemptible Kernel (Real-Time) (PREEMPT_RT [=n]) │
И вот именно там, именно это, на именно десктопе - уже спорное решение, потому что активация вот этого вот приводит к...
1) Доступности довольно специфичных режимов шедулинга задач, "как RTOS", когда можно гарантировать что на окне X миллисекунд вон та задача получит никак не менее Y хоть там что. Это очень круто - но на десктопе нафиг не уперлось в вот именно таком виде, вы ж не собираетесь кодить управляющий сервис которому реалтайм приоритет с гарантиями развешивать, и это на обычный десктоп, да?!
2) Вырубанию или обрубанию всех фич которые могут всему этому как-то мешать.Это все прекрасно но во первых создает уже достаточно измеримый оверхед в шедулере. Во вторых достаточно агрессиыно вырубает неожиданные вещи, вплоть до того что оно в какой-то из версий совсем dmesg могло отключать с аргументом "может сорвать гарантии реалтаймности". Реально может в специфичных случаях. Но это касается только парочки последних ядер веток 6.х.
Даже в самом последнем майнлайне сабжевые патчи еще НЕ ассимилировали ЦЕЛИКОМ, в вот именно основную кодовую базу. Даже в 6.2-rc7 еще не ВСЕ патчи. И вот тут клювом клацать не стоит. Ядро линукс не мировая константа а заученные раз ритуалы не гарантия что завтра будет как вчера. Вон то теперь чуть другое может означать чем раньще. С довольно заметным изменением свойств.
p.s. Кстати NO_HZ_FULL ничем таким не плох. Хотя там тоже нюансы. Наиболее очевидные факапы так то в хелпе к фиче написаны обычно.
gentoo-sources-4.19.271. + Патчи РТ с сайта РТ ,там для разных веток ядра есть. Раньше 4.9 использовал,но его перестали поддерживать, минимальная 4.14 на кернел архив теперь.
Да,обычный десктоп.
> gentoo-sources-4.19.271. + Патчи РТ с сайта РТ ,Блин, вот тут я не помню как там такое комбо выглядит, у меня менее 6.x нету ничего уже даже на винтажном хардваре. Там из-за интеграции в майнлайн части патчей, конфиг PREEMPT_RT поменял смысл. На декстопе патчи для именно вот жесткого реалтайма - а зачем? Там хватит обычного "full preempt" кернела имхо.
> там для разных веток ядра есть. Раньше 4.9 использовал,но его перестали
> поддерживать, минимальная 4.14 на кернел архив теперь.Не особо понимаю смысл возиться с древними ядрами. В новых так то еще есть всякие полезные вещи есть типа MGLRU и иных твиков всяких вещей типа страничной памяти. Это с другого бока полезно.
А вон тот реалтайм имеет смысл для тех кто готов заморочиться всерьез. Как то - серьезно просчитать доступное в системе время процессора, прописать КРИТИЧНЫМ процессам ГАРАНТИИ реалтаймного шедулинга. И вот так реалтайм уже не звучит пустым звуком. Но это достаточно продвинутые заморочки, актуальные для "управляющих систем" которые рулят/мониторят какие-то real world процессы, возможно опасные и чувствительные к отказам этого, там имеет смысл этим всем заняться вплотную. На обычном десктопе это несколько перебор, чтоли. Особенно учитывая что такие продвинутости в шедулере процессов уже идут все же с довольно измеримым оверхедом когда ему там надо довольно плотно трекать состояние всех процессов и кому сколько времени отсыпали чтобы реально обеспечивать вон те гарантии а не только вещать про реальное время.
У меня Вайн хреново работает с ядром выше 4.19. На 5х уже видны проблемы. Когда играть начинаешь,то все быстрее чем на ядре 4х,но через некоторое время фризит и после отпускает - снова быстро. Очень неприятно особенно в напряженные моменты. В тоже время я давно уже не сравнивал производительность игр на ядре с РТ патчами и без. Когда-то давно,во времена третьего Ведьмака по ощущениям профит был,так с тех пор и использую. D
Звук записывать, например
Я перечитал коментарии о нужности реалтайма для линукса и не нашёл ни одного упоминания про звук и звукозапись.
Это потому что ты не очень умный и не умеешь читать. https://www.opennet.dev/openforum/vsluhforumID3/129771.html#8
к жесткому реалтайму rt патчи имеют слабое отношение - мало того что дают милисекундные пределы, так еще допускают ситуацию где любой железячный драйвер может запретить прерывания на неопределенное время. и получим spikes в +- 100ms. давно есть пару более надежных решени, мне еще в 90-ых удавалось получить +-10микросекунд на железе аля пентуим-I, ядро 2.6 правда было ;)
> допускают ситуацию где любой железячный драйвер может запретить прерывания на неопределенное времянет, подучите матчасть
▶ All interrupt handlers are threaded, except for a few that explicitely need hard irq
• This is the case for drivers involved in interrupt dispatching
• cpufreq and cpuidle drivers too
▶ If you find a kernel-side unbounded latency, this is a bug
мдя, "threaded" не имеет отношения к disabled. иди пиши дальше на basic
> "threaded" не имеет отношения к disableимеет прямое отношение - во время обработки threaded isr прерывания разрешены, запрещены они только на время работы кода диспетчера аппаратных прерываний, а любой поток с меньшим приоритетом может быть вытеснен более приоритетным в любое время, даже на спинлоке
▶ With PREEMPT_RT, spinlock_t and rwlock_t will become sleeping locks
иди матчасть учи, любитель басиков
> мдя, "threaded" не имеет отношения к disabled.Попробуй патчи почитать. Или хотя-бы их описание, нуб. Ты случайно не тот же кадр который в кикаде хотел дорожки под 90 градусов? Или просто похожий по тормозизму? :)
> к жесткому реалтайму rt патчи имеют слабое отношение - мало того что
> дают милисекундные пределы, так еще допускают ситуацию где любой железячный драйвер
> может запретить прерывания на неопределенное время.RTFM, нуб. Там как раз это все обыгрывается. И много чего еще.
в твоем ответе обыгрывается только полное отсутствие понимания rt и 0 созданных приложений. походу ты потратил все время на чтение док, но не в коня корм
> в твоем ответе обыгрывается только полное отсутствие понимания rt и 0 созданных
> приложений. походу ты потратил все время на чтение док, но не в коня кормВ отличие от тебя я могу еще и патчи посмотреть и осознать что с threaded IRQ как раз идея в том что дрова теперь не могут IRQ надолго вырубать, ага. Это тоже не бесплатно по оверхеду но если надо вот именно реалтайм, с какими-то гарантиями - тут уж извините, придется кой-чем пожертвовать.