Быстродействие MasterScada 4d

[volgogaz]

Возникли проблемы с быстродействием. Задача собрать с 50-ти систем по 200 сигналов по ModbusTCP (и второй вариант по 104 протоколу) Тормоза уже начинаются на 10-ой системе (т.е 2000 входных регистров). А 104 вообще жуть, даже 100 параметров передать проблема. Кто сталкивался с подобным и как решили проблему.

[melky]

Тут либо ПК очень мощный, либо систему поменять. Правда вот со 104-м не много наверное наберется, как вариант использовать OPC UA сервер для этого

[Юрий Горелый2]

Возникли проблемы с быстродействием. Задача собрать с 50-ти систем по 200 сигналов по ModbusTCP (и второй вариант по 104 протоколу) Тормоза уже начинаются на 10-ой системе (т.е 2000 входных регистров). А 104 вообще жуть, даже 100 параметров передать проблема. Кто сталкивался с подобным и как решили проблему.

интересно на какое быстродействие расчитываете? с каким периодом хотите получать данные?
примерная прикидка Вашей системы - на коленке:

50 систем по 200 сигналов. не совсем понятно, но допустим это 4 байта каждый сигнал.
это 40 000 байт
насколько я помню, по эзернету 1 байт это примерно 10 бит. без учёта туда-сюда данных TCP (Modbus же TCP)
это на вскидку получается 400 мегабит. Это без учета того, что TCP оно обменивается туда-сюда двумя хэндшейками,

Если он шпарит непрерывно, без остановок.

И что-то мне кажется, что тормоз в этой архитектуре и этих протоколах скорее всего не мастерскада а сначала начнёт тормозить канал передачи данных,
потом начнёт тормозить память, потому что для каждой переменной не просто надо держать память, но ещё и открытый socket,
потом тормозить будет именно операционная система, потому что количество socket оно хоть и пишется что 65535, но больше 2500 редко какая версия windows нормально может держать открытой постоянно - надо серверную винду ставить.
и уже только потом будет вопрос к Мастерскаде.

Всё-таки я бы посоветовал пересмотреть архитектуру и протоколы.

[VladimirIS]

50 систем по 200 сигналов. не совсем понятно, но допустим это 4 байта каждый сигнал.
это 40 000 байт
насколько я помню, по эзернету 1 байт это примерно 10 бит. без учёта туда-сюда данных TCP (Modbus же TCP)
это на вскидку получается 400 мегабит. Это без учета того, что TCP оно обменивается туда-сюда двумя хэндшейками,

Странный расчет. Может у меня что с арифметикой, но 40 000 байт - это 400 000 бит. Это 400 килобит.

[VladimirIS]

для каждой переменной не просто надо держать память, но ещё и открытый socket,

Прошу подтвердить про socket. Вы это точно знаете или подозреваете?

[AlexZ]

Прошу подтвердить про socket. Вы это точно знаете или подозреваете?

50 систем = 50 socket. Быстродействие modbus TCP зависит от кол-ства опросов за 1 цикл. В Вашем случае желательно уложиться в 2 опроса на 1 систему

[Юрий Горелый2]

Странный расчет. Может у меня что с арифметикой, но 40 000 байт - это 400 000 бит. Это 400 килобит.

тут я на коленке да, как то здорово прикинул, конечно, порядка 16..30 мегабит получается если modbusTCP по диаграмме состояний.
см. MODBUS MESSAGING ON TCP/IP IMPLEMENTATION GUIDEV1.0b

[Юрий Горелый2]

Прошу подтвердить про socket. Вы это точно знаете или подозреваете?

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

[Юрий Горелый2]

50 систем = 50 socket. Быстродействие modbus TCP зависит от кол-ства опросов за 1 цикл. В Вашем случае желательно уложиться в 2 опроса на 1 систему

мне кажется что Далеко не всегда опрос 50-и систем, тем более по 200 регистров это 50 сокетов.
Более того, мне кажется что это минимум 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)

[AlexZ]

мне кажется что Далеко не всегда опрос 50-и систем, тем более по 200 регистров это 50 сокетов.
Более того, мне кажется что это минимум 200..250 сокетов, если данные идут подряд. см. максимальный размер посылки.
Если же регистры с промежутками, то в крайнем случае это один сокет на один запрос. потому что ModbusTCP так работает. (см. MODBUS MESSAGING ON TCP/IP IMPLEMENTATION GUIDE
V1.0b October 24, 2006)

1 клиент - 1 сокет, если клиент кривой просто сокеты между запросами могут закрываться/открываться

[VladimirIS]

мне кажется что Далеко не всегда опрос 50-и систем, тем более по 200 регистров это 50 сокетов.
Более того, мне кажется что это минимум 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)
Сокет - это IP адрес и порт.

