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

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

у тестеров/разработчиков фроста нет ли желания просто отлаживаться на компьютерах, соответствующих минимальным системным требованиям ?

мне сейчас напишут, что системные требования написаны "просто так", "понарошку", что они давно не обновлялись, что сайт иновы надо "здесь читать, здесь не читать, здесь рыбу заворачивали"

 

всем привет.
есть отважный доброволец (у которого воспроизводится проблема с нагрузкой) с 64-битной ос, чтобы пообщаться со мной в skype-чате / провести несколько относительно быстрых целевых проверок? если есть возможность дать еще и teamviewer-доступ - было бы вообще чудесно.

 

почему только с 64бит?

p.s долго ж мы вас ждали...

 

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

с ними сейчас проще работать в плане мониторинга (особенно если удаленного доступа нет). на x32 для тех же операций потребуется изрядная координация и опыт - нужно будет 1) антируткитом убрать фрост-драйвер или загрузить игру без него вообще 2) на мониторинг в processexplorer (нужен будет threads analysis) после этого будет не более минуты - потом по вам придет на security-сервер ошибка, и будет выполнен кик. соответственно, если за минуту повторить такого нельзя (а по своему опыту скажу, что это проблематично - нагрузку можно еще не успеть зафиксировать) - то отключать фрост-драйвер придется строго в опред. момент. в общем, много нюансов, которые сделают мониторинг просто сложнее для человека, который с этим не работал достаточное время.

на x32, если желаете, снимите для меня wireshark-лог по инструкции https://forum.4game.ru/showthread.php?t=422289 (да-да именно сетевой, но смотреть я буду там не потери / сигнал, а нечто иное, что даст информацию о процессе сканирования вашей системы). что для этого нужно - берете wireshark, включаете сбор логов, запускаете игру, запускаете диспетчер задач или processexplorer (где приблизительно оцените нагрузку, которую попробуем поймать). далее по часикам примерно замеряете - сколько она длится (чем точнее - тем лучше), и замеряете интервалы нагрузки, если она периодическая. результаты замеров + wireshark-лог мне на анализ.

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

p.s.
у меня вот такие результаты (плохо / хорошо судить не могу - замеров "до" у меня просто нет, плюс я не играю и оценить проседание фпс-а / фризы объективно мне сложно):

Спойлер

http://*********/41059495/image.png

соответственно, если у вас примерно то же (и тут показателен пост и скриншоты darkan и отчасти shadowdmy), и это источник ваших проблем, то я попробую выяснить, что менялось в релизе gameshielddll.dll (то, что на скриншоте у меня - memory scan фроста), менялась ли серверная часть (например интервал сканирования, ранее он был на lineage2 вообще раз в 10 минут, но с тех пор многое уже меняли, когда ввели поминутное - не могу сказать), есть ли какие-то факторы, которые мешают не делать так и не создавать подобной нагрузки так часто.

p.p.s я по прежнему ищу человека с x64 ос + нагрузкой для подобных экспериментов. мне крайне важно увидеть нагрузку и пики на иной машине, замерить интервалы и продолжительность. особенно если это слабая машина - сказываться будет сильнее, чем у меня, а значит memory scan и есть осн. фактор, который надо поправить разработчикам.

 

корейский запостите клиент на систему, которая подходит под минималку, посмотрим что у вас с игрой выйдет. у меня на руках такой конфиг есть, и свежий апдейт в виде lindvior на нём даёт от 18 до 30 кадров в игре. а в городах ползать можно только в режиме "рожей в пол". и на корейском сайте всё обновление требований свелось к переправке требуемого числа оперативки и видеокарты, а сами требования там не менялись по сути со времён c4 и win98.

 

на самом деле это не так, процессор p4 3ггц в минимальных требованиях появился и у корейцев, и у иновы сравнительно недавно. во времена с4 и win98 это был не минимальный, а топовый процессор.

