Отзыв АРМ Орион Про 1.11

[MadHacker]

AlexRuden, вы невнимательны. Держите. Пишите что душе угодно.
http://www.bolid.ru/soft/object/object_34.html

[AlexRuden]

AlexRuden, вы невнимательны. Держите. Пишите что душе угодно.
http://www.bolid.ru/soft/object/object_34.html

Эту поделку я видел... , и она мне и даром не нужна :evil:

Какойто xml , да еще и ОРС сервер тут - нах мне это? о_О

Дайте мне возможность общаться с ядром более быстро, хотя бы на локальном рабочем месте.

[AlexRuden]

Проще говоря дайте мне инжект в ядро по типу написания плагинов для программ, а не какието там xml ... Нужно повышать скорость работы системы, а не городить пришлепки в виде костылей, как здесь уже говорилось. Имея доступ к функциям ядра на низком уровне гораздо больше возможностей.
Но увы.. Болид на это не пойдет, и зря. Железо у Болида нормальное, а вот софт хромает.

В принципе срач в этой теме можно закрыть имхо...

[MadHacker]

Забавно читать. AlexRuden, сможете привести хотя бы один пример, в котором вам не хватит скорости существующих интерфейсов, для решения задачи?
И если не секрет, какие возможности вы надеетесь увидеть на низком уровне?

[AlexRuden]

Забавно читать. AlexRuden, сможете привести хотя бы один пример, в котором вам не хватит скорости существующих интерфейсов, для решения задачи?
И если не секрет, какие возможности вы надеетесь увидеть на низком уровне? :)

2000 сотрудников в БД , 40 контроллеров С2000-4 - считывание конфига и ключей происходит более 2 часов .. Чем обусловлена такая низкая скорость? Криво разработанным софтом? Глючное Ядро? Скорость порта 9600 б/с ? Или еще какие кастыли потерялись?
Работу с большим количеством пультов и портов вообще тут обсуждали.

4500 АУ ДИП34, 4 Пульта , 50 КДЛ - полное снятие/постановка на охрану занимает минут 20-30 ... Причем в это время ядро ставит в далекую очередь запросы моего скрипта...

Ядро вообще многопоточно, при работе с несколькими USB-портами?

Я не пользователь. Я разработчик.

Если Вы засланец Болида, то так и скажите - " жрите что дают, не будет улучшений ".

Я высказал свой отзыв ТС, засим откланиваюсь и покидаю тему .

[MadHacker]

Если Вы засланец Болида, то так и скажите - " жрите что дают, не будет улучшений ".

:) Будут улучшения. Но не скоро.

Считывание ключей долгое. Тут к сожалению ничего не сделать. А вот второе лечится если у вас нет БКИ, показывающих разделы не со своих пультов. Тогда в реестре HKLM\SOFTWARE\BOLID\ORION_PRO\ORICORE\NotTranslateStatusObj в единичку.

[zova]

4500 АУ ДИП34, 4 Пульта , 50 КДЛ - полное снятие/постановка на охрану занимает минут 20-30 ..

сколько портов у Вас используется для этого хозяйства?
У нас самый крупный АРМ в два раза больше и походу раз в десять шустрее работает.
Писюк арма обычный офисный.

[vasilich]

Расскажите какие платформы Вы используете для работы серверных процессов болида?

Обычные ПК. Я не пользователь. Я разработчик.

тем более, сфера применения Вам должна быть известна больше чем рядовым пользователям

Или использовать под сервант "не сервант"? Других вариантов нет, я себя лично отношу к последним, база у меня на нормальной платформе, а ядро на рабочем месте за 30р, что сервером быть не может по определению, значит заявления безопасность\стабильность\надежность это фарс.

Из всех программных модулей Болида серверным можно назвать только центральный сервер Орион. Остальные модули создавались под самые обычные пользовательские рабочие места. Потому что чаще всего сигнализация вся сводилась в какую-нибудь будку охранника, куда никто никакой сервер ставить в жизни не будет. Безопасность, стабильность и надёжность обеспечивают приборы. Софт должен обеспечивать удобство пользователя. И в этом плане недостатки у него пока имеются.

