Теоретический вопрос

Имеется проблема с переходом на новое поколение контроллеров.
Прокомментируйте, пожалуйста.

Допустим, имеется 10-20 современных контроллеров, поддерживающие обмен данными через сеть Ethernet. Например, типа WinCon-8000 (IPC-DAS) или Compact FieldPoint (NI) или даже ADAM 5510/TCP (Advantec). Подключаем их через хаб к компьютеру верхнего уровня АСУТП.

1) Как оценить реальное быстродействие сети? Меня смущает то, что технология Ethernet не обеспечивает хорошей скорости при передаче большого количества мелких файлов. Если требуется отслеживать процесс через каждые 0,5 - 1 с, то не получится ли так, что сеть "забъется" мелкими пакетами?

2) Возможен ли обмен данными между контроллерами, минуя компьютер верхнего уровня, и как это скажется на быстродействии сети? В сетях на основе RS485 присутствовал один мастер. Обмен данными в сетях на основе Ethernet предполагает не только связь "один ко многим" (компьютера верхнего уровня с контроллерами), но и обмен данными между контроллерами, тем более, если собраны в одном-двух шкафах.

3) Может более правильно "контроллеры с мозгами" (с Win CE, Linux) не плодить в шкафах, а использовать их по 1 штуке в каждом шкафу для управления "безмозглыми" корзинами с модулями ввода-вывода, которые подключают к ним по RS485?

Спасибо.

У меня нет контроллеров.

Связь из скада (LabVIEW DSC) с другим компьютером делал. Пока на обоих компьютерах работают только эти программы, все нормально: программный генератор меандра практически синхронно (я, как homo sapiens, не видел разницы) управляет индикатором на своем и на удаленном компьютере. Достаточно на одном из компьютеров запустить емкий процесс, или нагрузить сеть небольшим обменом по виртуальному СОМ порту (ADAM 4570), как синхронность (детерменизм) нарушается.

10Гбит/с Вам мало

Попробуйте с одного компа по сети копировать файлы на другой.  Ручаюсь, что файл объемом 1 гигабайт за одну секунду вы не скопируете.

Поэтому все эти сорости оччень лукавые.

 

Первоначально опубликовано _mrv Имеется проблема с переходом на новое поколение контроллеров. Прокомментируйте, пожалуйста. Допустим, имеется 10-20 современных контроллеров, поддерживающие обмен данными через сеть Ethernet. Например, типа WinCon-8000 (IPC-DAS) или Compact FieldPoint (NI) или даже ADAM 5510/TCP (Advantec). Подключаем их через хаб к компьютеру верхнего уровня АСУТП. 1) Как оценить реальное быстродействие сети? Меня смущает то, что технология Ethernet не обеспечивает хорошей скорости при передаче большого количества мелких файлов. Если требуется отслеживать процесс через каждые 0,5 - 1 с, то не получится ли так, что сеть "забъется" мелкими пакетами? Спасибо.

Какое сетевое оборудование используете?

Что вы имеете в виду под "мелкими пакетами"? Размер пакета не зависит от размера файла и их количества. Задержки при передаче мелких файлов - следствие работы операционной системы на уровне приложения. Это не имеет отношения к передаче данных по сети.

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

По факту прекрасной работы я не наблюдал ни разу.

Если (ненастраеваемое сетевое оборудование) имеет возможность объединения в мануале соединение называеться тренковым и так же указыветься что вслучае его выполнения устанавливаеться не только канал повышенной пропускной способности но и общаяя таблица маршрутизации, что позволяет устанавливать соединение точка точка в моммент установления канала в противном случае свич работает как тупой репитер (хаб)  и по факту при таком подключении сеть работает криво. Если вы используете монтируемую файловую систему то вообще труба, юзверь ревет как раненный медведь. Возможно при использовании более дорого и умного оборудования например CISCO этого всего можно избежать, НО я не имею возможности его использовать а значит невижу смысла углубляться в теорию. В любом случае мной были указаны возможные причины сетевых проблем, в том числе и архитектурные с которыми я сталкивался в своей работе. Если вы хотите обсудить детально аспекты работы сетевого и канального уровня это не ко мне сорри...