Влияние ошибок при передаче данных по сети QNX4

[LH]

В ОС QXN4 утилита netinfo регистрирует некоторое количество ошибок при передаче
данных по сетевому интерфейсу ( вывод во вложении ).

Можно ли предположить, что в результате данных ошибок можгут быть
искажены данные сообщения, отправляемого процессом c одного узла
процессу на другом узле с помощью механизма Send-Receive-Reply через сеть?

Спасибо.

[Андрей Сеньков]

Здравствуйте!

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

[LH]

Результаты тестирования выложены в папку
https://yadi.sk/d/MLlRgi-2hEHTE

В папке:
- текст t_msg.c
   клиент собирается $cc -o t_client -D CLIENT t_msg.c
   сервер собирается $cc -o t_server -D SERVER t_msg.c

- отчеты программ сервера и клиента в srv_log.txt и cli_log.txt

- отчеты netinfo по работе интерфейсов 2-й логической сети в netinfo_1.txt (1 контроллер ) и netinfo_3.txt ( 3 контроллер )

- фото коммутаторов 1-й(слева) и 2-й(справа) логической сети

- фото экрана с отчетом программы-клиента

- отчет sin ver с версиями системных программ на 3-м контроллере.

Сетевые интерфейсы 1-го и 3-го контроллеров  2-й логической сети работают с небольшим количеством
ошибок (см. отчеты netinfo_1(3).txt).

Программа-сервер запускалась на 1 контроллере, клиент - на 3 контроллере.

В ходе тестов клиент примерно 200 раз в сек. передает в сервер около 10кБ данных с подсчетом контрольной суммы,
в ответ сервер возвращает другие данные такого же объема с подсчетом контрольной суммы.

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

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

Предположение  Андрея Сенькова не подтверждается: физические ошибки сети проникают в данные на прикладном уровне.

P.S.
С подобной проблемой сталкивались ранее:
http://forum.kpda.ru/index.php/topic,587.0.html

но тогда не тестировали с проверкой контрольных сумм передаваемых данных.


В чем я не прав и что делать?

Cпасибо.

[Андрей Сеньков]

Приведите дополнительно вывод утилиты netinfo (без параметров) после возникновения ошибок.

[deadarcher]

И опять рилтеки. Ощущение, что они (сетевушки) пакет принимают правильный а выше передают уже битый.

[LH]

Приведите дополнительно вывод утилиты netinfo (без параметров) после возникновения ошибок.

Прикладываю к сообщению

[deadarcher]

В файле netinfo_n3.txt :

Код:

10:55:03 2   FFCF01 000000 (293) 
10:55:03 2   00E04D 08407A (3128) rtl ( rx) some packets missed, txing NACK
10:55:03 2   Status 468    (1099) 
10:55:03 2   FFCF01 000000 (1099) 

Видите эти MAC-адреса ?  Вопрос к сотрудникам: как-то можно прокомментировать эту ситуацию ?
Просто не понятно как трактовать подобные вещи.

[LH]

Такого MAC-адреса среди интерфейсов второй логической сети нет ( netmap пирилагаю ).

Разве что смешать 2-ю часть MAC-адреса 2-го и 4-го контроллера 

Вообще по логике работы проекта и проводимого дополнительно теста, третий контроллер обращается
сообщениями к 1-му контроллеру, но не ко 2-му и не к 4-му.

[deadarcher]

с такими МАС-адресами приходят, мне думается, искажённые пакеты. Вот только на каком этапе информация искажается ?  Битый пакет должен быть отброшен драйвером ?  Должна информация о таком событии отображаться в netinfo ?
Просто наблюдал и наблюдаю эпизодически подобные ситуации. У нас тоже два сетевых интерфейса с драйвером Net.rtl. И когда "электронщики" спрашивают что конкретно не работает, не знаю что ответить.

[LH]

У нас тоже два сетевых интерфейса с драйвером Net.rtl. И когда "электронщики" спрашивают что конкретно не работает, не знаю что ответить

Ваши два сетевых интерфейса со сбоями в отчете netinfo находятся в одной QNX4 - сети?

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

Подтверждение/опровержение экспериментальных данных всегда полезно...

Пробовали ли Вы на тех же контроллерах под Windows тестировать "сбойные" сетевые интерфейсы с помощью xchariot
или подобных средств с регистрацией ошибок передачи по сети?

спасибо.

[Андрей Сеньков]

Сообщение вида:

Код:

10:55:03 2   00E04D 08407A (3128) rtl ( rx) some packets missed, txing NACK

говорит о том, что драйвер Net.rtl зафиксировал ситуацию, когда были потеряны один или несколько предыдущих пакетов во FLEET последовательности.

Наблюдаемое также сообщение вида:

Код:

(3163) rtl ( rx) RX Unit Reset.

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

Подобные выводы могут свидетельствовать и об аппаратных проблемах с сетевым адаптером.

[LH]

Остаются вопросы:

- почему аппаратные ошибки сетевых адаптеров приводят к искажению  данных при обмене посредством Send-Receive-Reply (SRR) между
прикладными программами в сети QNX4?

- обязано ли ответственное прикладное ПО иметь собственный механизм проверки целостности данных при обмене в QNX4
сети посредством SRR?

[deadarcher]

Ваши два сетевых интерфейса со сбоями в отчете netinfo находятся в одной QNX4 - сети?
Пробовали ли Вы на тех же контроллерах под Windows тестировать "сбойные" сетевые интерфейсы с помощью xchariot или подобных

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

[LH]

Не, оба интерфейса в разных и логических и физических сетях.

Оказывается, ошибки происходят при обмене по сети и с одной неисправной сетевой платой.
Запустил t_server на узле 2 (исправная сетевая плата) и t_client на узле 3 (неисправная сетевая плата).

Отчеты по тесту прикладываю в архиве.

В t_msg.c внедрил более быстрый алгоритм подсчета контрольной суммы CRC16

Приглашаю deadarcher к проведению теста и публикации результата.

[LH]

Повторил тест с использованием второй неисправной сетевой платы ( на узле 1 ) и исправной ( на узле 2 ).
Результаты в err_2015_25.zip

Ошибки проявились и с другой неисправной платой.



Повторил тест с использованием последней версии драйвера Net.rtl 4.25D от 14 мая 2010 года.
Результаты в err_2015_27.zip

С последней версией драйвера тест по-прежнему демонстрирует ошибки на прикладном уровне при
отправке-приеме сообщений.