Поддержка real-time будет стандартизирована

Может у меня торможение, но странно все это звучит. Real-time возможности они ведь имеют свою логику, противоположную многим другим возможностям.

Как они будут уживаться в рамках одного кода ? Выбор таких свойств в ядре наверняка должен быть альтернативен многим другим свойствам. Это выглядит как смесь бульдога с носорогом

Здорово!

Интересно, где бы подробнее почитать что за патчи?

>Это выглядит как смесь бульдога с носорогом

Таких смесей уже десяток. Кто-то просто ускоряет ядро, кто-то вводит свой (более высокого уровня) планировщик, а ядро гоняет как один из процессов (RTAI, FSMLabs RTLinux).

По ссылке, какой-то реально кпасноглазый тип :)

Kak eto s 2.6.18????ono zhe uzhe released Mozhet s 2.6.19?

> будут включены в основную ветку ядра, начиная с версии 2.6.18.

Что значит "будут"? 2.6.18 уже давно вышел. И нет там патча -rt. Некоторые его части постепенно мигрируют в ядро, но полного варианта -rt не будет и в 2.6.19. А может, и никогда :(

> кто-то вводит свой (более высокого уровня) планировщик, а ядро гоняет как один из процессов (RTAI, FSMLabs RTLinux)

Это не совсен так. Adeos в новых RTAI - это скорее именно планировщик. Ядро как процесс гоняет L4 (AFAIK), и MkLinux когда-то давно гонял.

Imeetsja v vidu soft ili hard real-time?

объясните ламеру, real-time принесет пользу для десктопа?

не принесет

> объясните ламеру, real-time принесет пользу для десктопа? dlja nekotorih veshej dolzhen pozvolitj snizitj latentnostj i vremja reakcii na opredelennije sobitija (po krajnej mere eto rabotaet v xenomai). Verojatnee vsego dlja obi4nogo polzovatelja takoj oblastju budet multimedia.

> объясните ламеру, real-time принесет пользу для десктопа?

Что у тебя на десткопе такое крутится, что требует реалтайма - эмулятор лондОнской биржи на локалхосте?

> Как они будут уживаться в рамках одного кода ?

Наверняка имеется в виду т.н. soft-рилтайм, а не hard. Возможно, те патчи улучшают и так неплохой мягкий рилтайм ядра.

>Как они будут уживаться в рамках одного кода ? Выбор таких свойств в ядре наверняка должен быть альтернативен многим другим свойствам.

Легко, помню работал я в многопользовательской системе реального времени RSX11-M - любители поиграть в тетрис были просто счастливы.

Во-во! А то у меня переключалка рус/англ частенько в своп убирается. Забудешься, и пол строки кракозябами напишешь :)

Фигня етот риалтайм. Микроядро - вот ето вещь.

> работал я в многопользовательской системе реального времени RSX11-M - любители поиграть в тетрис были просто счастливы

Чё-то я не помню тетриса для ОС РВ :)

> Real-time возможности они ведь имеют свою логику, противоположную многим другим возможностям.

> Как они будут уживаться в рамках одного кода ? Выбор таких свойств в ядре наверняка должен быть альтернативен многим другим свойствам.

Столько раз это слышал - но никогда не слышал _доказательств_ этого.

> Это выглядит как смесь бульдога с носорогом

Посмотри на патчи -rt. Нормально выглядит.

> объясните ламеру, real-time принесет пользу для десктопа?

Видел как работают кеды на ядре 2.4 и на 2.6 с PREEMPT? Вот разница будет в этом направлении, только ещё больше.

> объясните ламеру, real-time принесет пользу для десктопа?

Принесёт. Тем, кто пишет музыку.

>Таких смесей уже десяток. Кто-то просто ускоряет ядро, кто-то вводит свой (более высокого уровня) планировщик, а ядро гоняет как один из процессов (RTAI, FSMLabs RTLinux).

В основной ветке ядра я такого не видел

А вообще я хотел бы заметить, что в современных системах возможна группировка физических процессоров в некоторые абстрагированные системные ресурсы и одновременное использование разных планировщиков в рамках одного ядра.

