Почему при сохранении данных в спад архиве такие большие потери данных, неважно даже сколько каналов пишется в архив хоть 1 хоть 100 потери одинаковые 35-45 потерянных значений из 100 при ETHERNET 100Мбит/сек. Добавлены NCB блоки, на прием, на верхнем уровне, установлен флаг – интенсивный прием, тип каналов как InNet так и InAutoNet потери одинаковые. Цикл пересчета 0,01сек, тип протокола NetBEUI, WinXP SP1.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
А в контроллере какой цикл пересчета?
Posted by zem21 (Участник № / Member № 418) on :
Также 0,01сек.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) 10мс - довольно критичный цикл для MS Windows (это предел его таймера). 2) Проверьте лог-файлы Микро МРВ и МРВ - может все же не хватает NCB-на прием или передачу? Тогда сервер об этом обязательно напишет в лог. 3) Уберите InNet с цикла 10 мс - это создает дополнительный перерасход NCB в системе.
Posted by zem21 (Участник № / Member № 418) on :
1) Установили цикл на обоих уровнях 20мс - ситуация аналогична, даже в проекте где всего 1 канал InAutoNet - потери 35-45 значений из 100. 2) Все лог-файлы проверили, ошибок не обнаружили. В скобках указаны значения для МикроМРВ … NET:NCB for AutoSend = 0(2) NET:NCB for AutoSend float value = 0(1) NET:NCB for SendToNet = 0 NET:NCB for CopyFrom = 0 NET:NCB for Registrator = 0 NET:NCB for Recieving = 7 (40) NET:iname ARG@@S1 NET:gname ARG@@S° NET:found 5(1) adapters NET: select 3(0) adapter with 3(0) number NET:init 3(0) adapter … NET:total NCB send 0(3912),error 0 = 0 NET:total NCB recieve 1406(3912),error 0 = 0 …
Проводил ли кто-нибудь аналогичное тестирование? Какие результаты?
Posted by Kramarenko Stanislav (Участник № / Member № 119) on :
У меня работают дублированные узлы без DoubleForce, я там оцениваю состояние партнера по присылаемым им системным секундам, при этом тоже случаются пропуски (остальные каналы меняются не чаще). На АСУТП нашего первого блока (ТюмТЭЦ-1) те же вопросы - передача большого количества данных по автопосылке вовсе не гарантирует доставку (по крайней мере немедленную). Все управляющие сигналы обязательно должны проверяться обратным запросом на предмет доставки.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Можно также лог-файл МРВ здесь показать?
Posted by zem21 (Участник № / Member № 418) on :
Лог-файл МРВ.
Professional Editional DRAWSERV 5.12 SUPPORT: NetBios INFO:Load Starting... C:\TraceMode5_Professional\mli2\node1.dbb INFO:Detected NT 5.1 INFO:Found 1 channels NET:NCB for AutoSend = 0 NET:NCB for AutoSend float value = 0 NET:NCB for SendToNet = 0 NET:NCB for CopyFrom = 0 NET:NCB for Registrator = 0 NET:NCB for Recieving = 7 NET:iname ARG@@S1 NET:gname ARG@@S° NET:found 4 adapters NET: select 3 adapter with 3 number NET:init 3 adapter INFO: LoadTime=3.125s CalcPeriod=9ms NET:starting... SIAD:starting... SIAD: opening file: C:\TraceMode5_Professional\mli2\p.rep SIAD: starting server... RTM:math kernel starting... INFO: start time is 0.484 s SCREEN load error screen.000 INFO:work mode INFO:stoping... SIAD: stopped. NET:total NCB send 0,error 0 = 0 NET:total NCB recieve 25707,error 0 = 0 NET:rasf=25703 rash=0 = 0 INFO: stop time is 0.437 s INFO:number of calculation = 13959 END OF WORK
Лог-файл МикроМРВ.
Professional Editional MRT 5.091 INFO:Load Starting... c:\mrt\demo\MLI2\nod.dbb INFO:Detected DOS = <1802 70a> INFO:Found 1 channels FBD_DLL not found fbd0.dld FBD_DLL not found fbd1.dld FBD_DLL not found fbd2.dld FBD_DLL not found fbd3.dld FBD_DLL not found fbd4.dld FBD_DLL not found fbd5.dld FBD_DLL not found fbd6.dld FBD_DLL not found fbd7.dld FBD_DLL not found fbd8.dld FBD_DLL not found fbd9.dld NET:VECTOR 5C found NET:NCB for AutoSend = 2 NET:NCB for AutoSend float value = 1 NET:NCB for SendToNet = 0 NET:NCB for CopyFrom = 0 NET:NCB for Registrator = 0 NET:NCB for Recieving = 40 NET:iname ARG@@S2 NET:gname ARG@@S° NET:found 1 adapters NET: select 0 adapter with 0 number NET:init 0 adapter INFO: LoadTime=5.71s CalcPeriod=4ms INFO: resolution=0.005 NET:starting... RTM:math kernel starting... INFO: start time is 0.22 s JRT:timer constant is = <5950 173e> INFO:work mode INFO:stoping... JRT: mem lock 0 0 NET:total NCB send 25892,error 0 = 0 NET:total NCB recieve 25892,error 0 = 0 INFO: stop time is 0.05 s INFO:number of calculation = 25892 END OF WORK
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Ну где Вы установили 20 мс?? У МРВ - "CalcPeriod=9ms", а у Микро МРВ - "CalcPeriod=4ms". Это значит, что Микро МРВ отправляет посылки в два раза быстрее, чем МРВ может принять - как минимум половину посылок в МРВ у Вас должно теряться! Posted by zem21 (Участник № / Member № 418) on :
Прошу прощения, недосмотрел, просто производилось множество тестов с различными временными характеристиками.;-) Для того, чтобы разъяснить ситуацию, выслал вам проект, zem21.rar, с циклом 20мс, архивом и лог-файлами (NODE1.txt) для верхнего и (NOD.txt) для нижнего уровней.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Попробуйте увеличить число каналов до нескольких десятков или сотен. Тест на таких скоростях всего для одного канала не всегда показателен, потому как 1-2 NCB блока на один канал - это не эффективно. 2) Если есть "хаб" или "свитч", то рекомендую во время обмена посмотреть число коллизий в сети, если конечно МРВ и контроллер в ней не одни.
Posted by zem21 (Участник № / Member № 418) on :
1. Тестовый проект увеличил до 128 каналов - ситуация осталась без изменения, идут потери 35-45 значений из 100, ошибок в лог файле связанных с NCB-блоками нет, увеличил проект до 512 каналов – потери идентичны, ошибок в лог файле связанных с NCB-блоками нет. Среда разработки – профессиональная версия. 2. Тесты проводились и через patchcord, и через switch (с несколькими компьютерами в сети), результат в принципе одинаковый. Каким образом просмотреть количество коллизий?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Попробуйте изолировать Вашу сеть, соединив контроллер и ПК как точка-точка. Обычно на панели "хаба" или "свича" есть индикатор коллизий - по интенсивности его свечения можно судить о количестве коллизий в сети.
Posted by zem21 (Участник № / Member № 418) on :
По поводу изоляции сети я уже писал, что проводил тесты на patchcord’e и результат идентичен тестам через switch. Количество коллизий в сети определить у нас не получится, нет аппаратных средств. Проводил тестирование на двух МРВ 512 каналов, цикл пересчета 10мс, получил в результате 25 потерянных значений из 500 ????????
Posted by zem21 (Участник № / Member № 418) on :
Господа ответьте пожалуйста на вопрос заданный выше.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
08.04.2004 Вы же уже сообщили, что у Вас все нормально и Вы с проблемой разобрались?
Posted by zem21 (Участник № / Member № 418) on :
Нет, проблема стоит в полный рост. Наличие коллизий мы определить не можем, ввиду отсутствия соответствующего индикатора на коммутаторе. Большие потери значений. Как следствие – невозможность применения Trace Mode 5 в системах диагностики. Если у Вас подобный тест дает отличные результаты - пришлите Ваш тестовый проект (с архивом и логами) и мы попробуем его у себя? Так мы сможем определить в чем проблема – в железе или программах, если в программах, то в драйверах или в Trace Mode.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
1) Избежать потерь в сети Ethernet все равно невозможно - это не та среда, где 100% гарантирована доставка данных. 2) При передаче данных Вы допускаете одну ошибку - (вспоминаем знаменитую теорему Котельникова) чтобы достоверно принять сигнал из канала с чатотой дискретизаци F приемник должен иметь частоту дискретизацию как минимум 2*F. Иначе сигнал будет искажен! Я провел тест на следующем проекте: Узел контроллера - 50 каналов генераторов пилы с циклом пересчета 20 мс все каналы посылают значения в сеть. Узел АРМ - принимает 50 каналов по сети с периодом в 10 мс. Значения по каналам архивируются в СПАД. В результате теста потери данных составляли около 2-3 значений на 1000 принятых (по каждому каналу). Учитывая то, что контроллер и АРМ были подключены в общую сеть нашего офиса, к тому же контроллер подключался через коаксиальный кабель и хаб - то показатель потерь в 0,3% очень даже хороший.
3) Вторая ошибка - "невозможность применения Trace Mode 5 в системах диагностики", правильней будет: невозможность построения системы диагностики исходя из той архитектуры, которую Вы пытаетесь реализовать. Если стоит задача собрать большой объем достаточно динамичных данных и передать их на другой узел и при этом НЕ ПОТЕРЯТЬ НИ ОДНОГО ЗНАЧЕНИЯ, то решать эту задачу надо соответсвующим образом. Для этого надо собирать данные в блоки по месту их регистрации и отправлять приемнику в виде этих самых блоков (буферизация данных), а не отправлять каждое значение с частотой его изменения.
![[Недоумение / Confused]](confused.gif)
![[crazy / сумасшедший]](graemlins/crazy.gif)