18-30 fps в игре вполне соответствует понятию "минимальных требований". без особого комфорта, но играбельно. у нас после последней профилактики в периоды 100%-ной загрузки процессора игра выдает менее 1 fps в течении ~10 секунд, вот это, на мой взгляд, не играбельно совсем.

 

поддержу тему. действительно после профилактики отмечаются серьезные задержки и проседания фпс.

 

https://forum.4game.ru/showthread.php?t=578312&page=2

withdkd: объединю темы.

 

попробую сделать wireshark-лог и выложить результаты

- - - добавлено - - -

только вопрос: делать лог с запущеной линейкой?

- - - добавлено - - -

куда выкладывать файл с логами?

 

да, важно поймать в этом логе несколько таких фризов / проседаний фпс. вы также можете примерно их засечь по продолжительности.

********* и ссылку мне в пм. либо добавляйтесь в скайп и напрямую.

 

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

 

чуть выше пост, что надо сделать что бы оценить проблему.

 

достало пропишите им в минималках какой нить и3 или и5 чтоб успокоились ужеи наконец то отправили свои пеньки подальше на антресоль

 

полностью поддерживаю информацию о загрузке цп.

тут просто стою в пустом кх, окно игры неактивно даже

 

я бы сказал что 25-30 fps это вполне даже играбельно, особенно если оно стабильно и не в пустых локациях

в чем то да, ухудшение имеет место быть - для меня например это просто скачок fps где то примерно с 70 до 20-30 на пару секунд

Спойлер

http://s002.**********/i199/1210/51/5ae82bf0ef95.jpg

зыs : windows7(64) 6.1 (build: 7601)
cpu : genuineintel intel(r) core(tm)2 quad cpu q9400 @ 2.66ghz @ 2668 mhz 4095mb ram
video : nvidia geforce gtx 460 (142)

 

спасибо за логи darkverin - наиболее "плохой" случай в логах, когда сканирования пересекаются между собой (от разных игровых процессов). т.е. если 1 окно на вашем cpu съело ~2.5с времени, то при перекрытии процедур во времени, на одном окне заняло 3-4с, на другом 5с, при этом суммарная нагрузка была выше оригинальной процентов на 30-40% наверное (по wireshark-логу этого не видно, но судя по моим замерам с 1 окна и поправки на мощность cpu...).

сейчас параллельно идут правки алгоритмов gameshielddll (фрост) относительно данного момента, часть уже оптимизирована, но релиза на pts еще нет (не могу посмотреть билд сам или вместе с кем-либо).

азурит, fatcat, спасибо за логи с периодикой - тут сомнений уже нет, характерные пики и рост i/o очень показательны. кто-либо сможет сделать на текущем билде такие же скриншоты от нескольких окон?

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

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

 

я то думал, почему у меня лаги не воспроизводятся регулярно. у меня i3, два ядра с ht = 4 вычислителя. оплачен 1 па = регулярно запущено два окна. в среду лагало жестоко, но потом, для того, чтобы воспроизвести ситуацию, пришлось побеспокоить старичка p4. получается, что фрост на данный момент в состоянии потребить ресурсы двух вычислителей. на компе с двумя вычислителями периодические лаги будут всегда, но их продолжительность зависит от мощности процессора. на p4 достигает 10 сек, на быстрых core duo фрост выполнит регулярные работы быстро и подлагивания можно даже не заметить. на двухъядерниках с ht или на quad лаги будут проявляться в том случае, если фросты от разных окон будут выполнять свои работы синфазно.

я вот не помню, гг загружался один на любое кол- во окон или как фрост, по экземпляру на каждое окно ?

 

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

