> я по-прежнему открыт для конструктивного диалога

Хм.

jtootf> планировщик реального времени - completely unfair, гарантии ты получаешь только для высокоприоритетных потоков

Это ты о чем - о SCHED_RR или о SCHED_FIFO? В чем complete unfairness планировщика SCHED_RR?

Ты не мог бы обосновать необходимость выбора между реактивностью и пропускной способностью без использования сомнительных терминов вроде «отзывчивость» («реактивность», «время реакции», «время отклика на событие» - это всё понятные термины)?

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

и в чём же проблема с драйверами?

> L4 - исключение, оно подходит для всего

фанаты-некрофилы пилят OS/2 поверх L4: http://ru.wikipedia.org/wiki/OsFree http://www.osfree.org

> фанаты-некрофилы пилят OS/2 поверх L4

Им слава ReactOS как самой ненужной ОС покоя не даёт.

Это ты о чем - о SCHED_RR или о SCHED_FIFO?

о любом из них

В чем complete unfairness планировщика SCHED_RR?

http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/kernel.html#SCHEDULING

Remember that the FIFO and round-robin scheduling algorithms apply only when two or more threads that share the same priority are READY (i.e. the threads are directly competing with each other). The sporadic method, however, employs a «budget» for a thread's execution. In all cases, if a higher-priority thread becomes READY, it immediately preempts all lower-priority threads.

в случае RT-планирования, равномерное выделение процессорного времени работает только для высокоприоритетных потоков с равным приоритетом. в CFS же наблюдается что-то подобное:

If the task spends a lot of its time sleeping, then its spent time value is low and it automatically gets the priority boost when it finally needs it. Hence such tasks do not get less processor time than the tasks that are constantly running.

в RT-системах priority boost выдаётся не на основании учёта потраченного времени (даже в случае использования спорадического планирования), а исключительно для предотвращения инверсии приоритетов (наследованием или округлением приоритетов, соответственно), что влияет только на реактивность высокоприоритетных потоков - и, вообще говоря, предотвращает повышение реактивности низкоприоритетных

Ты не мог бы обосновать необходимость выбора между реактивностью и пропускной способностью без использования сомнительных терминов вроде «отзывчивость»

я не особо силён в терминологии, каюсь. мой основной посыл в том, что нельзя сделать все потоки одинаково приоритетными (оставаясь в рамках RT-планирования), и получить для них какие-то хорошие гарантии - пользовательские приложения всегда будут иметь приоритет ниже жизненно необходимых потоков (реализующих протоколы, или работу с FS), но никакого priority boost или равноценного выделения процессорного времени для них не предусмотрено

лень перечитывать весь тред. Скажите, а ViengoOS уже сдох? И что там с Хурдом на базе L4?

и свежий глоток хакинтошникам?

L4/Darbat = L4 + Darwin + Wombat

PDF обзорная статья, см. Darbat

> Эммм.... HURD же основан на mach?!

http://www.gnu.org/software/hurd/hurd-l4.html

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

>соляра куда будет предпочтительнее в силу огромного рассового превосходства

у чпукса расовое превосходство еще больше :)

Думаю мы такое не увидем.

>> В чем complete unfairness планировщика SCHED_RR?

http://www.qnx.com/developers/docs/6.3.2/neutrino/sys_arch/kernel.html#SCHEDU...

В пределах одного значения приоритета он completely fair.

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

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

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

если RT-задач вообще нет, что мешает RTOS достигнуть той же производительности, что и GPOS?

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

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

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

> Зенг Да (Zheng Da) разработал новый стек драйверов, который работает на Dresden L4 (Fiasco)

Fiasco

Как вы лодку назовете, так она и поплывет.

>> если RT-задач вообще нет, что мешает RTOS достигнуть той же производительности, что и GPOS?

что такое RT-задача?

Нить с планировщиком, отличным от SCHED_OTHER

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

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

Тогда что вообще означает твоя фраза:

jtootf> реальное время, производительность и отзывчивость - выбрать можно одно из трёх

К чему она относится - к возможностям ОС by design или к возможностям конкретного программно-аппаратного комплекса под ощутимой RT-нагрузкой (RT-нагрузка - это ресурсы, потребляемые RT-задачами, если что)?

