Вид для печати
Возникли проблемы с быстродействием. Задача собрать с 50-ти систем по 200 сигналов по ModbusTCP (и второй вариант по 104 протоколу) Тормоза уже начинаются на 10-ой системе (т.е 2000 входных регистров). А 104 вообще жуть, даже 100 параметров передать проблема. Кто сталкивался с подобным и как решили проблему.
Тут либо ПК очень мощный, либо систему поменять. Правда вот со 104-м не много наверное наберется, как вариант использовать OPC UA сервер для этого
интересно на какое быстродействие расчитываете? с каким периодом хотите получать данные?Цитата:
Сообщение от volgogaz
примерная прикидка Вашей системы - на коленке:
50 систем по 200 сигналов. не совсем понятно, но допустим это 4 байта каждый сигнал.
это 40 000 байт
насколько я помню, по эзернету 1 байт это примерно 10 бит. без учёта туда-сюда данных TCP (Modbus же TCP)
это на вскидку получается 400 мегабит. Это без учета того, что TCP оно обменивается туда-сюда двумя хэндшейками,
Если он шпарит непрерывно, без остановок.
И что-то мне кажется, что тормоз в этой архитектуре и этих протоколах скорее всего не мастерскада а сначала начнёт тормозить канал передачи данных,
потом начнёт тормозить память, потому что для каждой переменной не просто надо держать память, но ещё и открытый socket,
потом тормозить будет именно операционная система, потому что количество socket оно хоть и пишется что 65535, но больше 2500 редко какая версия windows нормально может держать открытой постоянно - надо серверную винду ставить.
и уже только потом будет вопрос к Мастерскаде.
Всё-таки я бы посоветовал пересмотреть архитектуру и протоколы.
Странный расчет. Может у меня что с арифметикой, но 40 000 байт - это 400 000 бит. Это 400 килобит.Цитата:
Сообщение от Юрий Горелый2
Прошу подтвердить про socket. Вы это точно знаете или подозреваете?Цитата:
Сообщение от Юрий Горелый2
50 систем = 50 socket. Быстродействие modbus TCP зависит от кол-ства опросов за 1 цикл. В Вашем случае желательно уложиться в 2 опроса на 1 системуЦитата:
Сообщение от VladimirIS
тут я на коленке да, как то здорово прикинул, конечно, порядка 16..30 мегабит получается если modbusTCP по диаграмме состояний.Цитата:
Сообщение от VladimirIS
см. MODBUS MESSAGING ON TCP/IP IMPLEMENTATION GUIDEV1.0b
это на коленке Весьма и Весьма зависит от того, Каким образом проводить опрос - и посылать запросы. и зависит в том числе от систем, к которым они идут. если запросы не групповые -Цитата:
Сообщение от VladimirIS
а мы не знаем по порядку идут регистры или в разбежку, то в крайнем случае - это отдельный запрос на каждый регистр.
мне кажется что Далеко не всегда опрос 50-и систем, тем более по 200 регистров это 50 сокетов.Цитата:
Сообщение от AlexZ
Более того, мне кажется что это минимум 200..250 сокетов, если данные идут подряд. см. максимальный размер посылки.
"The received buffer size depends on the TCP Windows size, the TCP Maximum
segment size and the time needed to absorb the incoming frames. With a Maximum
Segment Size of 300 bytes (a MODBUS request needs a maximum of 256 bytes + the
MBAP header size)"
Если же регистры с промежутками, то в крайнем случае это один сокет на один запрос. потому что ModbusTCP так работает. (см. MODBUS MESSAGING ON TCP/IP IMPLEMENTATION GUIDE
V1.0b October 24, 2006)
1 клиент - 1 сокет, если клиент кривой просто сокеты между запросами могут закрываться/открыватьсяЦитата:
Сообщение от Юрий Горелый2
Сокет - это IP адрес и порт.Цитата:
Сообщение от Юрий Горелый2
более того, в документации на ModbusTCP пример такого рода системы разобран чёрным по беломуЦитата:
Сообщение от VladimirIS
"TCP-NODELAY:
Small packets (called tinygrams) are normally not a problem on LANs, since most LANs
are not congested, but these tinygrams can lead to congestion on wide area networks.
A simple solution, called the "NAGLE algorithm", is to collect small amounts of data and
sends them in a single segment when TCP acknowledgments of previous packets
arrive.
In order to have better real-time behavior it is recommended to send small amounts of
data directly without trying to gather them in a single segment. That is why it is
recommended to force the TCP-NODELAY option that disables the "NAGLE algorithm"
on client and server connections. "
плавно намекая на то, что большим количеством маленьких пакетов сеть будет загажена и их надо Специально упаковывать
в нужного размера пакеты. ( считать отдельно делать адресное пространство требуемым образом) а нужный размер максимум 300 байт.
далее по тексту в описании ModbusTCP отдельно указано что же будет с сокетами на серверАХ и клиенте и что с ними должно быть
"SO-REUSEADDR:
When a MODBUS server closes a TCP connection initialized by a remote client, the
local port number used for this connection cannot be reused for a new opening while
that connection stays in the "Time-wait" state (during two MSL : Maximum Segment
Lifetime).
It is recommended specifying the SO-REUSEADDR option for each client and server
connection to bypass this restriction. This option allows the process to assign itself a
port number that is part of a connection that is in the 2MSL wait for client and listening
socket.
"
Далее по тексту указано почему, когда и как стоит закрывать сокеты и создавать новые -
"SO-KEEPALIVE:"
"
By default on TCP/IP protocol no data are sent across an idle TCP connection.
Therefore if no process at the ends of a TCP connection is sending data to the other,
nothing is exchanged between the two TCP modules. This assumes that either the
client application or the server application uses timers to detect inactivity in order to
close a connection.
It is recommended to enable the KEEPALIVE option on both client and server
connection in order to poll the other end to know if the distant has either crashed and is
down or crashed and rebooted.
Nevertheless we must keep on mind that enabling KEEPALIVE can cause perfectly
good connections to be dropped during transient failures, that it consumes unnecessary
bandwidth on the network if the keep alive timer is too short."
"
из этого и вытекает, что за 200 параметрами к 50-и системам обращаясь, даже близко не будет пахнуть 50-ю сокетами.
Еще раз повторяю - 1 клиент = 1 сокет (одновременно), сервера, то есть ПЛК на другое не рассчитаны. В любом OPC задайте логгирование и убедитесь в этом.Цитата:
Сообщение от Юрий Горелый2
Советую почитать документацию на ModbusTCP чтобы не заблуждаться таким образом.Цитата:
Сообщение от AlexZ
Вы сейчас про OPC или про ModbusTCP?Цитата:
Сообщение от AlexZ
это немного совсем разные протоколы.
Или Вы про 1 сокет = 200 переменных? они в него, внезапно, не влезут.
сокет надо открыть. послать какое то количество данных, в каком то количестве сеансов. и закрыть. чтобы открыть заново.
почему все вдруг решили что каждая система в рамках одной сессии будет слать 2 килобайта (4 +11 )байт*200- большая загадка.
для серверов это нормальная ситуация, но для modbus я бы сказал совсем редкая и почти невозможная. потому что синхронизация.
и если какая то система так делает, то её достаточно жалко.
скорее протоколом это будет делиться на пакеты по 300 байт. потому что оно так.
В процитированной Вами документации говориться про алгоритм NAGLE и свойство KEEPALIVE.Цитата:
Сообщение от Юрий Горелый2
К количеству одновременно открытых сокетов не имеет никакого отношения.
Я имел ввиду не OPC протокол, а OPC сервер. Все известные мне OPC работают по схеме: 1 узел = 1 подключение = 1 сокет. Если пользователь хочет, а OPC позволяет искусственно разбивать узел на несколько логических частей, то только в этом случае может быть одновременно более 1 сокета для связи с одним ПЛКЦитата:
Сообщение от Юрий Горелый2
Тема ТС была про Modbus.Цитата:
Сообщение от Юрий Горелый2
Если система открывает/закрывает сокет для получения данных с каждого регистра, это проблемы системы.
Но даже в этом случае в один момент времени открыт только один сокет.
именно так и есть. 1 OPC сервер, 1 OPC клиент - по умолчанию 1 socket.
ModbusTCP немного не так, если покопать поглубже.
строго говоря не совсем так.Цитата:
Сообщение от VladimirIS
Более того, строго говоря совсем не так. иначе тайминги были бы ну совсем более ужасными.
Для Клиента - мастерскады опрашивающей 50 систем по протоколу ModbusTCP -почти наверняка не так, ( потому что внезапно TCP)
но возможно и для любого из 50-и Серверов тоже быть совсем не так. особенно после какого нибудь таймаута (а он, таймаут - придёт, никуда не денется)
резюме простое - лучше опрашивать OPC_UA. благо он именно для такого и предназначен.
и использовать пошире канал пошустрее сервер.
p.s ( видимо форум меня хорошо помнит лично, что выставил одно слово сначала со звёздочками... я посмеялся)
Все наоборот. Зачем закрывать сокеты при постоянном опросе? Чтобы получить "ужасные" тайминги?Цитата:
Сообщение от Юрий Горелый2
Нормальная работа: открыли сокет - получаем данные с контроллера. Если сокет закрылся (по любой причине), открываем заново. Аналогично для других 49 систем. Итого 50 одновременно работающих сокетов.
Про OPC не спорю. Просто ТС спрашивал про Modbus.Цитата:
Сообщение от Юрий Горелый2
Про канал мы вроде уже определились. Вы сами написали что нужно 30 мегабит. Для гигабитной сети это семечки.
Ну а шустрый сервер никогда не лишний :)
Хотелось бы получить хотя бы 1 сек. Сделал 2 теста На мастерскаде и на Какскад-САУ опрос источника данных 2000 параметров по МодбасТСР с встроенным счетчиком изменений - такт 500 мсек. На Мастерскаде постоянные пропуски по 5..7 значений, на Какскад-Сау ни одного пропуска.Цитата:
Сообщение от Юрий Горелый2
Поэтому и вопрос к тем которые сталкивались с этой проблемой, как выходили из этого?
Есть в работе 30 узлов, более 3200 тегов на опрос (ModbusTCP), интервал в основном секунда, те что на запись по 3 сек. 20 тегов с одного узла по 0,5 сек.
Данные для опроса в узлах расположены строго по порядку, т.е. заранее так планировалось. OPC умеет групповые запросы, на один узел от 4 до 8 в моём случае.
Используется KEPServerEX, каждый узел в отдельном потоке, сокеты закрывает только по тайм ауту, потом пытается вновь установить TCP соединение.
Всё летает, комп уровня офисного. То же самое на скромной виртуалке так же без проблем. Скада простенькая от Омрона.
Так и у меня скада простенькая и все летает, но вопрос по Мастерскаде, т.к. на нее планируется переход, а она по всей видимости не тянет. Уже на 500 сигналах при изменение 500 мсек, начинаются пропуски.Цитата:
Сообщение от BETEP
А ОРС сервер какой? И почему не пишете вопрос в техподдержку Инсат? Тут вам такой лапши навешают...типо простенькая скада от Омрон по Modbus TCP работает быстрееЦитата:
Сообщение от volgogaz
OPC сервера нет никакого, все работает через внутренние драйвера мастерскады. В техподдержку обращались - молчание. Лапши мне не навешают, т.к. у меня конкретный вопрос к тем которые сталкивались с этой проблемой в Мастерскаде. Все ответы до этого и ваш в том числе не попадают в эту категорию.Цитата:
Сообщение от Sergey666
С будуна что ли? Где такое написано?Цитата:
Сообщение от Sergey666
мне когда-то давно на 300 счетчиков электроэнергии Инсат насчитал ДВА физических сервера. Даже если взять 3-х фазники по 30-40 сигналов с каждого, пусть 40, то это всего-то 12000 тегов.
з.ы. справлюсь одним сервером уровня офисного, нафик такая Scada нужна, которая на 12 тысяч тегов требует два физических сервера????? речь тогда шла про 3-ю версию... 4-я куда тормознее в принципе...
Проблема решилась. по совету поддержки:
"Попробуйте разделить модули по нескольким протоколам. Так как на каждый протокол выделяется своя задача, то в таком случае повысится нагрузка на среду исполнения в целом, но снизится нагрузка на каждую конкретную задачу, что позволит увеличить скорость опроса."
Но правда еще к этому совету добавили изменение параметра Протокола "Тайаут" с 1000 на 50.
И теперь 2000 параметров (10 по 200) легко читаются с периодом изменения на источнике 250 мсек.