более того скажу - мне пока непонятно, что за алгоритм дал столько отзывов на live. модификации просто минимальны. периодика была, разумеется, и ранее. и "перекрытие" было ранее. вопрос, почему это стало заметно только после релиза 9.8.4.23 - для меня еще открыт, сейчас буду пробовать замеры с отключением фрагментов. была версия, что это из-за изменения интервала (ранее он был равен вообще 10 минутам, а сейчас - 1 мин или чуть более), но этот режим уже давно, и дело не в нем. нагрузку, сопоставимую с клиентом, сканирование не давало ранее (имею в виду последние релизы, неудачные - сразу убирались на этапе pts еще).


upd:
первые raw-тесты (модификации - руками, замеры - по wireshark логу, в логе - только первая итерация сканирования, потом "бан / кик" - грубо и рутина но пока так) производительности одного из алгоритмов (в котором, собственно были небольшие изменения, но в тесте исключался вообще весь алгоритм, а не только "добавка" версии 9.8.4.23):
продолжительность сканирование была равна на моем cpu:

2.44c
2.45c
2.38c
2,37с

те же условия с вкл. на live фрагментом:

7.25с
7.20с
2.36с (хм?)
7.65с

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

почему результат еще грубый (и вместе 5 секунд ранее, у меня 7+ секунд сейчас, а потом резко 2.36 и снова до 7) - первая итерация еще сопровождается загрузкой клиента (чтение dat-файлов, прогрузка игрового мира и прочее, поэтому показатели выше - будут больше тех, что в боевом состоянии клиента игры). также это должно говорить, что без отключаемого алгоритма в боевом режиме итерация займет еще менее 2.4с.
почему не прикладывают pe-мониторинга - при загрузке клиента cpu прыгает просто ужасно, i/o-показатель аналогично (сетевые / файловые операции), поэтому выделить так качественно фрост-активность мы не сможем, для этого нужны тесты в idle-режиме игрового клиента.

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

---

upd2: плагин собран на fasm-е, сейчас буду смотреть первые результаты.

показатель продолжительности по wireshark-логу (один запуск - несколько итераций сканирования, с вырезанным фрагментом vs полным фрагментом):
2.40с vs 2.44
5.13с vs 2.35
2.39с vs 2.48
2.60с vs 2.56
2.39с vs 2.36
2.42с vs 2.36

...

графики pe:

Спойлер

фрагмент убрали:
http://*********/41090579/image.png
фрагмент на месте:
http://*********/41090957/image.png

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

p.s. перерыв

 

поехали моя мафынка(знаю знаю видюху пора менять,поменяю скоро http://*********/private/41100806/0ae898407b9760982fc0d65b2c5b3614)
замеры были произведены долго и нудно,но того стоило спс radix

1 окно
http://*********/41100825/image.png

2 окна
http://*********/41100836/image.png

3 окна
http://*********/41100845/image.png

4 окна
http://*********/41100847/image.png

5 окошек
http://*********/41100855/image.png

6 окон
http://*********/41100861/image.png

7 окон
http://*********/41100868/image.png

8,9 без изменения

10 окно
http://*********/41100880/image.png

вообщем все гуд

общий process

http://*********/41100894/image.png

 

2 radix: у вас все пики одинаковые и узкие, такой результат получается, если стоять где - то в бездействии. даже если стоять в адене, где вечные тормоза и лаги, пики загрузки фростом у меня тоже короткие, пара секунд, и до 100% не всегда доходят.

если начать играть, то картина радикально меняется. заходим в картию. там обычно тормозов и лагов, как в адене, нет. а вот загрузка процессора фростом совсем другая. пики загрузки, во - первых, упираются в 100%, во - вторых, продолжительность их очень разная, от 2-3 до 10-15 секунд. если бы процессы клиента и процессы фроста выполнялись с равными приоритетами, то во время этих пиков fps проседал бы, к примеру, вдвое. на самом деле изображение практически замораживается, fps явно меньше 1.

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

я уже утомился чистить мышку, все мне кажется, что она плохо работает. подумывал даже менять. после того, как погамал в линейку от ncsoft, мышка реабилитирована.