Страниц: 1 ... 5 6 [7] 8
  Печать  
Автор Тема: Чем QNX лучше FreeBSD Embedded?  (Прочитано 43687 раз)
Аноним
Гость
« Ответ #90 : Ноября 29, 2003, 09:20:36 pm »

2Аноним №1
Собрались тут намедни ваять встроенную систему. И головное предприятие возжелало видеть в ней QNX. А знаешь почему? А потому что:
1. Есть организация (QSSL), которая обеспечивает поддержку своей ОС. Поэтому если меня уволят, то вполне можно будет найти специалиста, который будет обслуживать систему в дальнейшем.
2. Если что-то случится по причине ошибки в ОС (а в любой программе есть ошибки, в QNX тоже), то будет на кого иск подавать. Едва ли кто-то из местных начальников захочет подставлять свою голову.

А от системы нашей, кстати, реальности времени не требуется. Требуется надёжность.
Дорого ли $15000? Подсчитай сам, если известно, что на весь проект выделено $500000000...
Записан
Vlafy
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #91 : Ноября 29, 2003, 09:22:04 pm »

Сорри, последний Аноним - это я. Забыл авторизоваться.
Записан
ee
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #92 : Ноября 30, 2003, 01:02:27 am »

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

флаг в руки, барабан на шею. Только не забудьте лицензию прочитать.
Аноним
А от системы нашей, кстати, реальности времени не требуется. Требуется надёжность.
Дорого ли $15000? Подсчитай сам, если известно, что на весь проект выделено $500000000...

это называется - "зажрались". Надежность обеспечивается совокупностью систем/мероприятий.
В том числе таким дурным, как опыт разработчиков. Т.е. если допустим они всю жизнь писали на паскале и под досом, то при переходе на си и под QNX....обеспечен гемморой года на три..
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #93 : Ноября 30, 2003, 04:38:00 pm »

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


На "на паскале и под досом" вполне допустимо писать все беззаботные студенческие годы... ;-)
А если "всю жизнь"? то это и вправду очень дурной опыт.
Может заказчику проще... "сменить круг общения"?

А вот если разработчики писали под С/С++, да интересовались, а ещё лучше под POSIX - то "геморою" - на пол-года, и можно приступать к реальной работе над проектом.
Записан
ee
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #94 : Декабря 01, 2003, 12:30:21 am »

Olej
На "на паскале и под досом" вполне допустимо писать все беззаботные студенческие годы... ;-)
А если "всю жизнь"? то это и вправду очень дурной опыт.
Может заказчику проще... "сменить круг общения"?

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

Хотя наверное грамотному заказчику действительно стоит менять круг общения - если например, исполнители вносят в реализацию проекта более 2х принципиальных новшеств, по сравнению с предыдущим, или если реализация типа "на паскале под досом" или "система документооборота под qnx."
Записан
leitAlex
Участник
*
Offline Offline

Сообщений: 2


Просмотр профиля
« Ответ #95 : Декабря 01, 2003, 02:38:01 am »

Прочитал сейчас все за раз (только у меня страницы и даты как-то перемешались) и показалось мне, что не очень заострились на двух моментах.
1. Любая сложная система имеет вероятностный характер. С учетом ,ессно, вероятности поступления внешних воздействий. Далее понятно....
2. Нигде я не прочитал о том, как должна вести себя реалтайм система если ей не хватает времени. Сейчас этим занимается каждый за себя, а хотелось бы как-нибудь по-простому. Пример: если у меня задержка в обработке превысит 40мкс, то я попадаю сразу на 20 баксов. Для меня это жесточайший реалтайм. А вот если я в метро сунул в турникет карточку, а она там задержалась, скажем на лишних 1.5 сек., то для меня это реалтайм мягкий. (Хотя через 5 сек я уже заору).
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #96 : Декабря 18, 2003, 06:18:29 pm »

Во-вторых, решая проблему инверсии на трех процессах (потоках), в QNX остается инверсия на четырех и более процессах - Роб прямо указывает на это в первой половине стр.200

Сделал я проверку этого утверждения...
Кому интересно - можете посмотреть здесь:
http://qnxclub.net/modules.php?name=Forums&file=viewtopic&t=16&start=15
Это принципиально меняет картину!

По моему предположению:
- Р.Кёртен в этом месте: либо ошибался, либо не проверял то, что утверждал, либо проверял, но на какой-то ранней промежуточной версии QNX (я всё делал только для QNX 6.2.1 - что происходит в других релизах я не могу сказать).
Записан
Evgeniy
Jr. Member
**
Offline Offline

Сообщений: 73


Просмотр профиля
« Ответ #97 : Декабря 18, 2003, 10:37:06 pm »

Olej
Во-вторых, решая проблему инверсии на трех процессах (потоках), в QNX остается инверсия на четырех и более процессах - Роб прямо указывает на это в первой половине стр.200

Сделал я проверку этого утверждения...
Кому интересно - можете посмотреть здесь:
http://qnxclub.net/modules.php?name=Forums&file=viewtopic&t=16&start=15
Это принципиально меняет картину!

