Страниц: 1 2 3 [4]
  Печать  
Автор Тема: Прошу помочь  (Прочитано 8526 раз)
PoP
Sr. Member
****
Offline Offline

Сообщений: 336


Просмотр профиля
« Ответ #45 : Декабря 04, 2015, 02:45:26 pm »

Впечатлили возможности инструментов QNX- c одного рабочего места я с помощью –on, -sin практически диагностировал всю систему.
Это не заслуга инструментария, а следствие общей идеологии QNX. Все сообщения передаются через ядро, есть глобальная система имён. При этом сеть становится прозрачна для родных для системы механизмов передачи сообщений (конечно не сама по себе, а, видимо, после значительных усилий). Зато приложению всё равно, где находится его адресат:
процесс 1 <===========> ядро <===========> процесс 2
процесс 1 <==> ядро 1 <=> сеть <=> ядро 2 <==> процесс 2
Ну, за исключением временных нюансов и надёжности в целом.

Ну, а отключение второй сети могло быть по многим причинам. Например - появление дублей сообщений при каких-то затыках на хабе. Или наоборот, недопустимо долгово времени реагирования на обрыв сети (4-а догадывается что узел больше не доступен через несколько секунд после выдёргивания соответствующего разьёма).
И, конечно, усложнение ПО. Насколько я знаю, само ядро резервирование не поддеживает. Просто пихнёт данные в любую доступную (по его мнеию) сеть. И будет пихать чтото туда чтото сюда, пока не поймёт через свои, достаточно редкие служебные запросы что одной сети уже нет (а может и непоймёт никогда, посчитает за сбои). Для QNX вторая сеть это не резервная линия как в MIL или AFDX. Это просто расширение канала вдвое. По хорошему, нужно городить свою систему контроля на сырых пакетах, привязанных к конкретному номеру сети и удалять из netmap соответствующие записи.

P.S. В принципе я в эту сторону глубоко не рыл. По крайней мере для 4-ки, помоему, только так. Если не прав - поправьте, если кто имел подобный опыт.
Записан
KLM
Участник
*
Offline Offline

Сообщений: 24


Просмотр профиля
« Ответ #46 : Декабря 04, 2015, 07:39:24 pm »

Да… Понял, что не всё так просто, как в книжках… А если ещё учесть критическую длину линий для BASE-2, периодические потери связи, и необходимость связанных с этим фактором перезагрузок системы.    Значит нужен глубокий анализ работы с целью обеспечения бесперебойной работы системы по имеющимся сетям. Иначе получится, что вместо резервирования получится усугубление ситуации. Да и резервированием это не будет. Для чего её тогда «резервной» задокументировали? Вопрос риторический. Теперь понятна причина использования в системе линий MIL-STD-1553 (используются для связи основных вычислительных узлов с АРМ низкой ступени иерархии) наряду с FLEET (на главных АРМ).  Так может стоило резервную линию на MIL сваять, программно исключив параллельную работу вместе с FLEET? Это было бы фактическим, а не фиктивным резервированием.
Записан
PoP
Sr. Member
****
Offline Offline

Сообщений: 336


Просмотр профиля
« Ответ #47 : Декабря 05, 2015, 09:59:22 pm »

Возможно, её планировали сделать резервной, внесли в документацию и ТЗ, но чтото непошло или времени отладиться нехватило. Ну и решили проблему гениально просто ...
А те, кто всё это принимал, недодумались/поленились открутить разём. Или их уговорили забыть.
У нас всегда то, что можно попробовать оторвать - отрывают, то, без чего должно продолжать както работать - выключают. И всё это в самых невероятных комбинациях.
Записан
Страниц: 1 2 3 [4]
  Печать  
 
Перейти в: