Официальный форум СВД Встраиваемые Системы
10 Декабря, 2016, 15:44:25 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.

Войти
 
 
 Сайт СВД ВС  Начало   Помощь Поиск Войти Регистрация  
Страниц: [1]   Вниз
  Печать  
Автор Тема: Как работает SRR в QNX4?  (Прочитано 1126 раз)
LH
Опытный пользователь

Сообщений: 254


« : 26 Июля, 2011, 03:59:06 »

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

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

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

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

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

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

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

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

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

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


Записан
Андрей Сеньков
Администратор
Опытный пользователь

Сообщений: 262



WWW
« Ответ #1 : 26 Июля, 2011, 13:12:09 »

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

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

LH
Опытный пользователь

Сообщений: 254


« Ответ #2 : 27 Июля, 2011, 04:05:28 »

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

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

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

Сообщений: 262



WWW
« Ответ #3 : 27 Июля, 2011, 10:06:51 »

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

Chausov
Интересующийся

Сообщений: 5


« Ответ #4 : 28 Июля, 2011, 10:10:03 »

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

Сообщений: 254


« Ответ #5 : 29 Июля, 2011, 19:40:04 »

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

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


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

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

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

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

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

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


Записан
Chausov
Интересующийся

Сообщений: 5


« Ответ #6 : 30 Июля, 2011, 22:26:41 »

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

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

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

Сообщений: 254


« Ответ #7 : 31 Июля, 2011, 04:56:05 »

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

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

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

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

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

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

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



Записан
Chausov
Интересующийся

Сообщений: 5


« Ответ #8 : 01 Августа, 2011, 08:20:40 »

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

Сообщений: 254


« Ответ #9 : 01 Августа, 2011, 09:16:41 »

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

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

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

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

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

Сообщений: 5


« Ответ #10 : 01 Августа, 2011, 12:08:54 »

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

Сообщений: 254


« Ответ #11 : 02 Августа, 2011, 03:13:08 »

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

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

Надеюсь - до следуюшего жаркого лета Smiley.
Записан
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  

Powered by MySQL Powered by PHP © 2002-2016 СВД Встраиваемые Системы.
При использовании материалов сайта ссылка на forum.kpda.ru обязательна.

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines | © Aiwan. Kolobok smiles | Sitemap
Valid XHTML 1.0! Valid CSS!
Сайт СВД ВС

В последний раз google посещал эту страницу 05 Ноября, 2016, 19:26:06