>Столько раз это слышал - но никогда не слышал _доказательств_ этого.

Если бы я мог доказать это, я бы так и сделал. Но это был скорее вопрос.

И тем не менее, то , что я читал о реал-тайм системах говорит именно в эту сторону. Если главная задача реалтайм системы обеспечить некое гарантированное время отклика, то такая идеология не может не конфликтовать со всей архитектурой ядра, которое спроектироанно без учета таких гарантий, и даже более того, скажем для решения задачи производительной работы на широком классе оборудования.

С очевидностью это разные принципы, и при последовательной реализации они должны друг другу противоречить. что бы они не противоречили, должны быть некие компромиссы, которые приведут к ослаблению наделенности или на реалтайм или на эффективность работы, а скорее всего и то, или другое вместе.

> А вообще я хотел бы заметить, что в современных системах возможна группировка физических процессоров в некоторые абстрагированные системные ресурсы и одновременное использование разных планировщиков в рамках одного ядра.

К реальному времени всё это имеет отдаленное отношение

> главная задача реалтайм системы обеспечить некое гарантированное время отклика, то такая идеология не может не конфликтовать со всей архитектурой ядра

Я не вижу особых противоречий (да я никаких не вижу :)) Политикой ядра давно было "поменьше критических участков" (те, которые залочены) - это вредит масштабируемости на SMP. И именно это сходство SMP и RT и использовал Robert Love во времена 2.4, и теперь использует Ingo Molnar. В остальном... RT-mutex (и наследование приоритетов) - это, в конце концов, просто способ обратится к планировщику, так что тоже никаких идеологических разногласий. HR-таймеры, tickless kernel, generic IRQ framework, lockdep - это всё полезные и за пределами RT вещи, которые идеологически ни с чем не конфликтуют. Просто так получилось - они разработаны людьми, занимающимися RT. Что остается - threaded IRQs? Иделогического конфликта нет и здесь, AFAIK. Просто есть мнение, что большинству это не надо, так зачем раздувать ядро. Но ситуация может измениться: мультимедия наступает - музыканты были основной силой, которая проталкивала первые работы по RT, первыми (известными мне) тестерами серии патчей -vp и -rt.

> С очевидностью это разные принципы

Ну укажи мне на эту очевидность - не вижу я ее

> должны быть некие компромиссы

JОни всегда есть

ага липукс как всегда - "больше костылей, синих белых и крастных", жалко что из него сделали помойку.

А интересно задачу обеспечить гарантированное число транкзаций в секунду при любой нагрузке на систему можно отнести к реальному времени?

> А интересно задачу обеспечить гарантированное число транкзаций в секунду при любой нагрузке на систему можно отнести к реальному времени?

При подходящем определении термина "реальное время" - да, можно 8)

Если серьезно - можно, конечно. Только это не имеет отношения к традиционному понятию о том, что реальное время - это процесс управления каким-то объектом, требующий низких и предсказуемых задержек (роль RT-11 ;)).

Думаю нет. :)

Смысл же RT в гарантированном времени отклика системы на определенное событие.

http://en.wikipedia.org/wiki/Real-time#Real_time_and_high_performance

> Дополнительные real-time возможности, доступные раннее в виде патчей будут включены в основную ветку ядра, начиная с версии 2.6.18.

После включения этой нужной безусловно всем и каждому фичи, анонимусам должно быть стыдно комментить новости не в real-time

>ага липукс как всегда - "больше костылей, синих белых и крастных", жалко что из него сделали помойку.

Ага... особенно красТных. Это цвет, кстати, или некое другое свойство?

Потестить что-ль... а то видать не зря дома новый сервачок завелся, вовремя, нужно к делу приспособить.

Нафига козе баян, а домашнему сервачку RT? У тебя там данные телеметрии обрабатываются или чем ты тестить будешь? Скомпилируется - не скомпилируется? :)

> Нафига козе баян, а домашнему сервачку RT?

Он оттуда видео транслирует... в прямом эфире и реальном времени :)

