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

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

Солярка - так точно умеет, + судя по недавнему пеару от начальника QNX - оно тоже умеет и будет скоро уметь еще лучше породнившись с процами. Ну и наш любимый линукс. С AIX и остальными не работал.

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

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

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

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

Сидишь ты, например, за сервером Саныча и вдруг ни с того ни с сего мышой двинул. А на серваке ЛОР хостится, и тысячи анонимусов в этот самый момент нажимают кнопку "Post/Поместить".

Нормальный линукс вычислит приоритет для всех процессов, включая обработчик мыши и записи в базу анонимусовых постов, и вероятность того, что мышь двинется первой, будет равна 1/(кол-во анонимусов).

А realtime Linux забьёт на транзакции Саныча и сперва (или, по крайней мере, с большим приоритетом) обработает твою конвульсию, и только затем передаст управление низкоприоритетному процессу БД.

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

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

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

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

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

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

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

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

Как то трудно поверить, что ты не прикидываешся

> А realtime Linux забьёт на транзакции Саныча и сперва (или, по крайней мере, с большим приоритетом) обработает твою конвульсию, и только затем передаст управление низкоприоритетному процессу БД.

Оно и щас вроде так работает. Интерактивным задачам квант времени больше выделяется.

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

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

> Сидишь ты, например, за сервером Саныча ...

> вероятность того, что мышь двинется первой, будет равна 1/(кол-во анонимусов)

> А realtime Linux забьёт на транзакции Саныча

Спасибо за ликбез ;). Это различия в _функционировании_, а не в идеологии построения ядра ОС. То, что ты описал, возможно уже на ядре 2.0 (кажется, тогда появились SCHED_FIFO и SCHED_RR). Это может любой более-менее стандартный Unix. Где различия в _идеологии построения_?

Тебя трудно понять. Я - не понимаю.

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

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

тю. у меня под этим еще 2.4.18 справлялся - в реалтайме кодил поток в mpeg-4 на k6-233. c звуком

странно, вспоминаю сколько часов было потрачено на пережатие фильма на более навороченом железе и както в голове не укладывается что это можно сделать на k6-2 233 :)

> вспоминаю сколько часов было потрачено на пережатие фильма на более навороченом железе

Реальное время - это прежде всего предсказуемость. K6-2/233 предсказуемо выдавал 2.4 кадра в секунду :)

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

О, анекдоты на C появились. ;)

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

Нет сынок, это фантастика. Любая нагрузка в итоге может гарантировать только DoS.

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

>Нет сынок, это фантастика. Любая нагрузка в итоге может гарантировать только DoS.

В том и смысл разделения нагрузки на RT и не-RT (а внутри RT - по приоритетам), чтобы обеспечивать "гарантированное число транзакций" для RT-нагрузки при _любой_ не-RT нагрузке. При условии, конечно, что на заданное число транзакций вообще хватает производительности.

По видимому это склад мышления. Ты мыслишь конкретно, и все что выходит за рамки разговора о конкретных вещах воспринимаешь как разговор о чем то несуществующем.

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

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

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

Есть старая юниксовая мантра - "mechanisms, not policy". Я пытаюсь объяснить, что всё, реализуемое в рамках патча -rt - это использование существующих механизмов ядра. Я не вижу, как именно это противоречит хоть каким-то принципам построения серверных ОС. Более того - он был бы невозможен, если бы ядро не придерживалось политики "критические секции должжны быть краткими, иерархия локов - мелкой" (всё это необходимо для хорошего масштабированя на SMP и maintainable кода). Был бы благодарен за примеры вида "Существует принцип X, и фича Y нарушает его таким-то способом".

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

Приведенный пример показывал различия в планировщиках, которые имеются и в триждынасквозьсерверных ОС.

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

Ребята, не бывает (hard) ОСРВ, бывает только готовая вычислительная система (железо, ОС и прикладной софт) реального времени. Иначе это просто слова красивые. RTOS означает только то, что на её базе можно строить такую выч. систему. Hard/soft - решать тому, кто строит.

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

Оценка инвестиционных рисков, счет идет на десятки миллисекунд, новел будет выпускать специальный риалтайм дистр. сюзи под это дело.

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

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

Только вот нормальных аналогов Logic Audio и Cubase SX нет...

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

