Как работает SRR в QNX4?

[LH]

У нас имеются измерительные системы, состоящие из нескольких промышленных ПК, объединенных в QNX-сеть.

На первом ПК работает программа-сервер параметров. На других ПК работают программы обслуживания АЦП, плат дискретного ввода и т.п.,
которые объединяют результаты измерения в структуру известного формата ( тип сообщения. число данных, и далее наборы номер измеряемого параметра-его значение )
и отправляют эти данные в программу-сервер параметров синхронными SRR-сообщениями. Частота отправки таких сообщений примерно 10-100 раз в секнду каждой
программой-измерителем.

Такая схема работает много лет и до вчерашнего дня  сомнений не вызывала.

Вчера же обнаружилось, что изредка в программу-сервер поступают сообщения с искаженной структурой данных. Это происходило раз в 2-10 секунд случайным образом.
Искажение фиксировалось программой-сервером в том, что номера измеряемых параметров имели неправильное значение. Искаженные пакеты поступали от разных программ-измерителей с разных узлов.

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

После выключения, очистки фильтров, 20-ти минут остывания и последующего включения т-ра нормализовалась до 37С и ошибки прекратились.

Не понимаю : как объяснить происшествие. 

Если предположить, что отправленные через QNX4-сеть сообщения из-за сбоев сетевой платы искажались и доходили до получателя
испорченными, то выходит что FLEET-протокол не занимается проверкой правильности сообщений с помощью контрольной суммы.

Не думал, что контрольную сумму нужно вводить в само тело прикладных SRR-сообщений, а ее проверку выполнять после принятия
каждого сообщения...

Спасибо за поддержку в данном вопросе.

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

Каждый Ethernet кадр снабжен контрольной суммой в соответствии с форматом Ethernet II. Как правило, сверка CRC выполняется аппаратно сетевым контроллером. Протокол FLEET не предполагает дополнительного контрольного суммирования данных.

Передаваемые данные могут исказиться из-за ошибок в функциональном ПО.

[LH]

Я бы сам не поверил описанному случаю, если бы не видел все своими глазами.

Можно ли допустить, что в следствие перегрева Ethernet - интерфейс начал работать со сбоями и передавать данные в драйвер с
искажениями?

По моим наблюдениям примерно из 100-500 сообщений в секунду из разных программ-измерителей с разных узлов неправильные
сообщения приходили раз в 1-5 секунд случайным образом.

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

Если есть подозрения на ошибки в работе Ethernet-адаптера, можно попробовать его заменить или протестировать, например, с помощью тестов netperf

[Chausov]

Можно ли уточнить:
Тип контроллеров (оборудования)
Размер сетевого пакета

[LH]

Оборудование:
- системная плата PCA-6179VE-02A1 со встроенным сетевым контроллером ( Qnet сеть с логическим номером 1);
- сетевая плата RE100ATX/WOL (УСО RE100ATX/WOL для дублирующей (логический номер 2 ) Qnet- сети.

Для обоих сетевых интерфейсов применяется Net.rtl


При работе контроллеров в нормальном температурном режиме программные сбои отсутствуют.

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

Одни и те же программы-измерители работают на разных контроллерах в Qnet-сети, в том числе и на том, где работает программа-сервер данных.
Заметил, что сбойные данные приходили в программу-сервер только от программ-измерителей, работающих на других контроллерах, т.е. через Virtual Circuit.

Поэтому основное предположение об ошибках при передаче данных в виде SRR сообщений через сеть.

У нас программа-сервер работает так, что если в 1-м байте принятых по Receive() данных вместо
значения 2 принять ошибочно 3, то это приведет к сбою обработки данных, похожему на тот что наблюдался при
"перегреве".

Ломаю голову: неужели Net.rtl + интерфейс на такое способны?

[Chausov]

Мне сложно предположить что происходит, но поделюсь следующими мыслями:

Часто промышленные контроллеры (особенно Advantech) при повышении
температуры понижают частоту процессора.

Возможно это приводит к возрастанию размера сетевого сообщения.
В файле limits.h есть параметр _QNX_MSGLEN = 65500U максимальная длина
сетвого сообщения.
Но это не так. В реальности максимальная длина на 142 байта меньше.
И если этот лимит превышен то принятые последние байты не соответствуют переданным,
что может привести к непонятным, на первый взгляд ошибкам.

[LH]

Спасибо за сообщение.

К сож. это не мой случай.

От измерителей приходят более короткие сообщения: 2 байта - тип данных, 2 байта - число данных и потом по количеству данных пары
значений : номер параметра ( 2 байта ) и код АЦП - 4 байта.

На один АЦП приходится 32 канала, так что максимум 2+2+6*32= 196 байт. Данные от АЦП приходят минимум 10раз в сек. Сбои в обработке данных были случайными, от разных измерителей и примерно через 1...6 секунд.

Ошибка регистрировалась при "нереальном" номере параметра. Если номер параметра попадал
в допустимый диапазон - то код АЦП не проверялся и система пропускала "нереальные" измерения.

Если сбой был в одном бите 1-го байта ( вместо 3 приходило 2 ), то программа ожидала приход других пар данных : 2 байта - номер параметра, 2 байта - целое значение кода АЦП. В этом случае сбой с номерами параметров понятен.

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

[Chausov]

Мне кажется что проблема в контроллерах (возможное понижение тактовой частоты),
а не в сервере.
Можно ли узнать марку контроллеров и версию QNX установленную на них.

[LH]

Кажется проблема в терминологии.

Аппаратный уровень.
Измерительная система состоит из 4-х контроллеров, связанных дублированной Ethernet-сетью. В каждом из них используется указанное выше оборудование. Системная плата PCA-6179VE-02A1 , сетевая плата RE100ATX/WOL и еще разные платы АЦП, дискретного ввода и т.п.

Программный уровень.
ОС QNX4.25 на всех контроллерах. На контроллере с логическим номером узла 1 работает программа-сервер. На контроллере с логическим номером 1,2,3,4 работают программы-измерители, которые шлют сообщения в программу-сервер.

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

Наши электронщики сомневаются в возможном понижении тактовой частоты при нагреве.

[Chausov]

На стемной плате PCA-6179VE-02A1 понижения частоты нет.
Эффект очень интересный. Но мне кажется что дело не в искажении сетевых пакетов,
иначе рушилась бы вся сеть и узлы были бы не видны или то появлялись то исчезали.
Файлы копировались с ошибками и т.п.
Можно ли повторить эксперемент, повышая температуру одного из узлов - например
накрыв его целлофаном.

[LH]

Элекктронщики против.

Буду ждать следующего проявления сбоев. За прошедшую сбоев не было...

Надеюсь - до следуюшего жаркого лета .