"Нестандартное" применение OpenSCADA
| Автор |
Повідомлення |
|
Повідомлення створено: 08. 12. 2009 [11:10]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
almaz wrote:
roman wrote:
Вы пробовали?
Для ПО эту методику не применял, только для железа.
Вот как примените, тогда и будете расказывать как это круто, а сейчас не нужно.
almaz wrote:
Знаний достаточно, чтобы увидеть проблему и пути её решения. Знаний пока недостаточно чтобы эти решения реализовать. Обвинениями не занимаюсь вообще, так как обвинять всегда рано или уже поздно.
Вы фактически признали, что не владеете техническими особенностями и при этом продолжаете настаивать, что это возможно. В то время как я, владея техническими особеноостями, говорю, что такой возможности нет. Будем продолжать дальше или Вы всётаки изучите предмет обсуждения?
almaz wrote:
Пытаюсь повлиять на развитие OpenSCADA только в сторону улучшения, так как использую её для работы. Это вообще возможно (повлиять) или Вы так всегда будете отвергать очевидные улучшения? Понимаю, что достаточно поздно вносить такие сильные концептуальные изменения и это надо было делать когда проект только зарождался, но я не знал тогда о его существовании. И сейчас я не прошу всё бросать и разрабатывать срочно патч для реализации этого, а только принять к сведению (хоть к версии OpenSCADA 3.0) 
Возможно, когда это обосновано. Но это не тот случай.
almaz wrote:
roman wrote:
Запускайте. Кто Вам мешает?
Вы хоть примете разработку опции компиляции в микроядерном варианте в SVN проекта? Да и без Вашей поддержки разработка будет совсем сложна...
Она не нужна. Этот механизм уже реализуется без всяких опций. А на уровне нитей это сейчас невозможно!
almaz wrote:
На уровне нынешних нитей - нет. На уровне модулей, да. Пока попробуем его проработать.
Я так понял, в нескольких процессах запускается каждый существующий модуль с парочкой DAQGate - Транспорты? Такая коммутация может быть очень тормозной.
А вот это именно те недостатки микроядерной архитектуры которых Вы видеть не хотите, не имея обпыта работы с ней!
almaz wrote:
А нельзя хотя бы на будущее предусмотреть (принять к сведению) быстродействующий транспорт для DAQGate (вместо сетей связи, например, разделяемая память) для обмена между двумя процессами OpenSCADA на одной машине?
Это и так предусмотрено. Если Вы плохо читали концепцию, то перечитайте. Всё это, включая и микроядерность, рассматривалось ещё в 2002 году. Имеется реальный, а не виртуальный как у Вас, опыт работы с ОС микроядерной архитектуры, на основе QNX. И Вы сильно заблуждаетесь когда считаете, что я этого я не учитывал.
Если нужно быстрее, то используйте Unix-sockets. Если нужно ещё быстрее, то реализуйте модуль транспорта для разделяемой памяти, в простонародье SGA.
Только накладных расходов на сеарилизацию это не устранит!
almaz wrote:
Да и диспетчер нескольких опенскад на одной машине не помешал бы... Для перезапуска сбившихся процессов.
Это функция конфигурации, а не исходного текста.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 08. 12. 2009 [13:46]
|
|
almaz
Almaz Karimov
Contributor
Автор теми
Зареєстрован(а) с: 25.09.2008
Повідомлення: 516
|
Какими ещё техническими особенностями я не владею? Я просто тщательно не успел изучить исходные тексты OpenSCADA и ядер OS. И не имею знаний именно о подробностях работы исходного кода. А всё остальное изучено и большинство на практике.
Я уже достаточно привёл обоснований и доказательств. Вы их даже не читаете. Судя по этому:
roman wrote:
almaz wrote:
roman wrote:
Вы пробовали?
Для ПО эту методику не применял, только для железа. Как и Вы не знал, что это возможно. Узнал благодаря Википедии и инету. Теперь применяю и буду применять. Только самая нужная программа 100% отказывает при проверке таким тестом. Серьёзнейшая проблема и брешь в надёжности OpenSCADA. 
Вот как примените, тогда и будете расказывать как это круто, а сейчас не нужно.
roman wrote:
almaz wrote:
На уровне нынешних нитей - нет. На уровне модулей, да. Пока попробуем его проработать.
Я так понял, в нескольких процессах запускается каждый существующий модуль с парочкой DAQGate - Транспорты? Такая коммутация может быть очень тормозной.
А вот это именно те недостатки микроядерной архитектуры которых Вы видеть не хотите, не имея обпыта работы с ней!
Даже не работая с этими ОС понятно, что через TCP/IP стек обмен между системными процессами не идёт. А сравнительные тесты ОС дают потерю производительности в 5-10%.
roman wrote:
Будем продолжать дальше или Вы всётаки изучите предмет обсуждения?
Поработаю на практике с микроядерными ОС, чтобы у меня не осталось сомнений (слишком уж Вы уверено отвергаете эти ОС). Потом вернусь к этому вопросу. Ну и попытаюсь найти ошибку в концепции, из-за которой произошла такая ошибка в тесте ПО.
[Повідомлення редагувалось 2 раз(ів), останній раз 08.12.2009 в 14:02.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Повідомлення створено: 09. 12. 2009 [09:12]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
almaz wrote:
Даже не работая с этими ОС понятно, что через TCP/IP стек обмен между системными процессами не идёт. А сравнительные тесты ОС дают потерю производительности в 5-10%.
Да что Вы говорите.
А нука запустите мне модули DAQ.DiamondBoards, DAQ.SoundCard и DAQ.ICP_DAS по слабым связям в отдельном процессе (это возможно) и Вы получите потерю производительности на 100%, при сборе данных с частотой 10 кГц. В тоже время на локальных связях это замечательно работает и не однократно применялось.
Изучите сначала как в микроядерных архитектурах решаются подобные задачи, а потом бросайтесь числами не понимая что за ними стоит.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 09. 12. 2009 [14:55]
|
|
almaz
Almaz Karimov
Contributor
Автор теми
Зареєстрован(а) с: 25.09.2008
Повідомлення: 516
|
Цифру 5-10% я нашёл вот тут
www.minix3.ru/docs/faq.pdf
Это разница в производительности монолитной архитектуры Minix2 и микроядерной архитектуры Minix3.
Всё правильно. Там же между драйверами-модулями нет такого высокочастотного обмена. Высокочастотный обмен информацией идёт только драйвер-оборудование, а обмен между разными модулями происходит блоками данных на низкой частоте. Отсюда и незначительный проигрыш в быстродействии.
Я уже на первой странице темы задал вопрос по потере производительности в микроядерной архитектуре. И только сейчас Вы дали ответ на этот вопрос.
Вы видите в микроядерной архитектуре проблему для высоких частот обработки.
Вопрос. А для монолитно-модульной архитектуры в условиях многозадачной ОС на ограниченном числе процессорных ядер Вы проблему для высокочастотной обработки не увидели? Скажите, пожалуйста, на какой частоте затыкается монолитно-модульная архитектура.
PS Под высокочастотной обработкой подразумеваю следующее: ввод нескольких значений, обработка информации, вывод нескольких значений; и так периодически с высокой частотой в реальном времени. То есть передача информации большими блоками на низкой частоте исключена.
[Повідомлення редагувалось 3 раз(ів), останній раз 09.12.2009 в 15:11.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Повідомлення створено: 09. 12. 2009 [18:14]
|
|
almaz
Almaz Karimov
Contributor
Автор теми
Зареєстрован(а) с: 25.09.2008
Повідомлення: 516
|
Знаю, что монолитно-модульная архитектура в производительности на высоких частотах обработки вырвется в разы вперёд, но не существенно.
У нас не было необходимости использовать OpenSCADA на высоких частотах обработки (максимум 10 Гц), поэтому я только-только заметил возможность неправильного использования системы для этого.
Так вот: для обеспечения максимальной производительности на высоких частотах обработки необходимо все связанные с этим процедуры (ввод, обработка, вывод) сосредоточить в одном модуле DAQ.
А обмен с другими модулями вести на низкой частоте (возможно блоками-массивами данных).
Это верно и для монолитно-модульной, и для микроядерной архитектур.
Ещё лучше было бы сосредоточить эти процедуры в одном потоке процесса, но боюсь это повредит функциональности OpenSCADA (возможность использования интерпретатора ява и блочного вычислителя для высокочастотной обработки).
Предвижу ряд вопросов. Отвечу сразу.
Вопрос. А как же быть если ввод данных производится в одном модуле DAQ, а вывод в другом?
Ответ. Имеем два автомобиля без топлива. В один заливаем топливо, а в другой сажаем водителя. Как же нам поехать?
Вопрос. А как же составить алгоритм высокочастотной обработки на ява?
Ответ. Так же как он пишется на ява для блочного вычислителя. Просто на низкой частоте перетащить его из ява-вычислителя в модуль DAQ, который будет производить высокочастотную обработку.
Вопрос. А как же производить высокочастотную архивацию и другие операции?
Ответ. Блоками на низкой частоте. Архивы, визуализация и другое нужны человеку. А человек всё равно не имеет такой реакции. Зачем тогда все эти операции производить быстро?
Вопрос. А как же передать высокочастотные данные через транспорт, например, TCP/IP?
Ответ. Блоками на низкой частоте. Так как всё равно в реальном времени на высокой частоте ни через один транспорт не получится. Или через высокоскоростной интерфейс, подключаемый в том же модуле DAQ в котором идёт высокочастотная обработка. Или использовать аналоговую передачу сигнала.
PS Да здравствует низкочастотный межмодульный обмен!!!
[Повідомлення редагувалось 4 раз(ів), останній раз 09.12.2009 в 19:00.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Повідомлення створено: 09. 12. 2009 [19:51]
|
|
Aleksey
Aleksey Popkov
Contributor
Зареєстрован(а) с: 31.07.2008
Повідомлення: 326
|
Помоиму эту тему с дебатами Роман тоже запрет вот-вот.
Мне конечно не особо хочется в спор тут вступать, не настолько я в курсе поднятых тут дебрей, но на столько на сколько знаю я Романа, могу сказать с уверенностью. Если-бы варианты стабилизации лучьше тех которые применены в OpenSCADA были-бы, я уверен, Роман не упустил-бы их. Если-бы были варианты сделать OpenSCADA быстрее межмодульно, Роман и это-бы использовал. У него на то свои есть мысли, и решения его оспаривать помоиму не стоит. Темболее разработка OpenSCADA ведется ежедневно, что-то оптимизируется, нараживается, улучьшается и т.д.
Если всеж Вы не согласны с таким мнением, может просто сделать отдельный репозитарий только для Вас, где-нить на Ваших сетевых ресурсах и, основываясь на Ваших доводах, в которых Вы целиком и полностью уверены, реализовывать свое развитие OpenSCADA, в том разрезе в котором Вы видите ситуации по оптимизации межмодульного обмена и всех остальный идей которые Вы донести пытаетесь. Будете вести разработку OpenSCADA в своем русле, то как Вы это для себя видите.
Да и возникать ощущения что Вас не слышат тоже пропадут сами собой.
[Повідомлення редагувалось 1 раз(ів), останній раз 09.12.2009 в 19:57.]
|
|
Повідомлення створено: 09. 12. 2009 [20:21]
|
|
almaz
Almaz Karimov
Contributor
Автор теми
Зареєстрован(а) с: 25.09.2008
Повідомлення: 516
|
По поводу размножения проектов, выполняющих одинаковые функции, я уже выразил своё мнение при обсуждении дистрибутивов. Поэтому буду поддерживать только основной проект. И более того, буду оказывать противодействие при попытках это сделать (по возможности). Так как это рассредоточение усилий.
И Вам, Алексей, советую удерживать людей тут, а не выпроваживать, как Вы уже делаете.
Какое бы решение не принял Роман - всё равно с ним придётся согласиться. Так как он тут главный. Но эти решения он принимает в зависимости от обстоятельств. Если ничего не будет происходить, то и решений не будет.
Обсуждать проект нужно. И нужно доводить обсуждения до логического завершения.
Приведён после варианта улучшения надёжности ещё и вариант улучшения производительности, причём их можно совместить.
Алексей, послушаем, что скажет Роман и примем это как есть. Тем более в этом обсуждении уже почти пришли к завершению.
PS Было излишнее обсуждение из-за того, что мы с Романом подразумевали разные вещи под понятием производительность. Теперь я понимаю, что он имел ввиду. Надеюсь и он меня поймёт.
[Повідомлення редагувалось 5 раз(ів), останній раз 09.12.2009 в 22:49.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Повідомлення створено: 09. 12. 2009 [22:50]
|
|
Aleksey
Aleksey Popkov
Contributor
Зареєстрован(а) с: 31.07.2008
Повідомлення: 326
|
almaz wrote:
По поводу размножения проектов, выполняющих одинаковые функции, я уже выразил своё мнение при обсуждении дистрибутивов. Поэтому буду поддерживать только основной проект. И более того, буду оказывать противодействие при попытках это сделать (по возможности). Так как это рассредоточение усилий.
И Вам, Алексей, советую удерживать людей тут, а не выпроваживать, как Вы уже делаете.
Множить проект я никого не подстрекаю, просто, то что Вы предлагали в прошлой теме, попробовали-бы реализовать. Возможно были-бы достигнуты какие-то результаты, и по этим новоиспеченным результатам можно было-бы продолжить полемику.
И по отношению к дистров у всех свое, сугубо личное, мнение.
И не выпроваживаю я с этого ресурса никого, в мыслях даже такого не было, в посте предыдущем моем ничего об этом и не говорит. И не делал я ничего подобного.
Какое бы решение не принял Роман - всё равно с ним придётся согласиться. Так как он тут главный. Но эти решения он принимает в зависимости от обстоятельств. Если ничего не будет происходить, то и решений не будет.
Роман принимаем решения согласно родмапу и конепции которую он год готовил перед тем как начать работу над OpenSCADA, и на решения его, на наши посты размером с А4 ни как на это не повлияют. Только отнимум время на споры, а лучьше-бы его время тратить-бы на разработку и на борьбу с багой с которой пару дней как столкнулись.
Обсуждать проект нужно. И нужно доводить обсуждения до логического завершения.
Логическое завершение любого обсуждения, лично для меня, это мнение Романа.
Приведён после варианта улучшения надёжности ещё и вариант улучшения производительности, причём их можно совместить.
Тут мне трудно судить, я пологаюсь на профессианолизм Романа.
Алексей, послушаем, что скажет Роман и примем это как есть. Тем более в этом обсуждении уже почти пришли к завершению.
Я написал сюда только по единственной причине: одна из тем была заблокирована Романом не потому, что там достигнут результат, а потому что дальнейший разговор вел только к трате времени.
PS Было излишнее обсуждение из-за того, что мы с Романом понимали разные вещи под понятием производительность. Теперь я понимаю, что он имел ввиду. Надеюсь и он меня поймёт.
Я надесь что Роману не придется время тратить на такие споры, а он его потратить на откручивании ног одной баги, которая мне 2-е сутки покоя не дает.
[Повідомлення редагувалось 2 раз(ів), останній раз 09.12.2009 в 23:04.]
|
|
Повідомлення створено: 10. 12. 2009 [01:02]
|
|
kuzulis
Денис Шиенков
Зареєстрован(а) с: 10.07.2009
Повідомлення: 128
|
Что за баг?
|
|
Повідомлення створено: 10. 12. 2009 [08:18]
|
|
Aleksey
Aleksey Popkov
Contributor
Зареєстрован(а) с: 31.07.2008
Повідомлення: 326
|
Воспроизводиться падение из-за модбас.
Роман поправит ))))))))))
[Повідомлення редагувалось 1 раз(ів), останній раз 10.12.2009 в 08:19.]
|
|
|