Знач нужно начинать выпускать пользовательские девайсы (джип с дистанционным управлением) и начинать обрабатывать дома данные телеметрии:))

Я не достаточно хорошо знаю ядро, чтобы приводить более детальные примеры, но если ты утверждаешь, что SMP и RT подсистемы имеют сходство в механизмах, то я готов поверить этому. Ну а SMP это достаточно важная подсистема, чтобы сделать вывод о том, что ядро уже и в нынешнем виде весьма близка по используемым механизмам к RT.

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

Неужели так трудно понять, что RT система сконструирована так, что, должна обеспечить гарантированный временной отклик, а ядро Линукса такой задачи себе не ставит. Не так важно, что я не могу сказать, какую задачу ставит себе ядро Линукса, но оно точно не ставит себе задачу гарантировать реакцию по временни.

Пожалуйста объясни, зачем музыкантам нужно RT. Например графическая подсистема совсем не RT

>Пожалуйста объясни, зачем музыкантам нужно RT. Например графическая подсистема совсем не RT

Чтобы иметь гарантированную полосу I/O (GRIO).

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

Это истинно и без всякого RT

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

Яволь!

> а ядро Линукса такой задачи себе не ставит

...но так получилось, что всё необходимое для этого в нем было заложено работами по масштабируемому SMP. Если бы не это, то RT в Линуксе потребовало бы неприемлемо больших доработок.

> Пожалуйста объясни, зачем музыкантам нужно RT.

Воспроизведение/синтез звука _очень_ чувствительны к задержкам (особенности человеческого восприятия)

> Например графическая подсистема совсем не RT

Человек так устроен, что к этому он чувствителен гораздо меньше. Кроме того, "графическую подсистему" можно довести до RT, если нужно (хотя это вряд ли нужно - ну не улавливает глаз задержки в несколько мс, которые улавливает слух). И живет она большей частью в userspасе.

> Оценка инвестиционных рисков, счет идет на десятки миллисекунд, новел будет выпускать специальный риалтайм дистр. сюзи под это дело.

> Sun-ch # (*) (17.10.2006 11:06:16)

Это как мешать принципы построения грузовика и грузового самолета. Ведь у обоих есть двигатель и оба двигаются за счет горения топлива. Да и задачи похожие решают. Вот только задачи разные и решаются по разному, хоть и похожи.

Real-time computing is sometimes misunderstood to be high performance computing, but this is not always the case. For example, a massive supercomputer running a scientific simulation may offer impressive performance, yet it is not executing a real-time computation. Conversely, once the hardware and software for an anti-lock braking system has been designed to meet its required deadlines, no further performance gains are necessary. Furthermore, if a network server is highly loaded with network traffic, its response time may be slower but will (in most cases) still succeed. Hence, such a network server would not be considered an RTC system: Temporal failures (delays, time-outs, etc.) are typically small and compartmentalized but are not catastrophic failures. In an RTC system, a slow-down beyond limits would often be considered catastrophic for its application context.

> Оценка инвестиционных рисков, счет идет на десятки миллисекунд, новел будет выпускать специальный риалтайм дистр. сюзи под это дело.

> Sun-ch # (*) (17.10.2006 11:06:16)

Хотя принципиальной и практической важности отнесение приведенного примера к RT или HPC или к обоим сразу не имеет.

Потому я думаю стоит забить. :)

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

Потому пришлось ограничиться простыми формами, хотя можно было много чего сделать.

В системах управления и(или) контроля RT графика важна.

>Чтобы иметь гарантированную полосу I/O (GRIO).

Т.е чтобы гарантировать качество воспроизведения ?

> Я не достаточно хорошо знаю ядро

ну так чего споришь тогда? Слив защитан

>> Я не достаточно хорошо знаю ядро

>ну так чего споришь тогда? Слив защитан

Я не спорю, я выясняю то, что мне интересно знать, и если человек продолжает мне отвечать, значит ему тоже это интересно

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

> задержки перерисовки порядка секунд

:D Здесь поддержка RT в ядре тебе не помогла бы. Она занимается милли- и микросекндами. Секунды - это уже userspace (и/или userspace + неадекватное железо).

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

Да я ядро от userspace отличаю, просто раз речь зашла о RT потребностях, я и привел пример.

:-)

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