[Юрий Горелый2]

Прошу подтвердить про socket. Вы это точно знаете или подозреваете?

более того, в документации на ModbusTCP пример такого рода системы разобран чёрным по белому
"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-ю сокетами.

[AlexZ]

более того, в документации на ModbusTCP пример такого рода системы разобран чёрным по белому
"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]

1 клиент - 1 сокет, если клиент кривой просто сокеты между запросами могут закрываться/открываться

Советую почитать документацию на ModbusTCP чтобы не заблуждаться таким образом.

[Юрий Горелый2]

Еще раз повторяю - 1 клиент = 1 сокет (одновременно), сервера, то есть ПЛК на другое не рассчитаны. В любом OPC задайте логгирование и убедитесь в этом.
Вы сейчас про OPC или про ModbusTCP?
это немного совсем разные протоколы.
Или Вы про 1 сокет = 200 переменных? они в него, внезапно, не влезут.
сокет надо открыть. послать какое то количество данных, в каком то количестве сеансов. и закрыть. чтобы открыть заново.
почему все вдруг решили что каждая система в рамках одной сессии будет слать 2 килобайта (4 +11 )байт*200- большая загадка.
для серверов это нормальная ситуация, но для modbus я бы сказал совсем редкая и почти невозможная. потому что синхронизация.
и если какая то система так делает, то её достаточно жалко.
скорее протоколом это будет делиться на пакеты по 300 байт. потому что оно так.

[VladimirIS]

более того, в документации на ModbusTCP пример такого рода системы разобран чёрным по белому
"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-ю сокетами.

В процитированной Вами документации говориться про алгоритм NAGLE и свойство KEEPALIVE.
К количеству одновременно открытых сокетов не имеет никакого отношения.

[AlexZ]

Вы сейчас про OPC или про ModbusTCP?
это немного совсем разные протоколы.
Или Вы про 1 сокет = 200 переменных? они в него, внезапно, не влезут.
сокет надо открыть. послать какое то количество данных, в каком то количестве сеансов. и закрыть. чтобы открыть заново.

Я имел ввиду не OPC протокол, а OPC сервер. Все известные мне OPC работают по схеме: 1 узел = 1 подключение = 1 сокет. Если пользователь хочет, а OPC позволяет искусственно разбивать узел на несколько логических частей, то только в этом случае может быть одновременно более 1 сокета для связи с одним ПЛК

[VladimirIS]

Вы сейчас про OPC или про ModbusTCP?
это немного совсем разные протоколы.
Или Вы про 1 сокет = 200 переменных? они в него, внезапно, не влезут.
сокет надо открыть. послать какое то количество данных, в каком то количестве сеансов. и закрыть. чтобы открыть заново.
почему все вдруг решили что каждая система в рамках одной сессии будет слать 2 килобайта (4 +11 )байт*200- большая загадка.
для серверов это нормальная ситуация, но для modbus я бы сказал совсем редкая и почти невозможная. потому что синхронизация.
и если какая то система так делает, то её достаточно жалко.
скорее протоколом это будет делиться на пакеты по 300 байт. потому что оно так.
Тема ТС была про Modbus.
Если система открывает/закрывает сокет для получения данных с каждого регистра, это проблемы системы.
Но даже в этом случае в один момент времени открыт только один сокет.

[Юрий Горелый2]

именно так и есть. 1 OPC сервер, 1 OPC клиент - по умолчанию 1 socket.
ModbusTCP немного не так, если покопать поглубже.

[Юрий Горелый2]

Тема ТС была про Modbus.
Если система открывает/закрывает сокет для получения данных с каждого регистра, это проблемы системы.
Но даже в этом случае в один момент времени открыт только один сокет.

строго говоря не совсем так.
Более того, строго говоря совсем не так. иначе тайминги были бы ну совсем более ужасными.
Для Клиента - мастерскады опрашивающей 50 систем по протоколу ModbusTCP -почти наверняка не так, ( потому что внезапно TCP)
но возможно и для любого из 50-и Серверов тоже быть совсем не так. особенно после какого нибудь таймаута (а он, таймаут - придёт, никуда не денется)

[Юрий Горелый2]

резюме простое - лучше опрашивать OPC_UA. благо он именно для такого и предназначен.
и использовать пошире канал пошустрее сервер.
p.s ( видимо форум меня хорошо помнит лично, что выставил одно слово сначала со звёздочками... я посмеялся)

[VladimirIS]