По моему предположению:
- Р.Кёртен в этом месте: либо ошибался, либо не проверял то, что утверждал, либо проверял, но на какой-то ранней промежуточной версии QNX (я всё делал только для QNX 6.2.1 - что происходит в других релизах я не могу сказать).


Хотя в цитируемом вами фрагменте речь о другом, но это не очень важно.
А важно то, что если ваши результаты правильные (надеюсь, что так), то неизвестно хорошо ли это.
В этом случае проектирование многомашинных систем в плане распределения приоритетов должно идти как мультипроцессорных, т.е. распределять приоритеты надо глобально во всей системе, а сегодня, на сколько я понимаю, это делается для каждой машины независимо в рамках ее группы программ...
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #98 : Декабря 19, 2003, 01:32:42 am »

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

Как раз хотел это отметить: да, если в сетке TCP/IP процессы на каждом узле могут распланироваться автономно и независимо от других хостов, то в QNET - все процессы системы должны планироваться как одно целое.
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #99 : Января 05, 2004, 04:10:27 pm »

Хотя в цитируемом вами фрагменте речь о другом, но это не очень важно.

А вот теперь, спасибо за замечание - сделал проверку точно того, о чём пишет Роб: наследование приоритетов при последовательном транзитном запросе от 1-го менеджера к другому... или более по-цепочке.

Всё-таки Роб в том абзаце - неправ: происходит наследование приоритета первоначально запросившего клиента всеми последовательно менеджерами, кто потребуются для обслуживания запроса (по крайней мере - в 6.2.1!). Кто не верит, см. здесь:
http://qnxclub.net/modules.php?name=Forums&file=viewtopic&t=16&start=15

- в конце, несколько сообщений, после 21.12.2003.
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 470



Просмотр профиля
« Ответ #100 : Января 06, 2004, 12:54:19 am »

Olej
Всё-таки Роб в том абзаце - неправ: происходит наследование приоритета первоначально запросившего клиента всеми последовательно менеджерами, кто потребуются для обслуживания запроса (по крайней мере - в 6.2.1!). Кто не верит, см. здесь:


Сам Роб на это ответил очень просто:

That should be a fairly simple 5 minute test program, I would imaging


Т.е. смысл понятеy?
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #101 : Января 07, 2004, 12:45:09 pm »

dmi, вопрос не в том, кто что ответил и т.д., а в том - что там происходит на самом деле. Это слишком принципиальная позиция, особенно для потоков на нескольких узлах QNET - на этом (наследование приоритетов) вся realtime-овость OS держится: нет никаких иных принципиальных отличий RTOS от GOS!
Записан
Evgeniy
Jr. Member
**
Offline Offline

Сообщений: 73


Просмотр профиля
« Ответ #102 : Января 07, 2004, 05:23:23 pm »

Olej
dmi, вопрос не в том, кто что ответил и т.д., а в том - что там происходит на самом деле. Это слишком принципиальная позиция, особенно для потоков на нескольких узлах QNET - на этом (наследование приоритетов) вся realtime-овость OS держится: нет никаких иных принципиальных отличий RTOS от GOS!

Да полно, Олег! Хотя знание реального поведения системы и очень важно, но блокировка инверсии, на мой взгляд, совершенно не принципиальна. По той простой причине, что она не может быть полной, работающей при любых взаимодействиях процессов - это неизбежная плата за параллелизм при ограниченности процессорных ресурсов. Более того, в ряде случаев она просто может не соответствовать вашим целям.
Как по мне, так лучше вообще не иметь блокировки инверсии, чем иметь частичную блокировку потому, что такое неединообразие поведения только усложняет анализ системы. А такой анализ все равно проводить необходимо из-за того, что блокировка инверсии происходит не всегда.
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 470



Просмотр профиля
« Ответ #103 : Января 07, 2004, 05:38:22 pm »

Olej
dmi, вопрос не в том, кто что ответил и т.д., а

Мне почему-то показалось обратное

Olej

 в том - что там происходит на самом деле. Это слишком принципиальная позиция, особенно для потоков на нескольких узлах QNET - на этом (наследование приоритетов) вся realtime-овость OS держится: нет никаких иных принципиальных отличий RTOS от GOS!


А доказать?
Подсказка: отключение наследования приоритетов включается с помощью ключика _NTO_CHF_FIXED_PRIORITY при создании ChannelCreate().

P.S.: Ничего _принципиального_ в этом нет, т.к. нет проксирования запросов, поэтому любой канал будет создаваться лишь на один уровень. С наследованием приоритета, да...
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #104 : Января 08, 2004, 04:41:00 pm »

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

Я здесь уже интересуюсь не в применении к инверсии, а безотносительно, только в отношении к наследованию приоритетов: будет вся цепочка последовательных вызовов подтягиваться на приоритет 1-го запросившего обслуживание клиента, или не будет? Тесты показывают, что, якобы - будут.

Подсказка: отключение наследования приоритетов включается с помощью ключика _NTO_CHF_FIXED_PRIORITY при создании ChannelCreate().

То, что с флагом _NTO_CHF_FIXED_PRIORITY приоритеты не будут сдвигаться - это понятно. Вопрос напротив: как они меняются при разрешённом наследовании?
Записан
Страниц: 1 ... 5 6 [7] 8
  Печать  
 
Перейти в: