Comments 81
Какая шикарная статья! Спасибо большое. Надо понимать, что ОСРВ не обязательно будет работать быстрее и отзывчивее, чем обычная! Это говорит о том, что приложения будут получать более чёткий приоретет и более контролируемое время срабатывания.
Так что, если вы думаете ускорить свою ОС, делая её ОСРВ, то я вас разочарую. Надо очень чётко понимать зачем это вам нужно!
Так что, если вы думаете ускорить свою ОС, делая её ОСРВ, то я вас разочарую. Надо очень чётко понимать зачем это вам нужно!
Смысл статьи сводится к тому, чтобы объяснить, что Real Time Red Hat Enterprise Linux это всего лишь маркетинг? И написанному на упаковке верить нельзя?
Корпоративный блог RUVDS… Чего тут только нет…
По сути вопроса — если что-то выглядит как мышеловка, и там лежит вкусный сыр — значит почти наверняка мышеловка и есть. И лучше оттуда бежать со всех ног. Вот ровно таким образом стоит включать режим повышенного внимания всякий раз, как в тексте встречаются упоминания про «реальное время» и практически всегда бежать со всех ног, как только встречается уточнение «жесткое реальное время». В 99% случаев это будет ничего не значащий маркетинг.
По сути простая логика — гарантированное время в системе возможно лишь при условии интенсивности событий не превышающих некоторую заданную планку. Т.е. по сути единственное требование к системам реального времени — это требование не терять события на пустом месте. А дальше вопрос веры… Веры в то, что конкретно взятая система это умеет. Ну, и четкие значения порогов, после которых уже «не умеет».
По сути вопроса — если что-то выглядит как мышеловка, и там лежит вкусный сыр — значит почти наверняка мышеловка и есть. И лучше оттуда бежать со всех ног. Вот ровно таким образом стоит включать режим повышенного внимания всякий раз, как в тексте встречаются упоминания про «реальное время» и практически всегда бежать со всех ног, как только встречается уточнение «жесткое реальное время». В 99% случаев это будет ничего не значащий маркетинг.
По сути простая логика — гарантированное время в системе возможно лишь при условии интенсивности событий не превышающих некоторую заданную планку. Т.е. по сути единственное требование к системам реального времени — это требование не терять события на пустом месте. А дальше вопрос веры… Веры в то, что конкретно взятая система это умеет. Ну, и четкие значения порогов, после которых уже «не умеет».
К сути вопроса, linux не является ОСРВ. Его можно придвинуть максимально, для каких-то локальных задач, чётко понимая что будет. Опять же будет определять загруженность системы. Какая-нибудь легковесная Buildroot сборка с initd, либо systemd с кучей ненужных сервисов, будет иметь различную отзывчивость при одних и тех же настройках и сборке ядра.
Лично я развлекался тем, что пытался делать очень жёсткие тайминги на пине. И удалось добиться только на жёстком прерывании, и то с большим трудом.
Лично я развлекался тем, что пытался делать очень жёсткие тайминги на пине. И удалось добиться только на жёстком прерывании, и то с большим трудом.
Согласен.
Впрочем, если сказать что события будут гарантированно не чаще, чем один раз в день, и отреагировать на них надо не медленнее, чем за один час — то вжух — и любой Linux на любой малопроизводительной железке становится системой реального времени.
Но опять — если мы верим, что по каким-то причинам Linux где-то у себя не «похоронит» событие. Причины? Ну, например, внеплановая перезагрузка по причине возросшей энтропии или съеденная память «кривым» прикладным софтом.
Отчасти поэтому, все, что требует быстрой и надежной реакции на внешние раздражители до сих пор пишется на «небезопасном» языке C и работает прямо по железу. Полагаю, что именно такой расклад сохранится еще довольно продолжительное время.
Впрочем, уж Вам-то я об этом точно рассказывать не должен. В любом случае спасибо за уточнение. Действительно, добиться от Linux стабильного времени реакции на события в интервале в единицы миллисекунд — та еще задача. Впрочем, именно ее и пытается решить RT RHEL. Но только ее, и ничего больше.
Впрочем, если сказать что события будут гарантированно не чаще, чем один раз в день, и отреагировать на них надо не медленнее, чем за один час — то вжух — и любой Linux на любой малопроизводительной железке становится системой реального времени.
Но опять — если мы верим, что по каким-то причинам Linux где-то у себя не «похоронит» событие. Причины? Ну, например, внеплановая перезагрузка по причине возросшей энтропии или съеденная память «кривым» прикладным софтом.
Отчасти поэтому, все, что требует быстрой и надежной реакции на внешние раздражители до сих пор пишется на «небезопасном» языке C и работает прямо по железу. Полагаю, что именно такой расклад сохранится еще довольно продолжительное время.
Впрочем, уж Вам-то я об этом точно рассказывать не должен. В любом случае спасибо за уточнение. Действительно, добиться от Linux стабильного времени реакции на события в интервале в единицы миллисекунд — та еще задача. Впрочем, именно ее и пытается решить RT RHEL. Но только ее, и ничего больше.
Действительно, добиться от Linux стабильного времени реакции на события в интервале в единицы миллисекунд — та еще задача. Впрочем, именно ее и пытается решить RT RHEL. Но только ее, и ничего больше.
Вы не поверите, но решение этой задачи — это ахренеть как важно и нужно, на определённых задачах. ОСРВ, как правило нужно на встраиваемых системах, где достаточно точно известно какое ПО будет установлено и за прикладной софт будет. Даже перезагрузка (что в общем-то нештатная ситуация), может быть предсказуемой.
Вы не поверите...
Почему не поверю? Очень даже поверю. «раз звезды зажигаются, значит это кому-то нужно» (с)
Другое дело, что я до последнего буду биться за то, чтоб все, что требует миллисекундных (и меньше) реакций накрывалось отдельным контроллером или CPLD. Использование в таких проектах Linux (пусть и припиской RT)… Персонально мне не нравится. И сдвинуть меня с этой позиции можно только административными методами (т.е. прямым приказом — делаем только на Linux). И то, скорее всего я подстелю соломки и проработаю альтернативный вариант.
«Фиксированный набор софта» мы проходили. Котеночек всегда растет. И то, что сегодня кажется нерушимым как скала, завтра может оказаться песочком. Впрочем, верю — бывает и по другому. Просто мне не попадалось.
спользование в таких проектах Linux (пусть и припиской RT)… Персонально мне не нравится. И сдвинуть меня с этой позиции можно только административными методами (т.е. прямым приказом — делаем только на Linux). И то, скорее всего я подстелю соломки и проработаю альтернативный вариант.
Я частично с вами солидарен, так как linux не является ОСРВ. Но бывает так, что дешевле хоть как-то сделать linux похожей на ОСРВ, чем переписать софт под другое аппаратно-программное решение.
У меня есть успешный опыт использования линукса с Xenomai с тактом прикладного софта в 50 микросекунд и rt_preempt с прикладным софтом на 100 микросекунд. На x86, арме, мипсе, fpga, и прочих сволочах. Нормально справляется, если правильно приготовить.
Правильно приготовить… Ответственный повар не будет испытывать новое блюдо в случае необходимости накормить толпу условных шахтеров. Каким бы вкусным оно не было. Предпочтение будет отдано не самым вкусным, но вполне сытным блюдам, которые уже отработаны. Потому и говорю — сугубо административными методами.
Я эпизодически посматриваю в сторону RT Linux. Местами пробую (то, что доступно). Но результат мне не нравится. Возможно, да — дело в том, что «готовить не умею». А может потому что слишком испорчен низкоуровневыми решениями.
Но в целом, про MIPS и 50 микросекунд я бы почитал. Крайне интересно где здесь будет граница и есть ли в этом смысл. И по деньгам (цене системы) в том числе.
Я эпизодически посматриваю в сторону RT Linux. Местами пробую (то, что доступно). Но результат мне не нравится. Возможно, да — дело в том, что «готовить не умею». А может потому что слишком испорчен низкоуровневыми решениями.
Но в целом, про MIPS и 50 микросекунд я бы почитал. Крайне интересно где здесь будет граница и есть ли в этом смысл. И по деньгам (цене системы) в том числе.
В любом случае ни одна система РВ не гарантирует хорошего результата. Хороший результат — ответственность разработчика всей системы. Т.е. без хорошего повара все равно не обойтись.
толпу условных шахтеров
какая связь? РТлинукс как правило требуется для частных случаев. Выражаясь вашим языком - для разовых клиентов.
И да, скорее всего вы "не умеете готовить"
"линукса с Xenomai с тактом прикладного софта в 50 микросекунд и rt_preempt с прикладным софтом на 100 микросекунд. "
Напишите пожалуйста об этом статейку!
Xenomai ещё может получить 50 микросекунд, потому что он блокирует другие прерывания, но rt_preempt не блокирует прерывания. К тому же обработка high resolution таймеров занимает много времени.
«Много» — это сколько, и что там может требовать много времени? В более-менее современном железе таймеры высокого разрешения как раз не создают заметных накладных расходов.
30 мкс было максимальное время для обработки таймеров высокого разрешения для E3940. При том, что любой rt поток даже низкого приоритета, который просыпается в то же время когда и поток высокого потока, добавляем время.
Любое прерывание хоть и «ничего не делает», только пробуждает рабочий поток занимает время (5-10 мкс) и блокирует поток реального времени с высоким приоритетом.
Любое прерывание хоть и «ничего не делает», только пробуждает рабочий поток занимает время (5-10 мкс) и блокирует поток реального времени с высоким приоритетом.
Что именно нужно «обработать» за эти 30 мкс? И откуда 5-10 мкс на обработку пустого прерывания?
Мы говорим и системе реального времени, которую тестируют под высокой нагрузкой и нас интересуют только максимальные значения времени. При большой нагрузке других ядер происходит промах мимо кэша.
Цифры я привёл не из воздуха а из реальных тестов.
Обработка таймера это обычно активация rt потока. Если в определённый момент времени нужно рабудить несколько потоков, то каждый нужно активировать, даже если приоритет низкий. Пустое прерывание это тоже активация потока.
Цифры я привёл не из воздуха а из реальных тестов.
Обработка таймера это обычно активация rt потока. Если в определённый момент времени нужно рабудить несколько потоков, то каждый нужно активировать, даже если приоритет низкий. Пустое прерывание это тоже активация потока.
"если сказать что события будут гарантированно не чаще, чем один раз в день, и отреагировать на них надо не медленнее, чем за один час — то вжух — и любой Linux на любой малопроизводительной железке становится системой реального времени." — это конечно популярное заблуждение.
"В подавляющем большинстве случаев, при нажатии на менюшку, иконку, кнопку, мы сразу увидим перерисовку экрана, если конечно все в порядке (интернет есть, процесс не завис и т.д.). А вот если случилось что-то непредвиденное, например, связь пропала, мы увидим, чем отличаются (должны отличаться) системы реального времени. Обычный смартфон мы просто перезагрузим. Но если эта система управляет электростанцией, то сами понимаете, такое не всегда возможно. Отсюда делаем вывод, что система реального времени должна предсказуемо, а не быстро, реагировать на любое событие или совокупность событий, вне зависимости от своего состояния и окружения. "
Да. Заблуждение говорите? А можете подтвердить документально что это именно заблуждение? Где есть такое определение системы реального времени?
Давайте посмотрим. И начнем, допустим, с той же Wiki (русский и английский). Там дается определение из Unix, которое практически один в один повторяет Posix'овское.
И чуть дальше объяснение того маркетинга, который отличает «жесткое» и «мягкое» реальное время.
Что характерно, в английской версии такого нет. И быть не может. Потому как реальная ОС РВ обеспечивает время в любых допустимых условиях. Все. Точка. Под любыми мы понимаем и наихудшие. А если в «тепличных» может, а в предельных нет — уже не ОС РВ (или границы, в которых она остается ОС РВ указаны неправильно).
Даже если мы немного уйдем от вычислительно-компьютерной тематики и избавимся от термина операционная — оставим только систему реального времени. Не будет там ничего, сильно отличающегося. Добавится пара уточняющих определений. Но не будет ничего, про то о чем пишите Вы.
Вот и получается, что заблуждение не у меня. У меня-то как раз все четко. Заблуждение у Вас. Система реального времени не синоним системы повышенной надежности, повышенной устойчивости или многократно резервируемой системы. И это как раз то, что нужно четко понимать.
Давайте посмотрим. И начнем, допустим, с той же Wiki (русский и английский). Там дается определение из Unix, которое практически один в один повторяет Posix'овское.
Реальное время в операционных системах — это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени.
Оригинальный текст (англ.)
Realtime in operating systems: the ability of the operating system to provide a required level of service in a bounded response time.
И чуть дальше объяснение того маркетинга, который отличает «жесткое» и «мягкое» реальное время.
Операционная система, которая может обеспечить требуемое время выполнения задачи реального времени даже в худших случаях, называется операционной системой жёсткого реального времени. Система, которая может обеспечить требуемое время выполнения задачи реального времени в среднем, называется операционной системой мягкого реального времени.
Что характерно, в английской версии такого нет. И быть не может. Потому как реальная ОС РВ обеспечивает время в любых допустимых условиях. Все. Точка. Под любыми мы понимаем и наихудшие. А если в «тепличных» может, а в предельных нет — уже не ОС РВ (или границы, в которых она остается ОС РВ указаны неправильно).
Даже если мы немного уйдем от вычислительно-компьютерной тематики и избавимся от термина операционная — оставим только систему реального времени. Не будет там ничего, сильно отличающегося. Добавится пара уточняющих определений. Но не будет ничего, про то о чем пишите Вы.
Вот и получается, что заблуждение не у меня. У меня-то как раз все четко. Заблуждение у Вас. Система реального времени не синоним системы повышенной надежности, повышенной устойчивости или многократно резервируемой системы. И это как раз то, что нужно четко понимать.
Выше я процитировал Антона Бондарева https://habr.com/ru/company/embox/blog/440390/
Приведенная мной цитата и Ваши цитаты с той же вики отлично дополняют друг друга. "если сказать что события будут гарантированно не чаще, чем один раз в день, и отреагировать на них надо не медленнее, чем за один час — то вжух — и любой Linux" — как раз таки нет, потому что отсутствует "способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени."
Я использую FreeRTOS много лет и могу привести пример оттуда, поясняющий слова Антона Бондарева. В FreeRTOS какую функцию не вызови, а последним параметром укажи максимальное время выполнения этой функции. Хочешь закинуть элемент в очередь — укажи сколько ОС будет пытаться его туда положить, и вернёт программисту код ошибки, если время превышено.
… как раз таки нет, потому что отсутствует «способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени.»
Подождите. Вы сомневаетесь в том, что Linux сможет уверенно обслуживать одно событие в сутки менее чем за один час? Я специально подбирал такие параметры, чтоб даже «за уши» притянуть возможность их неисполнения было невозможно. У тут есть все — и требуемый промежуток времени и требуемый уровень сервиса и гарантированная возможность его исполнить. Чем не ОСРВ при такой постановке задачи? Чему это противоречит?
Что до иконок и менюшек… Там тема в которую не очень хочется лезть. ОСРВ (к счастью) почти всегда не про менюшки и реакцию на пользовательский ввод. И даже не про USB (хотя бы потому что шина эта не гарантирует доставку). Просто некий культ, возведенный вокруг ОСРВ как некоторой мега крутой, мега надежной и самой правильной операционной системы… Он смешон. Нет, оно конечно: «Тем, кто любит сосиски и уважает закон, лучше не видеть, как делается то и другое.» (С) Бисмарк. Потому, может и хорошо что у окружающих есть такое ощущение. Значит мы свою работу делаем хорошо. Но поддерживать этот миф… Не знаю. Меня с детсва учили — обманывать не хорошо. Ничего с собой поделать не могу.
"Вы сомневаетесь в том, что Linux сможет уверенно обслуживать одно событие в сутки менее чем за один час?"
Да, сомневаюсь. Вы уверены, что у Вас есть опыт работы с RTOS для ведения дискуссии на эту тему?
Подождите. Вы сомневаетесь в том, что Linux сможет уверенно обслуживать одно событие в сутки менее чем за один час?
Говоря строгим языком — нет, немодифицированный Linux этого гарантировать не может. Нет гарантии что кто-то не захордил ресурс, нет гарантии что не случилось какой-нибудь ошибки приоритезации, нет гарантии что кто-нибудь не наспавнил бесконечных циклов, и прочее и прочее.
Операционки реального времени (включая пропатченный Linux) спроектированы чтобы это гарантировать.
И пространные словоблудия тут ни к чему, тут строго детерменированные понятия.
Каким образом пропатченный Linux гарантирует безопасное отбирание управления у ядерной компоненты, нарушающей установленные для ядра правила обращения с ресурсами, распределения приоритетов и т.п.?
А никто и не говорил про безопасно. Если процесс хочет ресурс навсегда, у него его тупо отбирают, при определенных конфигурациях тупо убивая.
Фактически, все РТ патчи для Линукса так или иначе патчат шедулер так, чтобы можно было запустить юзерспейс таску так, чтобы кернел не мог у нее неожиданно отнять ресурс, и чтобы каждый процесс, включая кернеловые, не мог захватить ресурс навсегда (но это уже конфижится, рт патчи по дефолту дают «мягкий» риалтайм).
Ну а если кто-то не справляется в отведенное окно, то это его личные половые трудности.
Фактически, все РТ патчи для Линукса так или иначе патчат шедулер так, чтобы можно было запустить юзерспейс таску так, чтобы кернел не мог у нее неожиданно отнять ресурс, и чтобы каждый процесс, включая кернеловые, не мог захватить ресурс навсегда (но это уже конфижится, рт патчи по дефолту дают «мягкий» риалтайм).
Ну а если кто-то не справляется в отведенное окно, то это его личные половые трудности.
Выглядит как-то очень странно. Для чего патчи запрещают отбирать время/ресурсы у пользовательского процесса, и для чего разрешают делать это с ядерными процессами? Похоже на костыли для очень кривого софта, который в user mode пытается делать то, что положено делать в kernel mode.
Это позволяет быть уверенным, что если у тебя есть окно, в него никто не влезет и не отнимет ресурс. Как и положено в риалтайм системе.
Это применяется там, где весь софт так или иначе критический, но хочется сохранить преимущества линукса, и не заставлять все подряд городить в кернел.
Это применяется там, где весь софт так или иначе критический, но хочется сохранить преимущества линукса, и не заставлять все подряд городить в кернел.
Так это решается простейшей системой приоритетов. Если поток получил квант, и сам его не отдал, то другой поток того же или более низкого приоритета никак его не отнимет.
А если речь о том, что управление о пользовательского потока не может отнять даже аппаратное прерывание, то это черт знает что, а не ОС, не говоря уже о РВ.
В ядро не нужно тащить все подряд. Там должно быть только необходимое. Так же, как и с отложенной обработкой прерываний: первичный обработчик делает только самый минимум по обслуживанию устройства, следующий этап выполняется в отложенном режиме на пониженном приоритете, и уже самое некритичное завершает пользовательский поток.
А если речь о том, что управление о пользовательского потока не может отнять даже аппаратное прерывание, то это черт знает что, а не ОС, не говоря уже о РВ.
В ядро не нужно тащить все подряд. Там должно быть только необходимое. Так же, как и с отложенной обработкой прерываний: первичный обработчик делает только самый минимум по обслуживанию устройства, следующий этап выполняется в отложенном режиме на пониженном приоритете, и уже самое некритичное завершает пользовательский поток.
Хорошо. Это уже аргумент. Я его принял.
Но все что я могу на него возразить — это просто заметить, что ангелы господни пока не пишут операционные системы реального времени. Потому непогрешимого и безбажного кода, гарантирующего чего бы то не было и исправляющего за одно аппаратные сбои в железе в реальном мире, нет и быть не может. Можно математически гарантировать гарантировать правильность кода. Это сложно, но возможно. Но даже это выверенный математически код не спасет от мусора на входе, или сбоев аппаратуры, или криво написанной соседней задачи с таким же приоритетом. Потому я еще раз повторю свою мысль — у любой ОСРВ есть границы применимости. Я ВСЕГДА смогу создать внешние условия, в которых она перестанет таковой быть.
А аргумент о том, что не модифицированный линукс настолько плох, что не обслужить (ГАРАНТИРОВАННО) единственного события в сутки, да за целый час с момента его возникновения и только потому что его обязательно загрузят кривым софтом, захватывающим ресурсы, косячащим в планировщике, и увешанным бесконечными циклами (о ужас, где же обещанная вытесняющая многозадачность в бедном Linux'е???) — это даже не смешно. В конце концов Linux сервера с солидным uptime'ом не редкость И заняты они не только потреблением электроэнергии.
Криво написанный софт любую ОСРВ превратит в тыкву. И любая (в меру протестированная) ОС до определенных условий способна гарантировать сервис за время. Иначе кому она вообще нужна. Что до ОСРВ как таковых, то основная область их применения это все же задачи, требующие минимального времени реакции на событие. Потому они так любят хвастаться гарантированным временем вызова обработчика прерывания. А только после этого идет речь о всем остальном. Поймите уже наконец — мы живем в реальном мире. А в реальном мире все не так хорошо, как об этом пишут в рекламных буклетах ОСРВ и рассказывают институтские преподаватели.
Но все что я могу на него возразить — это просто заметить, что ангелы господни пока не пишут операционные системы реального времени. Потому непогрешимого и безбажного кода, гарантирующего чего бы то не было и исправляющего за одно аппаратные сбои в железе в реальном мире, нет и быть не может. Можно математически гарантировать гарантировать правильность кода. Это сложно, но возможно. Но даже это выверенный математически код не спасет от мусора на входе, или сбоев аппаратуры, или криво написанной соседней задачи с таким же приоритетом. Потому я еще раз повторю свою мысль — у любой ОСРВ есть границы применимости. Я ВСЕГДА смогу создать внешние условия, в которых она перестанет таковой быть.
А аргумент о том, что не модифицированный линукс настолько плох, что не обслужить (ГАРАНТИРОВАННО) единственного события в сутки, да за целый час с момента его возникновения и только потому что его обязательно загрузят кривым софтом, захватывающим ресурсы, косячащим в планировщике, и увешанным бесконечными циклами (о ужас, где же обещанная вытесняющая многозадачность в бедном Linux'е???) — это даже не смешно. В конце концов Linux сервера с солидным uptime'ом не редкость И заняты они не только потреблением электроэнергии.
Криво написанный софт любую ОСРВ превратит в тыкву. И любая (в меру протестированная) ОС до определенных условий способна гарантировать сервис за время. Иначе кому она вообще нужна. Что до ОСРВ как таковых, то основная область их применения это все же задачи, требующие минимального времени реакции на событие. Потому они так любят хвастаться гарантированным временем вызова обработчика прерывания. А только после этого идет речь о всем остальном. Поймите уже наконец — мы живем в реальном мире. А в реальном мире все не так хорошо, как об этом пишут в рекламных буклетах ОСРВ и рассказывают институтские преподаватели.
Поэтому разумная ОС РВ должна иметь средства не только обеспечения времени реакции, но и контроля за поведением привилегированного софта (прежде всего сбор статистики о его работе). Вместо того, чтобы городить костыли, позволяющие в любой момент прервать выполнение любого драйвера, и требующие для этого введения множества ограничений, гораздо правильнее вовремя (то есть — на этапах разработки и тестирования) обнаруживать компоненты, ведущие себя некорректно, и исправлять их до того, как система пойдет в производство.
А в системах повышенной надежности с жестким RT, как правило, у критичных процессов вообще нет возможности захватывать произвольные блокировки — там на это жесткий регламент, чтобы исключить непредсказуемость.
А в системах повышенной надежности с жестким RT, как правило, у критичных процессов вообще нет возможности захватывать произвольные блокировки — там на это жесткий регламент, чтобы исключить непредсказуемость.
Ммм… А давайте скажем по другому. Ответственные системы должны проектировать, реализовывать и валидировать ответственные люди. И ОСРВ (в любой ее реинкарнации) лишь один из многих инструментов.
Ответственных задач очень много. Часть из них требует минимального времени, часть максимального распараллеливания работы, часть максимально надежного выполнения. Волшебной пилюли, сочетающей в себе все эти требования одновременно нет.
Вам, в ваших задачах, видимо сильно мешают блокировки. Мне — задержки. Кому-то другому может мешать что-то еще. Мир велик. Задач много. А отсюда главная мысль, которую я не устаю повторять — главное помнить граничные условия. Они есть всегда.
Ответственных задач очень много. Часть из них требует минимального времени, часть максимального распараллеливания работы, часть максимально надежного выполнения. Волшебной пилюли, сочетающей в себе все эти требования одновременно нет.
Вам, в ваших задачах, видимо сильно мешают блокировки. Мне — задержки. Кому-то другому может мешать что-то еще. Мир велик. Задач много. А отсюда главная мысль, которую я не устаю повторять — главное помнить граничные условия. Они есть всегда.
Ну так откуда берутся эти задержки? От нежелания выполняющегося кода своевременно освобождать ресурсы (хоть просто процессор, хоть захваченные блокировки). Для получения гарантий на РВ необходима регламентация такого поведения. Она есть в любой серьезной системе, но мало где есть адекватный контроль за соблюдением ограничений. С ядром Linux я практически незнаком, зато хорошо знаком с виндовым: ограничения на продолжительность операций были установлены еще в 80-е, но спустя почти сорок лет их регулярно нарушает сама MS. Подозреваю, что в Linux ситуация такая же. А если бы встроенные средства контроля Linux и Windows (а не сторонние примочки и костыли) обнаруживали все эти нарушения, и явно указывали бы на модули-нарушители, все это сложно было бы столько времени официально скрывать и по факту игнорировать.
rt_preempt или какой-нибудь Xenomai делает Linux очень даже жесткой ОСРВ. И вопрос тут не в отзывчивости как таковой, а в постоянстве времени выполнения таска и отсутствии resource hoarding.
Если значение словосочетания «Real Time» является чётко опредлённым термином, не означает ли это, что компания должна быть привлечена к ответственности за введение потребителей в заблуждение и намеренное искажение смысла слов, мешающее даже специалистам понимать друг друга?
может кто знает, а как работает ОС МСВС-РВ? у нее как бы в названии РВ?
Тут описан RT планировщик процессов. Он работает (внезапно!) с процессами и может влиять только на приоритеты процессов. В таких условиях реализовать требования работы в реальном времени крайне трудно, так как всякие обработчики прерываний могут прерывать процессы «реального времени», либо не давать им включаться. Этот планировщик уже более 10-и лет является стандартной частью ядра.
Более реальное «реальное время» реализовано в наборе патчей PREEMPT_RT, поддерживаемым Инго Молнаром сотоварищи. Там уже можно прерывать прерывания, критические секции, и т.п.
Более реальное «реальное время» реализовано в наборе патчей PREEMPT_RT, поддерживаемым Инго Молнаром сотоварищи. Там уже можно прерывать прерывания, критические секции, и т.п.
UFO just landed and posted this here
Чтобы такого не было, в ядре должна иметься возможность сбора статистики о том, сколько времени каждый модуль или компонент проводит в обработке прерываний, сколько времени удерживает глобальные ресурсы и т.п. В результате будут выявляться компоненты, которые крутят слишком много циклов, держат блокировки сверх разумной необходимости, неправильно распределяют нагрузку по высоко- и низкоприоритетным режимам. Тогда будет, что предъявить разработчикам компоненты. :)
сходиться к ln2 ≈ 0.693147
Для одного процессора. Для SMP ~33%, вай!
К слову, если кто соберется настраивать RT Linux, стоит много внимания обратить на тюнинг BIOS сервера — например у HPE есть большая инструкция про настройку Просто установка может не дать никаких результатов.
Наличие инструкции похвально. Хотя в ней ни слова, к примеру, об отключении интерфейса USB. Впрочем, полностью его отключить всё равно не удастся.
В общем и целом отключение различных подсистем управления энергопитанием и профилем работы сервера дает 90+% результата, на HPE отключение всех таких подсистем снизило задержки со 200 мкс до 8 мкс. На другом сервере где стоял «не умный» BIOS из коробки без настроек были такие же результаты. Насчет USB не уверен что даст ощутимое уменьшение задержек. Единственно, нашел здесь что желательно использовать PS/2 перифирию.
Ну да, похоже.
«Hint:
Hints for getting rid of SMI interrupts on x86
1. Use PS/2 mouse and keyboard,
2. Disable USB mouse and keyboard in BIOS, „
USB контроллер, в особенности нагруженный — самый простой способ увеличить задержки в системе.
С другой стороны, вряд-ли кто-то будет использовать сервер целиком для задач реального времени. У LabVIEW, например, есть Real-Time Module, работающий параллельно с основной ОС.
«Hint:
Hints for getting rid of SMI interrupts on x86
1. Use PS/2 mouse and keyboard,
2. Disable USB mouse and keyboard in BIOS, „
USB контроллер, в особенности нагруженный — самый простой способ увеличить задержки в системе.
С другой стороны, вряд-ли кто-то будет использовать сервер целиком для задач реального времени. У LabVIEW, например, есть Real-Time Module, работающий параллельно с основной ОС.
А я вот помню, был такой Linux реального времени, где было небольшое ядро РВ на Си и в этом ядре выполнялись задачи РВ, а линукс выполнялся как одна из задач ядра РВ. Свою задачу нужно было писать на Си, а линукс нужен был для разных интерфейсов. Общаться с Линуксом нужно было через пайпы.
Даже сбацал на нем небольшой проект лет наверное 20 с чем-то тому назад.
Даже сбацал на нем небольшой проект лет наверное 20 с чем-то тому назад.
Для систем реального времени есть очень важный параметр — время холодного и горячего старта. Для мк с + голое железо — это время почти всегда равно старту кварца. В грамотно спроектированной системе мк успевает выполнить большую часть подготовки до кварца, ну а после — уже полноценный рабочий режим.
Ну а с линуксом старт всегда классический, с логом в порт отладки, или даже на экран — минимум пару минут.
Красиво получается: надо тормозить, до столкновения пара секунд, скорость предельная…
А линуха решила перегрузиться…
Ну а с линуксом старт всегда классический, с логом в порт отладки, или даже на экран — минимум пару минут.
Красиво получается: надо тормозить, до столкновения пара секунд, скорость предельная…
А линуха решила перегрузиться…
В некоторых системах кварц вообще не используется, т.к. не требуется точный отсчёт времени, а хватает и приблизительного от RC-генератора. В таких системах время старта в основном зависит от программы — сколько усилий приложили разработчики, чтобы сократить необходимый объём инициализации.
Бывают ещё задержки на запуск ФАПЧ (PLL), они сопоставимы со временем на старт кварца.
Бывают ещё задержки на запуск ФАПЧ (PLL), они сопоставимы со временем на старт кварца.
Для мк с + голое железо — это время почти всегда равно старту кварца
Нифига. Нет, конечно, если у вас один МК уровня атмеги и там что-то типа цикла для стиральной машины, оно может так стартовать (разработчики, кстати, какого хрена моя стиралка выходит на готовность через 3 секунды?).
Но в реале, сначала дожидаемся переходных процессов в БП (легко секунда на мощных, если там что-то силовое питается), потому кварц и система тактирования (с 5 разными PLL в контроллере, ага), потом загрузчик проверяет чек-сумму, потом запуск RTOS и запуск процессов в ней, инициализация/проверка внешней памяти, загрузка в оперативку чего-то, потом инициализации всякой периферии, запуск тестов, и только потом запуск логики. Чуть более сложная система, и все, несмотря на МК и RTOS у вас пара секунд запуска, а то и больше.
И заметьте, это еще без динамического выделения и соответственных задержек на запуск конструкторов-деструкторов на этапе инициализации.
А линукс при правильной готовке, тюнинге ядра, статической линковке и трюков по отключении автоматической детекции оборудования и захардкоживания списка периферии и вырезанию всего ненужного в данном системе выходит на готовность за 10-20 секунд. Не в стоке, да. Но достижимо.
UFO just landed and posted this here
Вообще-то очень многие заблуждаются насчет ОС РВ, заблуждаются насчет быстродействия. ОС РВ это такая ОС, которая позволяет выделить зачаче РВ гарантированное процессорное время. Что позволяет разработчику в свою очередь создать систему с гарантированным временем выполнения задачи. Не обязательно быстродействующую.
И еще. Тут пишут, зачем нужно реальное время в линуксе, мол это ему не нужно. Возражу, подсистема РВ Линуксу очень нужна, даже если отбросить всякие использования Линукса для создания систем РВ, она нужна для работы с мультимедиа, особенно звуком.
И еще. Тут пишут, зачем нужно реальное время в линуксе, мол это ему не нужно. Возражу, подсистема РВ Линуксу очень нужна, даже если отбросить всякие использования Линукса для создания систем РВ, она нужна для работы с мультимедиа, особенно звуком.
А ещё с движущимся изображением. В старые добрые времена на компьютерах Spectrum, Atari и Amiga было множество игр и демо с абсолютно плавным скроллингом и другими анимациями. Плавность обеспечивалась тем, что процессор имел возможность на каждый видеокадр сгенерировать новое изображение синхронно с развёрткой монитора. На PC под управлением Windows или Linux достичь подобного практически невозможно. Буферизация кадров — жалкий костыль, увеличивающий время задержки в динамических играх и других критичных приложениях.
Какая-то незаконченная статья, про тесты слишком мало инфы, а про упомянутую "доводку" вообще ничего нет
Но тема очень интересная, информации действительно по ней мало
А почему бы не сделать в «массовом» линуксовом ядре возможность получения жесткого RT с помощью настроек режимов планировщика, обработки прерываний, виртуальной памяти и т.п., без необходимости поддерживать специальную модификацию ядра для этого? Недостаточно востребовано?
Все в нашем мире не дается бесплатно. RT — это про максимальную отзывчивость к внешним воздействиям. Server — к сетевым и вычислительным, Desktop — к пользовательскому вводу. Каждая из этих задач немного противоречит остальным. Надстройками над планировщиком худо-бедно подружили (и то условно подружили) Desktop и Server. Мешать им обоим добавляя в общую кучу еще и RT считается не правильным.
И, пожалуй, именно так и надо. Нишевая потребность в RT обеспечивается отдельной веткой. Тем более, что Linux RT скептиков (типа меня) слишком много. Не стоит вносить в систему яблоко раздора. Пусть эта война идет где-то рядом. А когда она закончится возьмут назад победителя. Все правильно сделано.
И, пожалуй, именно так и надо. Нишевая потребность в RT обеспечивается отдельной веткой. Тем более, что Linux RT скептиков (типа меня) слишком много. Не стоит вносить в систему яблоко раздора. Пусть эта война идет где-то рядом. А когда она закончится возьмут назад победителя. Все правильно сделано.
Так для реализации [умеренно жесткого] RT не требуется какой-то дополнительной функциональности ядра, если оно имеет набор необходимых настроек. Надстройки нужны только в том случае, когда ядро невозможно адекватно настроить под RT. Ядро Windows проприетарное, поэтому там для RT приходится городить отдельное ядро, работающее на выделенных процессорах/ядрах. А ядро Linux открытое — туда сам бог велел добавить нужные настройки, которые каждый мог бы крутить под себя.
Все несколько сложнее, чем Вы описываете.
В ядре (даже ванильном) есть «REAL TIME». Это максимальный приоритет, который настоятельно не рекомендуется выставлять без четкого понимания того зачем это надо. Но всегда в документации есть сноска, про то что это не совсем REAL TIME, а так… Некоторое к нему приближение. Потому как REAL TIME это не только про «быстро».
Потому в Вашей постановке вопроса все УЖЕ сделано, а даже в POSIX'овском понимании, увы нет.
В ядре (даже ванильном) есть «REAL TIME». Это максимальный приоритет, который настоятельно не рекомендуется выставлять без четкого понимания того зачем это надо. Но всегда в документации есть сноска, про то что это не совсем REAL TIME, а так… Некоторое к нему приближение. Потому как REAL TIME это не только про «быстро».
Потому в Вашей постановке вопроса все УЖЕ сделано, а даже в POSIX'овском понимании, увы нет.
Потому что в современных системах есть требования, которые принципиально не стыкуются с RT. По USB пришел пакет, его надо обработать. Потому что сейчас прилетит еще один, а буфер маленький. Хотите поддерживать видео-поток по USB — все, у нас не RT, выбирайте, или то, или то. И таких штук в современных компах много, потому что этого хотят пользователи, и если забить на реалтайм это реализуется не особо нагружая систему. Но ценой того, что у процесса курсора забирают управление когда другим системам этого необходимо. Пользователю пофиг, он этого даже не замечает. Но это уже не реалтайм.
Поэтому переключатель «RT/non-RT» смысла не имеет, потому что при его включении сломается 90% всякого.
Поэтому переключатель «RT/non-RT» смысла не имеет, потому что при его включении сломается 90% всякого.
Не понял, в чем Вы видите «не RT» в поддержке видеопотока по USB? RT — это прежде всего своевременная реакция на события — в данном случае, это регистрация без потерь всех приходящих по USB пакетов.
А для того, чтобы приложение успевало еще и обрабатывать кадры, чтобы пользователю нравилось плавное видео, нужно не RT, а просто достаточное общее быстродействие.
Вообще, условие удовлетворения системой требованиям RT можно сформулировать довольно просто: если реактивность железа позволяет обрабатывать события без потерь, но система из-за каких-то внутренних ограничений неспособна эту реактивность реализовать, то эта система неполноценна в плане RT.
Я, честно говоря, не вижу никаких технических проблем обеспечить время реакции, сколь угодно близкое к быстродействию железа, хоть в Linux, хоть в Windows. Для этого достаточно очень простых доработок в ядре. В Windows этого не делают, поскольку это невыгодно MS, а вот почему этого не делют в Linux, который сплошь и рядом используют в разных устройствах?
А для того, чтобы приложение успевало еще и обрабатывать кадры, чтобы пользователю нравилось плавное видео, нужно не RT, а просто достаточное общее быстродействие.
Вообще, условие удовлетворения системой требованиям RT можно сформулировать довольно просто: если реактивность железа позволяет обрабатывать события без потерь, но система из-за каких-то внутренних ограничений неспособна эту реактивность реализовать, то эта система неполноценна в плане RT.
Я, честно говоря, не вижу никаких технических проблем обеспечить время реакции, сколь угодно близкое к быстродействию железа, хоть в Linux, хоть в Windows. Для этого достаточно очень простых доработок в ядре. В Windows этого не делают, поскольку это невыгодно MS, а вот почему этого не делют в Linux, который сплошь и рядом используют в разных устройствах?
Не понял, в чем Вы видите «не RT» в поддержке видеопотока по USB? RT — это прежде всего своевременная реакция на события — в данном случае, это регистрация без потерь всех приходящих по USB пакетов.
В том, что задача обработки видео по USB подразумевает получение данных не когда получится, а когда он придет в буфер. Если у вас там что-то свое крутится, то идите нафиг, системе надо или кусок данных пропустить, или на вашу задачу забить.
Чтобы и текущую задачу выполнять, и кусок данных не пропустить, еще семьдесят лет назад была придумана концепция приоритетов — она реализована в любой ОС, не только RT. Но между «кручением чего-то своего» и приходом данных по USB есть принципиальная разница: первое — это обычное, рядовое выполнение кода, второе — это асинхронное событие. Именно по эффективности реакции ОС на асинхронные события и определяется ее пригодность для задач RT.
Поэтому ОС РВ должна прежде всего обеспечить ее клиентам (процессам и драйверам) возможность реагирования на асинхронные события со скоростью, сравнимой со скоростью голого железа. Как они этой возможностью распорядятся — вопрос отдельный.
Поэтому ОС РВ должна прежде всего обеспечить ее клиентам (процессам и драйверам) возможность реагирования на асинхронные события со скоростью, сравнимой со скоростью голого железа. Как они этой возможностью распорядятся — вопрос отдельный.
Как вам помогут приоритеты, если две задачи конкурируют за время процессора? И либо ту надо выполнить и уйти на 2мс в нее, либо обеспечить реагирование в течении 1мс на любое другое событие. Система может быть сколько угодно RT, но любая внешняя задача, которую надо выполнить ставит крест на реалтайме.
Вы определенно плохо понимаете смысл понятия «ОС реального времени».
Если за время процессора конкурирует несколько задач, то приоритеты определяют, которую из них выполнять прямо сейчас (прервав, при необходимости, менее приоритетную).
Грубо говоря, ОС РВ гарантирует, что наиболее приоритетный код всегда получит управление в течение периода, определяемого объективными факторами (например, быстродействием процессора, контроллера прерываний, расходами на поиск обработчика прерывания, переключение задач и т.п.).
Например, если любое аппаратное прерывание гарантированно доставляется системе в течение, скажем, 1 мкс, но, при отсутствии более приоритетных прерываний, обработчик может быть вызван как через 1 мкс, так и через 50 или 100 мкс, то эта система не может называться ОС РВ. Если наиболее приоритетный поток, перейдя в состояние готовности, технически может начать выполнение через 1 мкс, но фактически может начать его только через 100 или 500 мкс (например, когда текущий поток догадается освободить процессор) — это тоже не ОС РВ.
Если за время процессора конкурирует несколько задач, то приоритеты определяют, которую из них выполнять прямо сейчас (прервав, при необходимости, менее приоритетную).
Грубо говоря, ОС РВ гарантирует, что наиболее приоритетный код всегда получит управление в течение периода, определяемого объективными факторами (например, быстродействием процессора, контроллера прерываний, расходами на поиск обработчика прерывания, переключение задач и т.п.).
Например, если любое аппаратное прерывание гарантированно доставляется системе в течение, скажем, 1 мкс, но, при отсутствии более приоритетных прерываний, обработчик может быть вызван как через 1 мкс, так и через 50 или 100 мкс, то эта система не может называться ОС РВ. Если наиболее приоритетный поток, перейдя в состояние готовности, технически может начать выполнение через 1 мкс, но фактически может начать его только через 100 или 500 мкс (например, когда текущий поток догадается освободить процессор) — это тоже не ОС РВ.
то приоритеты определяют, которую из них выполнять прямо сейчас (прервав, при необходимости, менее приоритетную).
Спасибо, кэп, а то я не догадался!
С чего тред-то начался? С тезиса «а чо бы не сделать из линуксового ядра RTOS».
Я ответил на это «гарантируем выделение времени на произвольные задачи — ломаем обмен по USB», и тут вы начали строчить цитаты из википедии. Спасибо за умение цитировать википедию, но ситуация странная — вы же первый спросили, а почему, собственно, так не сделано, и когда вам начали объяснять, почему же не сделано, вы начали рассказывать, что дескать, они глупые, плохо понимают смысл понятия, и так далее. Вы уж определитесь — вы или просите объяснений или стоите на тумбочке с видом «вы все non-rtOS, а я дартаньян».
Дело не в том, что RTOS c USB не может быть. Дело в том, что современная практика использования USB подразумевает, что процессору надо когда происходит обмен данными, часто и непредсказуемо уходить в обработку. Для пользовательской системы такое положение дел допустимо, для RTOS нет. И если вам надо 2мс на обработку пакета, а гарантированная реакция RTOS должна составлять 1мс, то либо крестик снять, либо трусы надеть: либо прерывать обработку пакета, если вдруг надо пошевелить движком, но тогда ломается пользовательский опыт — скипать фреймы тоже не дело, либо ждать от 1 до 2мс, и тогда ломается уже реалтаймовость. Поэтому очень сложно совместить текущую пользовательское ядро, в которой данные важнее чем быстрая реакция на события (пользователь и подождать может) и RTOS, в которой важнее реакция, а все остальное в меньшем приоритете.
Покажите пальцем, где я или кто-то еще предлагал «гарантировать выделение времени на произвольные задачи».
Что Вы называете «обработкой» приходящего пакета? Для любого пакета, приходящего от любого устройства (хоть USB, хоть PCIe, хоть с любой другой шины) прежде всего необходимо зарегистрировать этот пакет, поставив его в очередь на обработку, а контроллер DMA перенастроить на свободную область памяти. Для выполнения этих действий на современном железе достаточно единиц, максимум — десятков микросекунд. Если где-то код занимается этим аж две миллисекунды — значит, это очень кривой код. Задача ядра — обеспечить надежный и непрерывный прием пакетов, а не их обработку.
Обработка собственно данных из пакета — это уже совершенно отдельная задача, чаще всего выполняемая «пользовательским» кодом. Там тоже должны быть приоритеты — эта задача, понятное дело, должна иметь преимущество перед задачами отображения UI. Если быстродействие железа достаточно, то задача ОС РВ — обеспечить этой задаче возможно загружать железо настолько, насколько это необходимо.
Если же быстродействия железа для конкретной задачи недостаточно, то вообще нет смысла говорить о «реалтаймовости» ОС на этом железе.
Все проблемы с «недостаточным реалтаймом» возникают от того, что на достаточно быстром железе ОС или применяет неправильные алгоритмы планирования/переключения, или сама неприлично тормозит в ядре или собственных стандартных драйверах, чем регулярно грешит винда.
А ко времени реакции UI на действия пользователя понятие ОС РВ имеет отношение только в том случае, когда эти действия включены в набор событий, безусловно критичных ко временем реакции. Например, если делать ОС РВ для единого автомобильного компьютера, который управляет и двигателем, и тормозами, и вентиляцией, и мультимедией, то события «повысилось содержание кислорода в отработавшем газе», «передвинут рычаг управления дальним светом» и «нажата педаль тормоза» будут относится к безусловно критичным, а события «повернут регулятор оборотов салонного вентилятора» и «нажата кнопка перехода к следующей песне» — к некритичным. Хотя при этом разумно дать событиям управления вентилятором бОльший приоритет, чем управлению музыкой, но это уже кому как.
Что Вы называете «обработкой» приходящего пакета? Для любого пакета, приходящего от любого устройства (хоть USB, хоть PCIe, хоть с любой другой шины) прежде всего необходимо зарегистрировать этот пакет, поставив его в очередь на обработку, а контроллер DMA перенастроить на свободную область памяти. Для выполнения этих действий на современном железе достаточно единиц, максимум — десятков микросекунд. Если где-то код занимается этим аж две миллисекунды — значит, это очень кривой код. Задача ядра — обеспечить надежный и непрерывный прием пакетов, а не их обработку.
Обработка собственно данных из пакета — это уже совершенно отдельная задача, чаще всего выполняемая «пользовательским» кодом. Там тоже должны быть приоритеты — эта задача, понятное дело, должна иметь преимущество перед задачами отображения UI. Если быстродействие железа достаточно, то задача ОС РВ — обеспечить этой задаче возможно загружать железо настолько, насколько это необходимо.
Если же быстродействия железа для конкретной задачи недостаточно, то вообще нет смысла говорить о «реалтаймовости» ОС на этом железе.
Все проблемы с «недостаточным реалтаймом» возникают от того, что на достаточно быстром железе ОС или применяет неправильные алгоритмы планирования/переключения, или сама неприлично тормозит в ядре или собственных стандартных драйверах, чем регулярно грешит винда.
А ко времени реакции UI на действия пользователя понятие ОС РВ имеет отношение только в том случае, когда эти действия включены в набор событий, безусловно критичных ко временем реакции. Например, если делать ОС РВ для единого автомобильного компьютера, который управляет и двигателем, и тормозами, и вентиляцией, и мультимедией, то события «повысилось содержание кислорода в отработавшем газе», «передвинут рычаг управления дальним светом» и «нажата педаль тормоза» будут относится к безусловно критичным, а события «повернут регулятор оборотов салонного вентилятора» и «нажата кнопка перехода к следующей песне» — к некритичным. Хотя при этом разумно дать событиям управления вентилятором бОльший приоритет, чем управлению музыкой, но это уже кому как.
Слушай, не пиши ахинеи, не позорься. Ты совершенно не понимаешь что такое ОСРВ, и чем отличается от других ОС. А главное для чего оно нужно. Твой пример про USB полный бред.
Как минимум, что получение пакетов по USB можно обеспечить минуя ЦП по DMA. А разбор пакетов в удобное время.
Как минимум, что получение пакетов по USB можно обеспечить минуя ЦП по DMA. А разбор пакетов в удобное время.
«в чем Вы видите «не RT» в поддержке видеопотока по USB?»
Интерфейс USB крайне напряжный и точно не лучший для RT. В каких-то случаях, возможно и подойдёт, но время реакции системы увеличивает значительно.
Интерфейс USB крайне напряжный и точно не лучший для RT. В каких-то случаях, возможно и подойдёт, но время реакции системы увеличивает значительно.
Звучит крайне странно. Можно конкретнее, что именно «крайне напряжного» в интерфейсе USB?
К примеру количество вызовов прерывания и время обработки запросов драйвером — достаточно активно пошевелить мышкой десяток секунд, чтобы время пребывания в обработчика драйвера USB превысило таковое для сетевого стека и диска.
ps. Выше дают ссылку на рекомендации по настройке RT системы. Цитата:
«Hint:
Hints for getting rid of SMI interrupts on x86
1. Use PS/2 mouse and keyboard,
2. Disable USB mouse and keyboard in BIOS, „
Если же, к примеру, к интерфейсу USB3 подключить внешний SSD и интенсивно с ним поработать, цифры ещё заметно подрастут.
В каких-то случаях остатка отзывчивости системы может хватить, но далеко не всегда.
ps. Выше дают ссылку на рекомендации по настройке RT системы. Цитата:
«Hint:
Hints for getting rid of SMI interrupts on x86
1. Use PS/2 mouse and keyboard,
2. Disable USB mouse and keyboard in BIOS, „
Если же, к примеру, к интерфейсу USB3 подключить внешний SSD и интенсивно с ним поработать, цифры ещё заметно подрастут.
В каких-то случаях остатка отзывчивости системы может хватить, но далеко не всегда.
Тут проблема не в USB, а в кривом драйвере (да, у MS их много). 500 мс процессорного времени на десяток секунд сколь угодно быстрого шевеления мышью — это чудовищно, неприлично много.
У меня с USB 3.0 интеловский драйвер iusb3xhc.sys под Win7 потребляет около 50 мс на десять секунд дерганья мышью, и около 150 — на десять секунд видео 1920x1080 (сжатого) от USB-камеры. Но и это тоже очень и очень много. Если в случае с мышью обмен по USB может идти программно (поскольку данных в пакете мало), то с камеры он обязан идти по DMA. Что там столько времени может делать драйвер — ума не приложу.
Да, именно такие косяки в виндовых драйверах (которые, кстати, сплошь и рядом нарушают требования самой MS, что не мешает им проходить все тесты и получать сертификаты) и портят весь реалтайм в системе. А ведь чисто технически, с правильно сделанными драйверами, винда была бы вполне себе RT-системой.
У меня с USB 3.0 интеловский драйвер iusb3xhc.sys под Win7 потребляет около 50 мс на десять секунд дерганья мышью, и около 150 — на десять секунд видео 1920x1080 (сжатого) от USB-камеры. Но и это тоже очень и очень много. Если в случае с мышью обмен по USB может идти программно (поскольку данных в пакете мало), то с камеры он обязан идти по DMA. Что там столько времени может делать драйвер — ума не приложу.
Да, именно такие косяки в виндовых драйверах (которые, кстати, сплошь и рядом нарушают требования самой MS, что не мешает им проходить все тесты и получать сертификаты) и портят весь реалтайм в системе. А ведь чисто технически, с правильно сделанными драйверами, винда была бы вполне себе RT-системой.
Проблему кривых драйверов, конечно, никто не отменял. Но ведь драйвер tcpip.sys от того же поставщика, и проходит через него информации заметно больше, а времени он отбирает гораздо меньше.
Даже если драйвер USB в Windows 10 настолько кривой, что его можно оптимизировать по производительности на порядок, он всё равно будет отнимать больше времени, чем драйвер tcpip.
Ну и в DOS отключение USB контроллеров сказывается весьма позитивно на отзывчивости системы — есть знакомое приложение, работающее с оборудованием через pci, которое пропускает циклы просто при включении контроллера USB в BIOS.
Даже если драйвер USB в Windows 10 настолько кривой, что его можно оптимизировать по производительности на порядок, он всё равно будет отнимать больше времени, чем драйвер tcpip.
Ну и в DOS отключение USB контроллеров сказывается весьма позитивно на отзывчивости системы — есть знакомое приложение, работающее с оборудованием через pci, которое пропускает циклы просто при включении контроллера USB в BIOS.
Так «поставщик» — это не один человек, и даже не одна команда — это огромное количество разных людей, каждый из которых принимает участие в одном или нескольких проектах. Какие-то драйверы получаются аккуратными, какие-то — очень кривыми. Если количество жалоб не достигает критического уровня — их не переделывают годами.
Но на сеть уже давно завязано гораздо больше, чем на USB. В каких-то версиях винды заметно тормозил и tcpip.sys, но быстро поднялся вой, поскольку это реально мешало множеству задач, и драйвер поправили. А USB параллельно с задачами реального времени используется гораздо реже, поэтому первый совет — «отключи USB».
Я недостаточно близко знаком с протоколами USB, чтобы судить предметно, но что именно там может требовать миллиона команд в секунду при шевелении мышкой, и трех миллионов — при захвате видеопотока? Это можно было бы понять при программной передаче данных, но там же давным-давно DMA.
Но на сеть уже давно завязано гораздо больше, чем на USB. В каких-то версиях винды заметно тормозил и tcpip.sys, но быстро поднялся вой, поскольку это реально мешало множеству задач, и драйвер поправили. А USB параллельно с задачами реального времени используется гораздо реже, поэтому первый совет — «отключи USB».
Я недостаточно близко знаком с протоколами USB, чтобы судить предметно, но что именно там может требовать миллиона команд в секунду при шевелении мышкой, и трех миллионов — при захвате видеопотока? Это можно было бы понять при программной передаче данных, но там же давным-давно DMA.
USB исходно слишком сложен и ресурсоёмок, драйвера тут ни при чём, я привёл пример, когда в DOS сам факт невыключения контроллера USB приводит к существенному ухудшению времени реацкии системы.
Да, программисты данного поставщика умеют писать софт, ставящий на колени любой компьютер, но к написанию драйверов они, к счастью, (пока) не причастны.
Была альтернатива — FireWire, принципиально более простая, но лицензионная политика Apple как одного из разработчиков убила этот протокол.
Да, программисты данного поставщика умеют писать софт, ставящий на колени любой компьютер, но к написанию драйверов они, к счастью, (пока) не причастны.
Была альтернатива — FireWire, принципиально более простая, но лицензионная политика Apple как одного из разработчиков убила этот протокол.
Насколько я знаю, USB сложен в плане поддержки всех предусмотренных стандартом описаний и параметров, но они все передаются на этапах подключения/договаривания. Когда идет потоковая передача данных, передаются только данные и минимальные управляющие сигналы. Так что в самом интерфейсе нечему заметно нагружать ЦП, это все драйверы.
А тем, кто понимает, зачем нужно «REAL TIME», оно реально помогает максимально быстро реагировать на асинхронные события? Есть ли в ядре средства контроля внутренних задержек (например, сколько времени тот или иной модуль ядра или драйвер проводит в обработчике прерывания? Если в Linux есть механизм отложенной обработки прерываний, то организуются ли его очереди в соответствии с приоритетом самих прерываний?
Самый правильный ответ — надо смотреть. Пожалуй, стоило бы им и ограничиться. Но…
Насколько я знаю, в ванильном ядре кроме приоритета и очередей нет ничего. Впрочем, трассировка (отслеживание времени) вполне возможно. А вот как-то нормализовать джитер, гарантировать в разумных пределах время реакции (или гарантированно не потерять одно из двух быстрых последовательных событий) и гарантировать дедлайн… Насколько я знаю в ванили это невозможно. Что-то позволяют RT-патчи или модификации типа описываемой в данной статье.
Но все же я вынужден вернуться к первому предложению данного ответа. Тема RT уже довольно продолжительное время не находится сфере моих непосредственных интересов. А при возникновении оных я пытаюсь решить проблему другими средствами.
Насколько я знаю, в ванильном ядре кроме приоритета и очередей нет ничего. Впрочем, трассировка (отслеживание времени) вполне возможно. А вот как-то нормализовать джитер, гарантировать в разумных пределах время реакции (или гарантированно не потерять одно из двух быстрых последовательных событий) и гарантировать дедлайн… Насколько я знаю в ванили это невозможно. Что-то позволяют RT-патчи или модификации типа описываемой в данной статье.
Но все же я вынужден вернуться к первому предложению данного ответа. Тема RT уже довольно продолжительное время не находится сфере моих непосредственных интересов. А при возникновении оных я пытаюсь решить проблему другими средствами.
Если в Linux есть механизм отложенной обработки прерываний, то организуются ли его очереди в соответствии с приоритетом самих прерываний?
да, это существует из коробки.
Sign up to leave a comment.
Linux в режиме реального времени