Чему там противоречить. Возможно, заменят планировщик и все процессы будут выполняться с одинаковым приоритетом. Ядро будет гарантированно реагировать на событие за два тика (или сколько там?), большего и не трабуется. Preemptive режим этому способствует.

> А вообще я хотел бы заметить, что в современных системах возможна группировка физических процессоров в некоторые абстрагированные системные ресурсы и одновременное использование разных планировщиков в рамках одного ядра.

Solaris?

>> А вообще я хотел бы заметить, что в современных системах возможна группировка физических процессоров в некоторые абстрагированные системные ресурсы и одновременное использование разных планировщиков в рамках одного ядра.

> Solaris?

Linux

> Нафига козе баян, а домашнему сервачку RT? У тебя там данные телеметрии обрабатываются или чем ты тестить будешь? Скомпилируется - не скомпилируется? :)

И это тоже. А на самом деле - возможно захочу его транслятором видео во внешнюю сетку сделать или что-то в этом роде.

> > Solaris?

> Linux

И все же - Солярка.

>>> Solaris?

>> Linux

>И все же - Солярка.

А так же IRIX, и, кажется, даже оффтопик. Много где есть.

Вот только про оффтопик не нужно, там простую-то многопроцессорность с горем пополам асилили только к 2003 году.

В общем - юниксы.

Кстати, тогда такой вопрос, какие из Unix-систем на сегодняшний день поддерживают preemptive в ядре?

>объясните ламеру, real-time принесет пользу для десктопа?

канешн принесет! сплошная польза.

Во-первых это тЪру! Перед знакомыми, зевнув в ладошку: "а у меня риалтайм на тачке домашней.."

Во-вторых, это тЪру. После третьей перекомпиляции, с отвалившимися девайсами, ты будешь думать "Оно мне надо?!?" и так придешь к этому самому.. вобщем станешь йогой. Это которые кричат "Йог тваю.. мазербоард!"

Сплошная польза на домашней тачке.

> даже оффтопик

А какие там есть планировщики кроме того, что там by default? О_о

> Во-первых это тЪру! Перед знакомыми, зевнув в ладошку: "а у меня риалтайм на тачке домашней.."

Зря шутишь. Судя по проходившим ранее дебатам, на ЛОРе довольно много фетишистов, долгое время копивших на навороченную аудио-систему с золотыми проводниками и соплями девствениц в качестве изоляции. Им без real-time в ядре музыку слушать некошерно. cat kernel-2.6.18.tar.bz2 > /dev/dsp без RT дает микро-искажения в звучании.

> Кстати, тогда такой вопрос, какие из Unix-систем на сегодняшний день поддерживают preemptive в ядре?

Кроме Linux, как минимум - IRIX и Solaris. И QNX, конечно.

>Зря шутишь.

Абсолютно согласен. В том смысле что круг задачек найдется, вон.. знакомого маво звукорежисера-музыканта можно было бы переманить такой фичей на линукс. Одначе учитывая спешность исполнения, вечную приписку "экспериментал" и полный ужас с дистрибьюторами о реалтайме как о чем-то нормальном и обычном наверное будут говорить года через два :/

> учитывая спешность исполнения

Этим патчам уже 2 года

> вечную приписку "экспериментал"

:D нужно брать поздние версии патчей для конкретного ядра

> полный ужас с дистрибьюторами

судя по трафику lkml примерно годичной давности, специализированный музыкальный софт давно уже хорошо относится к -rt, и рекомендует его использование.

Когда начинаешь рассуждать о использованных элементах для достижениея цели, то сама цель может потеряться за обилием деталей. Русские эту истину выражают пословицей "Не видеть за деревьями леса"

Можно сказать и по другому - используя буквы однгоо и того же алфавита можно послать сам знаешь куда, а можно и просто пофлудить на ЛОР-е

:-)

> Когда начинаешь рассуждать о использованных элементах для достижениея цели, то сама цель может потеряться за обилием деталей.

Когда не владеешь предметом, это можно маскировать глубокомысленной трескотней.

> Можно сказать и по другому - используя буквы однгоо и того же алфавита можно послать сам знаешь куда, а можно и просто пофлудить на ЛОР-е

Мудрено завернул, да.