После профилактики 16/10/2012

старая проблема возвращается, некогда пытались ее решить, но прогресса в эту сторону не было.
тогда gameguard грузил проц периодически, потому как при отключении gg эта проблема пропадала.
странно , что только недавно заметили эту проблему, она существует уже как минимум с лета.
и прошлая профилактика тут не причем, могу заявить со 100 % уверенностью, что и до профилактики скачки в загрузке процесса имелись, то есть прощай стабильность на компах со слабым процем.
в общем начинаю опять следить за этой темой, выкладывать скрины с загрузкой не вижу смысла - ситуация идентичная, что и у других , загрузка стабильно 70 %, с интервалами в минуту - повышается до 100% и длится секунду - две. во времена gg эта длительность была до 30 сек и более))

 

я еще замеры на осаде сделаю потом скрины выложу :aaa:

 

pinguin,

разумеется! именно так легче оценить чистую нагрузку от алгоритма меморискана (на который подозрение). причем клиент у меня почти всегда свернут (поэтому нагрузка от его потоков суммарно редко выше 5% от моего cpu). плюс я старался держать среду идентичной по сторонней нагрузке (другие процессы). такой паттерн для измерения был выбран именно из-за того, чтобы точнее оценить пики от фроста (чисто прирост нагрузки на cpu). а вот продолжительность этой нагрузки - естественно будет зависеть от сторонней нагрузки, от активности самого игрового окна. например у меня клиент загружал cpu на ~50% примерно, и если выполняются крит. по времени операции - продолжительность скана от фроста с тем же пиком, будет просто больше. сама нагрузка от фрост-алгоритма не вырастет ну никак. выше своего чистого потолка, когда ему дают всю мощь фактически, не прыгнуть (общая - вырастет, т.к. клиент активен - это понятно).

соответственно тесты в нагруженном состоянии - уже задача следующая. т.е. если ранее, мы как-то посмотрели на влияния "проблемного" фрагмента на саму нагрузку (пик - разный, а продолжительность у нас идентичная вышла в итоге), то на вашем примере мы сможем оценить влияние фрагмента именно на продолжительность скана в условиях конкуренции за время cpu. очень хороший поинт вы предлагаете, но до этих тестов я еще банально не дошел, если хотите попробовать сами добавить информации - сделайте замеры, особенно интересны wireshark-логи и скриншоты с pe (общая нагрузка или per-process если видите l2.exe.exe).

а тут я с вами объективно не согласен. main-поток игры и сканирующий поток фроста сейчас реально (!) имеют одинаковые как basepriority, так и dynamicpriority показатели. этот показатель у них - normal. это обычное дефолтное состояние для любых программных потоков. занижение приоритета фрост-потока по отношению к графовыводящему потоку клиента приведет к тому, что проверки на неактивных окнах могут не проходить за отведенное время (ибо по классу потоки геймшилда будут вытесняться активным окном + потоками клиента неактивных окон, т.е. выполняться где-то там, когда остальные "отдыхают"). а это приведет к дисконнекту от сервера по таймауту проверки (таймаут сейчас ну неприлично большой). даже при текущих соотношениях приоритетов (равенстве) такие дисконнекты вполне допускаю. более того скажу, в стороннем по часто практикуют перехват сканирующей функции gameshielddll и искусственное подтягивание ей приоритета (чтобы проскакивала быстрее, чтобы неактивные окна не летали по таймауту проверки и прочее). так что можно только в плюс менять этот показатель, но никак не в минус! и сейчас, повторюсь, именно равенство, в котором вы усомнились.

и да, "вдвое" (про фпс) - тут совсем некорректно. если взглянуть на динамику работы main-потока игры, то вы увидите огромное кол-во wait-состояний прежде чем сцена отрендерится и будет выведена на экран (посмотреть можно на самом примитивном уровне все в том же pe). любой wait, любой sleep - сигнал планировщику забыть активный поток и перейти к след. ready-потоку из очереди. а вот в memory-сканах, в любых простых вычислениях "слипы" и синхру (те же waitforsingleobject) ставят редко (могу даже проверить алгоритмы, пожалуй), в итоге скан будет почти всегда интерактивен / ready, и будет соваться планировщиком каждый раз, когда нет никого с приоритетом выше или с таким же и также ready ("графа" в этом случае все равно отдыхает, хоть какой приоритет, ибо она wait банально). поэтому, если рендеринг изобилует wait-ами (мало ли зачем), а его алгоритмы не укладываются нормально в кванты cpu, то потеря фпс-а при наличии тяжелых ready-потоков может быть и существенно больше.

даже глупый код вида while(1); убьет всю графику в 0 фпс легко только потому что никогда не отдыхает, никогда не ждет ресурсов из памяти и прочее, т.е. ready постоянно. к слову, этот же код ядро загонит в 100% (опять же по этой же причине). что уж говорить о любой проверке, которая сложнее. благо в них есть запросы и к памяти, и слипы даже иногда (увеличит продолжительность чего-либо, но заметно убивает среднюю нагрузку) - поэтому мы не наблюдаем оверлоада все таки. за что я тут переживаю более всего - что в алгоритме появился участок, который слишком тяжелый и слишком долго может выполняться (например крутиться в цикле поиска), как описал ранее - он постоянно ready / running и убивает нам фпс. тестами можно попробовать его найти (этому собственно и посвящены мои замеры и результаты ребят выше). в заявленных изменениях таких элементов увы нет, и это напрягает (эффект то почему то заметили все же).