Вот тут я с Вами не соглашусь, во первых приборы не умеют заводить пользователей в системе не умеют строить отчеты, не умеют управлять уровнем доступа, а функционирование системы определяют именно по этим операциям, делить функционал системы на приборы и ПО не логично, во-вторых нормальном корпоративном софте должна применять схема клиент-сервер, если раскрыть задачи в этой схеме "сервер" то окажется что "будка охранника" это серверная?)) или нечто больше чем клиент но еще не сервант). Самое простое решения в такой ситуации избавиться от COM интерфейса совсем. Два метода как я и писал раньше, для таких как я например http://www.moxa.ru/good/show/14885/1871592/ или для любителей паяльников любой из http://www.moxa.ru/good/listAll/14885/?&utm_sourc ... lid=COya9MOAyrACFckvmAod03JlYA Я думаю болид самостоятельно может решить такую задачу выпустить C2000 с сетевым интерфейсом и веб-мордой, и все, можно ставить ядро опроса хоть на луну. В моем случае "будка охраника" выглядит так, 2 HDMI монитора на 24" офисный комп на i5 и мощной видео картой, по COM подключен C2000, система видео наблюдения "клинет" грузит 65 ip камер, производительность железа на приделе, а тут еще ядро опроса сбоку... которое и само по себе не стабильно, а в комплексе с местом произрастания рук проживающего в будке, с гигантской сетевой и процессорной активностью клиента видео наблюдения, сводит всю систему до не рабочего положения.

Это почему ж нет, в чем разница между COM на виртуальной машине от физической?

В том, что туда его ещё надо прилепить, через какой либо софт, который как минимум будет вносить задержку. А в более неприятной ситуации сможет добавить глюков, которые будет очень тяжело выловить.

Да не правда. Главное не изобрети велосипед. Не знаю как там на Wтварях, знаю как на HyperV вот окно настроек COM порта на виртуальной машине (гостевой ОС)
[img]http://img406.imageshack.us/img406/8523/comhyperv.jpg[/img]

Виртуальные среды удобнее запускать в кластерной среде на высоко производительных серверах, где миграция от железа больше не зависит, и ситуация когда выход из строя какого либо компонента физического сервера влияет на работу системы, не возможна. Единственный минус это привязка COM к конкретному железу, да и то решается COMtoEth.

Вот вот. Ком всё равно притаскивать. В лучшем случае расстояние позволит завести все провода в серверную и подключить. В худшем - придётся использовать какие-нибудь ухищрения.

Не рассчитана система изначально под облака, терминалы и высокопроизводительные кластеры. Можно добавить какие нибудь костыли, чтоб она заработала в таких условиях, но лучше от этого не станет.
Когда облака станут более распространёнными - появятся соответствующие решения.

ИМХО костыли это прерогатива исключительно пользователя, производитель ПО должен использовать надежные проверенные решения, другой вопрос, если производитель этого не желает. Проблема с терминальным доступом загадка, лицензия вроде как на рабочее место, а то что одно рабочее место может запустить много клиентов болиду не известно, они до сих пор живут в плоскости windows XP. Что значит "более распространёнными" вы имеете ввиду пока у вас на рабочем столе не появится виртуальная среда? ну так поставе себе HyperV core он бесплатный) а вдруг понравится))). ИМХО использование сервера без виртуализации за редким исключением специализированных систем типа iSCSI и т.п. считаю не профессионализмом и бесполезной тратой денег. Рядовой сервант на рынке стоит от 80т р. все что до, это не сервера, ну возникает вопрос который я уже писал, не жирно ли болиду 80т р. только за платформу на которой будет 0,00000001% процессорного времени занимать ядро опроса вместе с MSSQL? +АПСы +уровень сетевого доступа +место в шкафу оно то не резиновое, и целом сумма на 1-2U набежит приличная...

[MadHacker]

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

http://bolid.ru/production/devices/devices_155.html Но просто запихнуть ком в сеть не лучшая идея. Работа по кому это большое количество мелких пакетов, а сети такое не любят.

