Решили мы развести наши модули I-7000 на несколько линий, для чего приобрели плату Moxa CP-204J (4 RS-порта, интеллектуальная). Начали проводить сравнительные испытания "Интегрированный на материнку СОМ-порт против порта Moxa". Для этого использовали "Trace Mode" и "I-7000 Utility". Результат нас крайне удивил. При использовании I7000util с платой CP-204J снизились: загрузка процессора задачей на 40%, количество прерываний на 17%. При использовании TraceMode те же показатели выросли: загрузка процессора задачей на 160%, количество прерываний на 64%. При обновлении драйвера CP-204J с в.1.1 до в.1.4 показатели I7000util практически не изменились, а TraceMode выдал увеличение показателей относительно интегрированного порта: загрузка процессора задачей на 1677% (с 1,8% загрузки процессора до 32%), количество прерываний на 24%. Исходя из того, что использование платы CP-204J (и прочих из серии Intellio фирмы Moxa) должно снижать нагрузку на ценральный процессор и мы увидели это при использовании программы I7000util, осмелюсь предположить, что TraceMode работает некорректно с такими устройствами. Ваши комментарии...
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Мы уже сталкивались с тем, что "интеллектуальные коммуникационные платы имеют определенные особенности функционирования", связанные с тем, что они "с целью оптимизации" предполагают работу в обход системных функций. Многие утилиты именно так и работают. Модули Трейс Моуд используют для поддержки коммуникаций только системные функции. А с ними такие "интеллектуальные" платы работают неэффективно. В версии Трейс Моуд 6 мы будем рассматривать вопросы оптимизации коммуникационных процедур.
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
Я понимаю, что все ваши силы сейчас брошены на шестую версию, но думаю, что обмен по последовательным портам является достаточно важной задачей, тем более, что вопросы по нему возникали (по крайней мере у меня) и до настоящей ситуации, которую я не могу рассматривать иначе, как существенное упущение, ввиду того, что проведенные мною дополнительные испытания с использованием программ различных производителей доказали эффективность "железа". Буду искренне рад, если у вас найдутся силы проработать данный вопрос в рамках пятой версии.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Мы учтем Ваше пожелание.
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
Поскольку платы уже закуплены, пришлось написать собственный драйвер обмена по произвольному носителю (простому системному СОМ-порту, но на плате CP-204J) c протоколом ADAM ASCII.
При этом для снижения нагрузки на процессор пришлось исключить проверку на наличие данных в буфере, т.е. просто читаем спустя таймаут (15 мс на скорости 19.2 кбит при поканальном опросе и 40 мс при групповом; при 115 кбит оба таймаута сравниваются на 12 мс).
Кроме того, чтобы снизить количество прерываний использовали вызов процедуры чтения из буфера по прерыванию от платы по приходу контрольного символа (в данном протоколе это - CR(13)) - количество прерываний упало почти вдвое.
Но это - не выход из положения. Надо, чтоб ТМ сам справлялся. Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Проблема достаточно важна. Мы учтем это в дальнейшем.
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
Время у нас идет медленно, но мы уже собралсь внедрять. И тут возник вопрос!
Насколько мне известно, при штатной работе с системными СОМ-портами TM запускает опрос по каждому из них в отделном потоке. Так ведь?
А у нас этой прелести не получится, поскольку драйвер (media_.dll) один на многопортовую плату и все каналы будут опрашиваться последовательно в одном потоке, хоть и обращаются к разным портам???
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Тогда как варианты: 1) Создать несколько драйверов TYPE_12 для каждого СОМ-порта, тогда они будут работать в разных потоках. 2) Создать внешнее приложение для обмена по СОМ-портам, а с DrawServ оно будет обмениваться по COM-интерфейсам. Например, как вот этот программный задатчик: http://forum.adastra.ru/ubb/ultimatebb.php?ubb=get_topic;f=11;t=000056 Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
По первому варианту вопрос - А надо ли для каждого СОМ-порта делать свою пару t12sN.dll + media_.dll или достаточно оставить один media_.dll и сделать только несколько t12sN.dll, которые будут вызывать media_.dll, естественно обращаясь к разным портам?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Нет - не обязательно, media_.dll может быть одна.
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
Случайно :-) прогнали тесты, описанные в первом сообщении не на Win2000 Server, а на Professional!!! На Professional CP-204J работает нормально, но на Server, что на 2000, что на 2003 - все по прежнему.
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
Положительный результат теста оказался случайным стечением обстоятельств. Каких именно теперь не знаем и повторить не можем. Есть влияние версии драйвера и настройки BIOS SETUP "PnP OS"=Yes/No, но влияние не принципиальное. Через наш драйвер КОНТР_12 обмен медленнее на 15%, поэтому до сих пор эксперементируем.
В связи с этим вопрос: как ТМ, например для КОНТР_11, определяет что приняты все требуемые данные? Циклически подчитывает данные из буфера порта и многократно вызывает функцию Check_xxx до истечения тайм-аута?
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
Предыдущий вопрос снимается - разобрались.
Возник новый в результате переписки c компанией Moxa. Их последний ответ про работу DrawServ с COM-портом звучит так: "In fact, your utility could reduce to call the purge_comm (flush) function. Because your application is a traditional polling and responding application, there should not any garbage on serial buffer. So, it is not need to call purge_comm function frequency. Then everything should be fine." , что в литературном переводе примерно следующее - "Ваша утилита (мы посылали им DrawServ) могла бы уменьшить количество вызовов функции очистки буфера порта. Поскольку ваше приложение является традиционным приложением, работающим по принципу запрос-ответ, то в буфере порта не должно быть мусора. Поэтому не нужно так часто вызывать функцию очистки. В результате все должно быть прекрасно."
т.е. в начале каждого вызова буферы чистятся, а если устройство не отвечает, то чистятся подряд два раза (!!!). ЗАЧЕМ? Зачем это делать? Карта у меня слишком умная, да и буферы не маленькие - она этого не любит. Я понимаю, что это отчасти вопрос совместимости, но ведь действительно можно буферы не чистить!!! Если будет мусор, будет недостоверность - по ней, согласен, нужно очистить (что, в-общем-то, и имеет место), а при нормальном обмене это считаю лишним!
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Это действительно так - и процедура очистки буфера производится перед каждым запросом. Причина - многие протоколы (особенно I7000 совместимые) в кадре ответа не содержат номера устройства его приславшего, поэтому может возникнуть ситуация, что сервер на запрос следующего устройства может принять пакет в буфере за уже готовый от него ответ, хотя на самом деле это ответ на совершенно другой - предыдущий запрос. Пример - поканальный опрос входов модуля I7017, если при этом не чистить буфер перед каждым запросом, все принимаемые значения "поплывут", потому как невозможно контролировать от кого пришел ответ.
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
Вынужден согласиться - такое возможно, если таймаут катастрофически мал и ответ начинает поступать уже после его истечения и очистки буфера по недостоверности, а пауза до следующего запроса достаточно велика, чтобы ответ поступил полностью. Однако, чаще всего такого не происходит, т.к. следующий запрос начинается сразу после получения ответа (или истечения таймаута) предыдущего, т.е. интерфейс постоянно занят и запоздавшему ответу просто не пробиться. Я бы на месте разработчика оставил такую функцию, как постоянная очистка буфера на усмотрение пользователя.
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
А с другой стороны, вместо очистки буфера можно просто считать из него все данные перед новым запросом и "выкинуть" (в смысле никак не обрабатывать) - эффект будет тот же.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Чистка буфера - это всего лишь частная функция обмена. Не исключено, что завтра появится (или уже появилась) какая-нибудь "умная" плата, которая еще какие-то особенности имеет. Нельзя гарантировать, что не придется и под нее подлаживаться. А при этом надо еще обеспечить и совместимость со стандартными, "не очень умными" платами и интегрированными портами. Либо надо менять системные стандарты, либо писать в каждом случае свои собственные драйверы. Те решения, которые Вы приняли при написании собственного драйвера, ориентированы на конкретный протокол. В Трейс Моуд для всех протоколов принята единая идеология.
Да и само стремление снизить нагрузку на процессор от задач обслуживания COM-портов не выглядит убедительным. Вы же сами пишете, что интегрированные порты ("тупые") загружают процессор всего на 1.8%. Основная нагрузка на процессор - это не COM-порты, а графика, межзадачный интерфейс, файловые операции, сеть и пр.
![[Пдмигивание / Wink]](wink.gif)
![[Спокойствие / Cool]](cool.gif)
![[prey / молящийся]](graemlins/prey.gif)
![[master / мастер]](graemlins/master.gif)
И тут возник вопрос!![[Неодобрение / Frown]](frown.gif)