p.s. замеры продолжительности в нагруженном состоянии, думаю, займусь сегодня (с "подозрительным" алгоритмом и без него). но есть проблема - "большого" чара у меня нет, как и знаний контента, чтобы быть в "интересной" локе. могу только побегать в 2 окна где-то попроще, и все надеюсь, это хоть сколько-нибудь будет объективно.

горячий, еще раз спасибо за графики. монументально получилось, впечатляет...
dragontier, а без "повышения" сколько нагрузка?

 

2 окна (в "простом стоячем" состоянии), при поворачивании камеры во фризящем окне, нагрузки на цп не наблюдается
http://s03.**********/i176/1210/d1/313efa3e9f55t.jpg
причем теперь второе окно стало постоянно запускаться во фризе. если свернуть перед запуском второго окна первое, то второе уже нормально запустится. запуская третье окно - аналогично, но второе по запуску окно уходит во фриз, хотя перед запуском 3 окна камера на 2-ом отлично поворачивалась.
приходится теперь шаманить сворачиваниями окон.
при большой игровой нагрузке тоже пока не пробовала

 

порядка 70% на 2 окна, активное и неактивное.

 

dragontier, хм, 30% на фрост-скан, многовато, хоть и быстро. и если не учитывать тех изменений, которые я сейчас пытаюсь все проверить, то алгоритм / интервалы опроса и прочее уже действительно давно такие и никак не с профилактики. однако, нагрузку стали выделять именно после 16, и явно она по характеру принадлежит геймшилду. надо бы с чем-то это связать, в чудеса верить как-то не приходится.

darkverin, интересный график с 2 пиками (окнами соответственно). по поводу запуска во фризе - первый меморискан стартует где-то через 60-90 сек. после входа на сервер, но не ранее. визуально фриз на окне, соответствует пику нагрузки на запускаемом окне? просто, пытаюсь понять - в данном случае заморозка одного окна связана ли со сканом в новом окне (было бы логично) или это просто эффект от загрузки клиента + еще чего-либо например (все дисковые операции достаточно тяжелые).

p.s. а кто-либо на птс-е может проверить хотя бы примерно нагрузки / продолжительность и прочее?

 

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

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

 

radix,вот и я о том же, особенно при игре в 2 окна эти загрузы сильно заметны, причем видно по графику , что грузят оба оба окна с одинаковой периодичностью, правда на неактивном окне нагрузка подскакивает с 5-6% до 30 - 40, соответсвенно начинает тормозить активное окно из за этого, а потом уже и активное прыгает с 70 до 100, выходит , что чем больше окон , тем ситуация жестче.
после профилактики ситуация у меня ровным счетом не изменилась.

на птсе могу глянуть конечно, но только ближе к вечеру.

 

я попробовал, глупый батник

Код:

@echo off
:m
goto m

присаживает fps, но не "в ноль", как это делает фрост. а примерно вдвое.
http://s018.**********/i525/1210/64/40a879187f9f.png
тут видно сосуществование фроста, клиента и упомянутого батника. красная линия, загрузка ядра, это ресурс, который потребляет батник, т.е. чуть меньше половины, а клиенту достается чуть больше половины. комп тот же p4 с ht. если такое запустить на двухъядерном процессоре, то fps, видимо, не пострадал бы почти совсем.

небольшие "провалы" в красном графике - это работа фроста. но и кратковременніе проседания fps в эти моменты тоже наблюдались, т.е. фрост получал ресурс и за счет батника, и за счет клиента. дальше я батник прибил. это вызвало "обвал" и красного и зеленого графика. а дальше потом интересно, длинный подъем зеленого графика - это длинный лаг. фрост "обрадовался" снижению нагрузки на процессор и типа как наверстал упущенное. лаги разной длины - это реальность работы фроста в процессе игры. ваши две с половиной секунды, плюс - минус, не отражают реального извращенного поведения фроста.

 

судя по тому, что при неактивном окне загрузка процессора с ht достигает 100%, понятно, что речь идет не об одном потоке фроста, а об нескольких. клиент в неактивном окне потребляет обычно 5-10%. один поток, любой, на процессоре с ht не может потребить более 50% в принципе. если при неактивном окне клиента загрузка процессора подскакивает до 100%, то понятно, что речь идет не об одном вредоносном потоке, а об нескольких.

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

 

замеры при двух клиентах

1й = верхний находится в дисконекте
2й = нижний в игре

оба окна не активны, пики по 15%-20% на втором окне ~ каждую минуту

http://clip2net.com/clip/m0/1350993084-clip-37kb.png

 

собственно проблема осталась

 

на птс скачки остались правда теперь они не на 100% нагружают проц

 

вот это прикол..я думал у меня у одного логает) жуткие тормоза задержки по 5 -10 сек аж до обрыва с сервером..что на мобах что в городах.. играть не возможно..со вчерашнего дня не играю-не возможно поиграть в такую лагу)

 

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

 

прошу вас воздержаться от флуда в этой теме.

 

проверьте интенсивность отправки пакетов во время пиков загрузки цп

 

юзер 64 битки все еще нужен?

 

gg тоже даёт нагрузку на систему, а ещё и двойной старт (в отдельных случаях). а ещё nc с движком игры так ничего и не сделали, и любая прикрутка отличной от gg системы защиты сносит мозги клиенту вот с такими эффектами. обратная сторона - gg для того чтобы он беспроблемно работал в локализациях за пределами кореи сильно режут по функциям, как итог - он почти не выполняет свои функции.

 

я бы не сказал что тут есть что-то критичное

http://s010.**********/i313/1210/50/10f2e11fc480.jpg

не знаю точно, но операции i/o порядка 40mb (у меня если верить pe), на разных машинах у разных людей ведут себя по разному - это к вопросу о том, что такое frost и как он работает на разном железе ...