Более распространённым - это письма от пользователей с просьбами добавить полноценную поддержку.
Терминалы не загадка. Просто там сетевые порты одни на всех. Над этим уже работаем, но говорить про сроки не возьмусь. В 1.12 терминалы точно не попадут.

[vasilich]

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

http://bolid.ru/production/devices/devices_155.html Но просто запихнуть ком в сеть не лучшая идея. Работа по кому это большое количество мелких пакетов, а сети такое не любят.

Отличный девайс, вопрос удаленности на нем можно реализовать, но для виртуализации этого мало, хотелось бы реализацию как выше мной описанных, когда СОМ вообще исключен. И для реализации такой схемы нужен будет только один C2000. Ну от чего же "большое количество мелких пакетов" должно влиять на сеть? если пакет правильно сформирован проблем не должно быть, на то она и сеть, если речь идет о нормальной корп.сети а не SOHO коммутаторах, ему будет параллельно какого размера пакеты и с какой частотой они будут идти, да и VLAN спасет мир. Изолированная сеть чисто для обмена C2000 и Ядром.

Более распространённым - это письма от пользователей с просьбами добавить полноценную поддержку.
Терминалы не загадка. Просто там сетевые порты одни на всех. Над этим уже работаем, но говорить про сроки не возьмусь. В 1.12 терминалы точно не попадут.

По чему это не загадка, я имел ввиду лицензия продана как на рабочие место, а по сути на клиента. Не могу сказать за всех, но мне в чистом виде терминальная служба не нужна, да и это плохая практика, от не опытности администрирования. А вот когда например доменный пользователи на одном ПК работают посменно, один со смены ушел заблокировал свой логин, второй не может запустить болид на том же ПК под своей учетной записью потому как "пользователь" не может выгнать "пользователя", а болид запущенный в той сессии не позволяет запустить его в новой сессии пользователя. (каша получилось но думаю понятно) Источник проблемы ясен, софтина запущенная в одной сессии использует статичный исходящий порт

[MadHacker]

Всё ещё хуже Софтины используют входящий статический порт. Отсюда и вся беда с многопользовательскими режимами.
Для дежурств по сменам как раз и была сделана смена дежурства в мониторе. Предполагалось, что всё это будет крутиться под одной учёткой. Оно долгие годы так и было. А сейчас всё меняется. Меняется очень быстро, а статистики по реальным условиям использования софта нет.
Вот и про проблемы с многопользовательским режимом знаем. Но. Жалобы есть? Нет. Следовательно единичный случай. Откладывается.

[vasilich]

Для дежурств по сменам как раз и была сделана смена дежурства в мониторе.

Это функция операционной системы "смена пользователя") не отнимайте хлеб у макрасофт

[AlexRuden]

Предполагалось, что всё это будет крутиться под одной учёткой. Оно долгие годы так и было. А сейчас всё меняется. Меняется очень быстро, а статистики по реальным условиям использования софта нет.

Дык так нравился атоввод пароля в ОЗ "Орион".
А для "Орион Про" пришлось накатать программулинку, чтоб вводила пароль за оператора. Т.к. сторож (дедушка) боится клавиатуры как огня.
Все крутится под одной учеткой. Смену дежурства ведут в бумажном журнале (прошнурованном, пронумерованном и с печатью ). Недоверяют компьютеру..

[zova]

Всё ещё хуже Софтины используют входящий статический порт. Отсюда и вся беда с многопользовательскими режимами.
Для дежурств по сменам как раз и была сделана смена дежурства в мониторе. Предполагалось, что всё это будет крутиться под одной учёткой. Оно долгие годы так и было. А сейчас всё меняется. Меняется очень быстро, а статистики по реальным условиям использования софта нет.
Вот и про проблемы с многопользовательским режимом знаем. Но. Жалобы есть? Нет. Следовательно единичный случай. Откладывается.

вот как раз статический порт хреново согласуется с сетевой технологией STP. То есть если всё подключено к одному коммутатору жалоб может и нет, но у меня есть.

[Sia-Ori]

MadHacker, пламенный привет коллективу программистов!
Хочу высказать пожелания по Орион-ПРО. И простого это касается.
Перезапись ключей в приборах сейчас происходит так - сперва удаляются все ключи из всех приборов, потом берётся первый ключ, пишется в свои приборы, второй - в свои и т.д., до полного успеха.
Это всё здорово, пока у вас пара-тройка приборов.
Когда их сотня - процесс растягивается на часы, и всё это время часть карточек не работает.
Надо бы изменить порядок стирания-записи ключей, не по ключам, а по контроллерам.

[MadHacker]

А можно поинтересоваться почему вы используете перезапись ключей, а не синхронизацию?

[Sia-Ori]

Потому что синхронизация требует предварительного считывания конфигурации. В Орионе-ПРО это ещё как-то возможно, конфигурация кэшируется, а в просто орионе - никак. И зачем, спрашивается, сначала считать ключи из всех приборов, поработать в АБД и синхронизировать их, если перезапись занимает ровно столько же всемени, как и чтение конфигурации. Хотя нет. Перезапись быстрее! Не ситывается при этом железная конфигурация.
Касательно большого объекта (120 контроллеров С2000-2 в пяти ветках rs-485, 20 событий в секунду поутру, приличествующая такому объекту охранка и пожарка на КДЛах)
Синхронизация выполняется часто, но она происходит с ошибками. Внешне всё нормально, но фактически накапливается разнобой между базой и контроллерами.
Если карту просто удалить - она остаётся в контроллерах.
Вобщем, периодически перезапись нужна.
Сейчас ежедневно вручную считывается конфигурация из нескольких контроллеров, так, чтобы за пару недель всё было свежее. Перезапись выполняется только поштучно, потому как полная перезапись займёт часа два три, и это ночью, когда никто не ходит.
Но это всё лирика.
Уже, скажем, с пятью контроллерами на одной шине 485 по 1000 человек перезапись со сбросом всего сразу занимает вполне заметное время на 9600-то.

[MadHacker]

В Орионе-ПРО это ещё как-то возможно, конфигурация кэшируется, а в просто орионе - никак.

В простом Орионе тоже доступно кеширование.

И зачем, спрашивается, сначала считать ключи из всех приборов, поработать в АБД и синхронизировать их, если перезапись занимает ровно столько же всемени, как и чтение конфигурации. Хотя нет. Перезапись быстрее! Не ситывается при этом железная конфигурация.

Считается что чтение конфигурации делается один раз и далее всё благополучно работает.

Если карту просто удалить - она остаётся в контроллерах.

Попробуйте после этого по ней пройти ;) . Волноваться за судьбу этой карточки не стоит. Работать она не будет, а при первом удобном случае на её место запишется новая.

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

Именно периодически и ночью. На такую работу эта функция и рассчитана. А для повседневной жизни придумана синхронизация.

[Sia-Ori]

Считается что чтение конфигурации делается один раз и далее всё благополучно работает.

Так бы слушал и слушал... Вам бы сказки писать.
С какой версии в Орионе-про удалённый ключ затирается в контроллерах? Sp2 - такого ещё нет.

[MadHacker]

С какой версии в Орионе-про удалённый ключ затирается в контроллерах? Sp2 - такого ещё нет.

С 1.11 точно есть, да и раньше скорее всего был.
Он не затирается в том виде, в котором вы себе это представляете. Он остаётся на месте и его даже можно прочитать. Но он никого не пропустит, потому что контроллер знает, что ключ удалён. А когда вы будете писать новые ключи - на его место запишется новый. Проведите эксперимент в конце концов.
Это сделано для повышения быстродействия. Физическое удаление ключа из контроллера очень ресурсоёмкая операция. По этому применяется отметка "удалён".

Что касается сказок - мы каждый день работаем над тем, чтоб они стали былью. Но, если бы всё зависело только от нас...

Попробуйте нормально настроить синхронизацию. В 1.12 механизм перезаписи изменён не будет.