>L4/Darbat = L4 + Darwin + Wombat

Тут вы слегка смешали все в кучу - Wombat это паравиртуализованый Linux, так что -Wombat

К чему она относится - к возможностям ОС by design или к возможностям конкретного программно-аппаратного комплекса под ощутимой RT-нагрузкой (RT-нагрузка - это ресурсы, потребляемые RT-задачами, если что)?

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

>> К чему она относится - к возможностям ОС by design или к возможностям конкретного программно-аппаратного комплекса под ощутимой RT-нагрузкой (RT-нагрузка - это ресурсы, потребляемые RT-задачами, если что)?

строго говоря, второе, но работу первого без второго я не представляю

Представь работу Linux, когда патч -rt мигрирует в ядро полностью, и будет включен по умолчанию. Последнее состояние дел, о котором я читал: http://lwn.net/Articles/354690/

Последнее состояние дел, о котором я читал

занятно, особенно абзац про big kernel lock - не представляю, как им это удастся (хотя утверждают, что большая часть работы уже сделана). будем посмотреть

>То есть если поставить QNX на пентиум-75 мегагерц то QNX внезапно перестанет быть реалтаймовой системой?
Если количество поступающих запросов небольшое а задача, которую нужно обработать в режиме жёсткого реального времени быстрая - то будет.

>он прав, кстати. реальное время, производительность и отзывчивость - выбрать можно одно из трёх
В реальном времени могут работать только 1-2 процесса. Остальным хватит обычной многодачности.
Как говорит вики :In more advanced systems, real-time tasks share computing resources with many non-real-time tasks...

В реальном времени могут работать только 1-2 процесса. Остальным хватит обычной многодачности.

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

In more advanced systems, real-time tasks share computing resources with many non-real-time tasks

было бы интересно посмотреть на такую систему

>было бы интересно посмотреть на такую систему

А в чем вы видите проблему ?
http://www.ok-labs.com/solutions/what-is-mobile-phone-virtualization
картинка в центре.

>> In more advanced systems, real-time tasks share computing resources with many non-real-time tasks

было бы интересно посмотреть на такую систему

Linux

ушел из большого спорта так в нем и не побывав

ричарду пора смириться с тем, что он неудачник и прекратить эту агонию.

>> Michael Walker (Майкл Волкер) начал создавать дистрибутив Arch Hurd, вместе с другими Arch разработчиками.

Предатели!

Да нет там никаких разработчиков Arch.
Только Allan McRae им помогал.

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

Линукс когда-то ещё превратится. Hurd — уже. http://walfield.org/papers/200707-walfield-critique-of-the-GNU-Hurd.pdf

Кстати, deadbeef теперь исключение из этого правила.

Ну, похоже это замечательное ядро всё-таки допилят. Драйвера из Linux как пользовательские процессы-это умно. Теоретически, можно дописав нужные модули, даже виндовые дрова пускать как процессы GNU/HURD. И даже целые ядра ОС. В какой-то мере микроядро похоже на конструктор, из которого и гипервизор, и ядро ОС, и что-угодно получить можно. Теоретически можно даже большую часть ядра Linux на модули распилить, и в проекте заюзать. И от BSD можно натаскать кода для модулей. Главное, что-бы основа(само ядро) была допилена. Можно даже Wine переделать, используя его как процесс для HURD, позволяющий задействовать поддержку приложений альтернативной ОС из коробки.

Почему тупой двоешник, приславший статью, так и не исправил ошибку в транскрибировании имени китайца на русский язык? Или орфографические ошибки в новостях на лоре исправлять не принято?

Изучи, кривой неуч снайпер - http://ru.wikipedia.org/wiki/Транскрипционная_система_Палладия .

Отправляйся ка в игнор, школота, неумеющая разговаривать.

Я пробовал. Виснет, если минут пять не печатать на клавиатуре =) И очень порадовало сообщение в инструкции по установке о том, что ГРУБ пока настолько глючный, что они постеснялись его включать в дистрибутив, поэтому поставить систему вы можете, а запустить - ну, если получится...