строго говоря не совсем так.
Более того, строго говоря совсем не так. иначе тайминги были бы ну совсем более ужасными.
Для Клиента - мастерскады опрашивающей 50 систем по протоколу ModbusTCP -почти наверняка не так, ( потому что внезапно TCP)
но возможно и для любого из 50-и Серверов тоже быть совсем не так. особенно после какого нибудь таймаута (а он, таймаут - придёт, никуда не денется)
Все наоборот. Зачем закрывать сокеты при постоянном опросе? Чтобы получить "ужасные" тайминги?
Нормальная работа: открыли сокет - получаем данные с контроллера. Если сокет закрылся (по любой причине), открываем заново. Аналогично для других 49 систем. Итого 50 одновременно работающих сокетов.


резюме простое - лучше опрашивать OPC_UA. благо он именно для такого и предназначен.
и использовать пошире канал пошустрее сервер.
p.s ( видимо форум меня хорошо помнит лично, что выставил одно слово сначала со звёздочками... я посмеялся)
Про OPC не спорю. Просто ТС спрашивал про Modbus.
Про канал мы вроде уже определились. Вы сами написали что нужно 30 мегабит. Для гигабитной сети это семечки.
Ну а шустрый сервер никогда не лишний :)

[volgogaz]

интересно на какое быстродействие расчитываете? с каким периодом хотите получать данные?
примерная прикидка Вашей системы - на коленке:

Хотелось бы получить хотя бы 1 сек. Сделал 2 теста На мастерскаде и на Какскад-САУ опрос источника данных 2000 параметров по МодбасТСР с встроенным счетчиком изменений - такт 500 мсек. На Мастерскаде постоянные пропуски по 5..7 значений, на Какскад-Сау ни одного пропуска.
Поэтому и вопрос к тем которые сталкивались с этой проблемой, как выходили из этого?

[BETEP]

Есть в работе 30 узлов, более 3200 тегов на опрос (ModbusTCP), интервал в основном секунда, те что на запись по 3 сек. 20 тегов с одного узла по 0,5 сек.
Данные для опроса в узлах расположены строго по порядку, т.е. заранее так планировалось. OPC умеет групповые запросы, на один узел от 4 до 8 в моём случае.
Используется KEPServerEX, каждый узел в отдельном потоке, сокеты закрывает только по тайм ауту, потом пытается вновь установить TCP соединение.
Всё летает, комп уровня офисного. То же самое на скромной виртуалке так же без проблем. Скада простенькая от Омрона.

[volgogaz]

Скада простенькая от Омрона.
Так и у меня скада простенькая и все летает, но вопрос по Мастерскаде, т.к. на нее планируется переход, а она по всей видимости не тянет. Уже на 500 сигналах при изменение 500 мсек, начинаются пропуски.

[Sergey666]

Так и у меня скада простенькая и все летает, но вопрос по Мастерскаде, т.к. на нее планируется переход, а она по всей видимости не тянет. Уже на 500 сигналах при изменение 500 мсек, начинаются пропуски.
А ОРС сервер какой? И почему не пишете вопрос в техподдержку Инсат? Тут вам такой лапши навешают...типо простенькая скада от Омрон по Modbus TCP работает быстрее

[volgogaz]

А ОРС сервер какой? И почему не пишете вопрос в техподдержку Инсат? Тут вам такой лапши навешают...типо простенькая скада от Омрон по Modbus TCP работает быстрее
OPC сервера нет никакого, все работает через внутренние драйвера мастерскады. В техподдержку обращались - молчание. Лапши мне не навешают, т.к. у меня конкретный вопрос к тем которые сталкивались с этой проблемой в Мастерскаде. Все ответы до этого и ваш в том числе не попадают в эту категорию.

[BETEP]

................. Тут вам такой лапши навешают...типо простенькая скада от Омрон по Modbus TCP работает быстрее
С будуна что ли? Где такое написано?

[melky]

мне когда-то давно на 300 счетчиков электроэнергии Инсат насчитал ДВА физических сервера. Даже если взять 3-х фазники по 30-40 сигналов с каждого, пусть 40, то это всего-то 12000 тегов.
з.ы. справлюсь одним сервером уровня офисного, нафик такая Scada нужна, которая на 12 тысяч тегов требует два физических сервера????? речь тогда шла про 3-ю версию... 4-я куда тормознее в принципе...

[volgogaz]

Проблема решилась. по совету поддержки:
"Попробуйте разделить модули по нескольким протоколам. Так как на каждый протокол выделяется своя задача, то в таком случае повысится нагрузка на среду исполнения в целом, но снизится нагрузка на каждую конкретную задачу, что позволит увеличить скорость опроса."
Но правда еще к этому совету добавили изменение параметра Протокола "Тайаут" с 1000 на 50.
И теперь 2000 параметров (10 по 200) легко читаются с периодом изменения на источнике 250 мсек.