...

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

...

> то , что я читал о реал-тайм системах говорит именно в эту сторону

...

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

...

Неплохо как, без единого аргумента "они ведь..наверняка" перерастает в "с очевидностью"

> Может у меня торможение

Пожалуй.

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

> Оценка инвестиционных рисков, счет идет на десятки миллисекунд

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

> новел будет выпускать специальный риалтайм дистр. сюзи под это дело

Специально для калькуляторов CASIO.

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

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

Даже боюсь тебе предложить использовать для анализа формулировок diff i md5summ, а вдруг не осилишь

Короче смысл в том, что теперь включив RT-приложение все остальное в Линуксе будет тормозить.

>Короче смысл в том, что теперь включив RT-приложение все остальное в Линуксе будет тормозить.

Ты коротко выразил смысл моих подозрений :-)

> > Короче смысл в том, что теперь включив RT-приложение все остальное в Линуксе будет тормозить.

> Ты коротко выразил смысл моих подозрений :-)

не так, отклик системы будет быстрее за счет общей производительности системы

хотя в ядре уже есть планировщик идейно близкий RT

>>Короче смысл в том, что теперь включив RT-приложение все остальное в Линуксе будет тормозить.

>Ты коротко выразил смысл моих подозрений :-)

Скорее всего не так. Для RT-приложения будет выделен фиксированный объем системных ресурсов (процессор, память), необходимый для его выполннения (не обязательно большой - зависит от задачи). Остальные системные ресурсы будут полностью доступны для остальных программ. Если RT-приложение не ресурсоемкое, его выполнение просто не будет заметно.

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

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

да-да, иронию нынче в школах не преподают, а жаль!

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

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

Рекомендация рекомендации рознь. В моем конкретном и частном случае я музыканту ничего не могу порекомендовать. Именно из-за ужаса с дистрибьюторами. Это мне интересно "докопаться до правды" если вдруг и насмерть звуковуха типа Analog Devices с драйвером hda-intel отваливается в убунте, или заводится со страшным скрипом в дженте. А что делать человеку, у которого один микрофон стоит больше маво компа, и которому ядро пересобирать просто нету времени? Намекнул разок мол "юзай линукс" - он меня так далеко послал, что я до сих пор не решаюсь отправиться в то место. Вот он пользует винду какую-то, и оборудование, которое само по-себе риал-тайм, причем железный риалтайм, и доволен. Оть так :(

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

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

А как они дальше будут проводить согласование реалтайма с прочими принципами и приоритетами, наверно время покажет.

Именно, недавно осиливший md5, понимаешь разницу в словах "не совпадать" и "противоречить"?

Короче смысл в том, что теперь музыканту для работы придется рюхать распределение ресурсов и программирование RT-приложений на уровне ядра 8-)

> не так, отклик системы будет быстрее за счет общей > производительности системы

Это вообще о чем и каким раком относится к RT? 8=) Общая производительность - скорость процессора что-ли?)) А что такое отклик системы oO

> А как они дальше будут проводить согласование реалтайма с прочими принципами и приоритетами, наверно время покажет.

Есть маза, что принципы RT будут в сильном противоречии с прочими принципами. И уж тем более было смешно читать про необходимость RT для мультимедии 8)

>Есть маза, что принципы RT будут в сильном противоречии с прочими принципами. И уж тем более было смешно читать про необходимость RT для мультимедии 8)

Меньше мазаться нужно и не будет смешно читать...
Как может работать синтезатор звука и наложение всяческих звуковых эффектов на воспроизводящийся звуковой поток без RT?
Хотя под мазой может быть и без RT покатит ;)

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

> Только вот нормальных аналогов Logic Audio и Cubase SX нет...

Ну если это основное препятствие для сочинения музыки... :)

>Человек так устроен, что к этому он чувствителен гораздо меньше. Кроме того, "графическую подсистему" можно довести до RT, если нужно (хотя это вряд ли нужно - ну не улавливает глаз задержки в несколько мс, которые улавливает слух). И живет она большей частью в userspасе.

Это наверное для каких-то особо специализированных музыкальных установок нужно RT. Был на Lounge-fest в Архангельском в этом году, так сэмплировщик пускал звук с двух маков. Все вещи типа добавления дорожек и прочего он делал вживую.