Проблемы при выключении узла из сети QNX4

[LH]

Имеется пять узлов с QNX4, соединенных в дублированную qnx-сеть. Все узлы "видят" друг друга. Логическая сеть 1 и 2
образуются подключением соответствующих сетевых карт каждого узла к отдельному коммутатору.

Программа nameloc запущен на каждом узле.

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

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

Команда sin net задумывается на несколько секунд перед началом вывода.

Через некоторое время ( 10 минут ) работа оставшихся в сети узлов нормализуется.

В чем может быть причина?
Похоже на nameloc?
Какие пути решения?

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

Спасибо.

[LH]

Сегодня попробовал запускать nameloc с ключами

nameloc -S -s1 -e5 &

Никак не помогло, описанный выше эффект замедления остается.

[deadarcher]

Из личного опыта: немного разгрузить ситуацию можно, добавив к параметрам драйверов имеющихся сетевых карт ключей -n2 -t2.

[Василий Дмитриев]

еще можно поиграть  -t от Net. И вообще, дублированная сеть, по личному опыту, дублированный тормоз:)

[LH]

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

В течение 10 минут после выключения другого узла из сети qnx4 выполнение
ф-ции qnx_name_locate() существенно замедляется если не блокируется.

Как мне представляется - по вине nameloc.

[LH]

Применение -n2 -t2 для сетевого драйвера действительно смягчает проблему, но не решает ее полностью.

Почему тогда не сделать -n1 -t1 ?

По умолчанию используемые интерфейсы с Net.e1000 работают со скоростью 1Гбит, а применяется для связи между узлами
коммутатор со скоростью 100 мБит.

Требуется ли принудительно перевести Net.e1000 на пониженную скорость, соответственно скорости
коммутатора, или сетевая плата и "коммутатор" договариваются самостоятельно?

[deadarcher]

Коммутатор и сетевушка сами договорятся и будут на 100 работать. Хотя у нас иногда приходилось принудительно ставить ключ -s100 а то ерунда случалась. А ещё нам пришлось придумать такую штуку, типа широковещательного опроса с головного узла остальных. И как только определенный узел уходил, всем остальным рассылалась команда удалить его сетевой адрес. Правда у нас узлы уходят без возможности снова придти. Удаление сетевого адреса происходит из кэша Net а не из /etc/config/netmap. Это очень хорошо разгружает ситуацию замедления опроса через nameloc. Может сумбурно написал, ну как смог.

[LH]

Спасибо за интересную идею!

Правильно ли я понял, что "удаление сетевого адреса из кэша Net" производится
командой

#netmap -f file2 ,

где file2 - новый состав узлов в сети?

[deadarcher]

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

# netmap -m "d node_number"

При этом удаляется узел node_number по всем сетям. Удаление можно делать на тех узлах, где nameloc крутятся или где name_locate вызывается для поиска в сети.

[deadarcher]

Вспомнил ! В вашем случае можно не удалять адреса, а делать на них mask. У нас удаление сделано просто из-за незнания о mask. Посмотрите справку use netmap, там есть подсказка как это сделать.

[LH]

Описанный Вами метод работает в случае выключения работающего i-го узла из сети.

Проверку наличия узлов делал командой

#alive -uf

При потере узла i ставил маску:

#netmap -m "m i" ( i - номер узла )

Но при возвращении i-го узла в сеть команда alive его уже не видит : узел замаскирован.

Не могу сообразить, каким образом определять возврат i-го узла в сеть, если он ранее
был замаскирован командой netmap.

спасибо.

[deadarcher]

Здесь уже не подскажу. Только если узел при включении сам будет о себе сообщать исполняя удаленно на других узлах размаскирование типа on -n j netmap -m " u i "

[LH]

Перечитываю netmap описание

Deleting vs masking
Deleting a mapping allows the map_entry to be reused, while masking an entry ties up the entry, preventing its reuse.

Похоже что я ошибочно маскировал , а не удалял (как Вы и предлагали !!),  описания ушедших из сети узлов. М.б. при возврате узлов в сеть их описания будут восстанавливаться автоматически?  Нужно будет проверить.

Еще получил оригинальное предложение от Hugh Brown. Полное описание здесь:
http://community.qnx.com/sf/discussion/do/listPosts/projects.community/discussion.qnx4_community_support.topc23930?_message=1375110723049

Обескуражен последним замечанием:

You must not have the same netmap file on every node. On node 1 the netmap
file should have nodes 2,3,4 & 5 in the netmap file, and on node 2 the
netmap file should have nodes 1,3,4 & 5 etc.

В предыдущих проектах на нескольких узлах сети использовал одинаковый /etc/config/netmap,
который запускался командой

netmap -f

в sysinit.*, причем на каждом узле был такой же как на других узлах netmap,
описывающий конфигурацию сети как других узлов, так и текущего узла.

Вроде все работает правильно и очень давно...

Почему указано такое ограничение: в /etc/config/netmap текущего узла описывать
конфигурацию только других узлов в сети, но не текущего узла?

Спасибо.

[deadarcher]

Кстати да, не подумал об этом - может их действительно стоит удалять. Ведь если на 5ом узле будет nameloc и netmap'ы везде одинаковые, то при включении узла в сеть nameloc сам постучиться ко всем и запишется ко всем.

[LH]

Извините, так и не понял: что плохого в том, что в /etc/config/netmap текущего узла, кроме интерфейсов других узлов, описаны интерфейсы текущего узла ( т.е. в том, что netmap на всех узлах один и тот же ).

Буду признателен за пояснение.

Проверил : после проверки alive наличия каждого узла сети и обнаружения "потери" к-либо i-го узла, стоит удалить его описание командой :

#netmap -m "d i"

После этого замедления сети (длительностью 10 минут)  из-за  nameloc не наступает.

После включения узла , его информация автоматически восстанавливается в netmap других узлов и все вновь
"видят" друг друга...

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

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