Jump to content

Донат
На хостинг
ISK за переводы
до 75kk за 1000зн.
Хроники EVE
Сборник
Новичкам
Полезная информация
Photo

Замедление времени


  • Please log in to reply
128 replies to this topic

#1
prototype

prototype

    Clone Grade Delta

  • Tech III Pilots
  • PipPip
  • 219 posts
22
  • EVE Ingame:protohuman
  • Client:Eng
Introducing time dilation, CCP Veritas


Замедление времени

Часто говорится, что война против лагов не может быть выиграна, поскольку наши игроки всегда могут привести еще один корабль. Это, по существу, верно, и принятие этой истины важно для работы, которую мы выполняем в команде Gridlock (”затор”). В дополнение к работам по оптимизации, выполняемых нами, мы также боремся с проблемами деградации, чтобы, в случае перегруженности сервера, она обрабатывалась разумным способом. Именно об этом сегодняшний блог. Но, чтобы понять, куда мы движемся, нужно знать, где мы сейчас. В настоящее время, при перегруженности сервера нет никакого явного механизма для обработки такой ситуации. Те же самые механизмы, которые обеспечивают нормальное функционирование, продолжают двигаться собственным ходом. В результате возникает интересное поведение, но мне нужно определить некоторые термины, прежде чем я углублюсь в обсуждение.

Об tasklet’ах, планировщиках, и уступке

Серверы EVE Online, в целом, существуют, чтобы выполнять набор задач – будь это ответ на поступающий от клиента пакет, задача, поддерживающая состояние модулей или, в общем, почти всё. Их называют tasklet’ами, по причинам, о которых вам сегодня знать не потребуется. Так как мы имеем дело с компьютером, только один tasklet может выполнятся в любой момент времени, и должна существовать такая часть программного обеспечения, которая бы решала, какой именно tasklet это должен быть. Эта часть называется планировщиком.

Планировщики бывают совершенно разнообразные. Тот, который управляет tasklet’ами EVE Online довольно прост – это циклический, совместно-многозадачный планировщик. Цикличность означает, что каждому tasklet’у дадут возможность выполнится прежде, чем любому tasklet’y дадут две возможности. Нет никакого установления приоритетов, или специальной обработки - это очень справедливо в том смысле, что каждый получает в свою очередь. Совместная многозадачность означает, что никакой tasklet не будет прерван извне во время его исполнения. Tasklet будет выполняться вплоть до того, как завершиться, либо до вызова специальной функции, которая сигнализирует планировщику, что tasklet желает передать возможность выполниться всем остальным. Это называется уступкой.

Таким образом, то, что мы имеем, является примерно такой системой:
Изображение


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

Другой распространённой причиной, по которой tasklet уступает, является ожидание некоторого ввода от другой машины, например базы данных. Нет никакого смысла сидеть и постоянно спрашивать "оно уже вернулось?" снова и снова и снова - мы можем позволить другим tasklet’ам делать свою работу, пока мы ждём. (Да, технари, это – состояние приостановки, до сигнала о завершении операции ввода/вывода, но остальным это знать не интересно).

Да, чувак, к чему это ты клонишь ?

Извините, мне нравиться писать о компьютерных вещицах. Клоню к объяснению поведения tasklet’ов при большой нагрузке. Если сервер перегружен, то может пройти пять или более секунд, до получения возможности что-либо сделать, после того как ты уступил. Результатом всего этого является то, что задачи, которые либо очень благовоспитанны, или имеют многочисленные требования по взаимодействию, могут, в конечном итоге, завершаться адски длительно, поскольку они проводят большую часть своего времени в ожидании очереди на выполнение. Уничтожение корабля является великолепным примером - требуется множество запросов к базе данных, поэтому tasklet уступает очень часто, в результате чего событие растягивается на несколько минут, прежде чем, наконец, завершится. Схожим образом, модули также могут очень замедлиться в обработке, так как tasklet, который управляет ими, уступает после 100 миллисекунд выполнения.

Я рассказываю вам всё это для того, чтобы мотивировать следующее заявления:

Сервер EVE Online [под нагрузкой] должен деградировать таким образом, чтобы очередь tasklet’ов, ожидающих исполнения, была минимальной – в идеале нулевой.

Именно на это и нацеливается Замедление Времени.

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

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

Регулировка нагрузки выглядит гораздо более привлекательным предложением на данный момент, теперь, когда мы разобрались с кучей легких оптимизации. Были выдвинуты несколько различных предложений о том, что можно было бы сделать. Одно, которое предлагалось большинством в первую очередь – это переход к более низкому разрешению, нежели один раз в секунду, в Destiny, нашей системе моделирования физики, при возникновении перегрузки. Это помогло бы снизить нагрузку выполнения моделирования, но, как оказалось, она составляет только 5-10% от нагрузки, поэтому много мы бы не выиграли.

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

К счастью, у нас есть средство, чтобы регулировать нагрузку, которая даёт нам преимущества, оставляя нетронутым дизайн: сделать время бегущим медленнее. Подавляющее большинство нагрузки в больших схватках привязаны ко времени - модули, физика, перелёты, отварпы, все эти вещи случаются в течение некоторого периода времени, так что замедление времени пропорционально снизит вызываемые ими нагрузки. Таким образом, идея состоит в замедлении внутриигрового времени настолько, чтобы поддерживать очень небольшую очередь ожидания tasklet’ов, а затем, при снижении нагрузки, ускорении времени вплоть до нормального, по мере того, как мы справляемся с нагрузкой. Это будет выполняться на лету, и очень маленькими шажками; нет никаких причин, по которым мы не можем работать на 98% времени, если мы просто немного перегружены.


Хорошо конечно, но как вы себе это представляет во время большого боя?

Вот как я себе это представляю в время большого сражения (к примеру, 1600 или около того). Когда атакующий флот приварпывает, сервер становится сильно перегружен – варп и другие подготовительное задачи, к примеру, выпуск дронов, довольно дороги – и игровое время чрезвычайно замедляется, до 5% реального времени. Как только эти задачи выполняются, у сервера возникает достаточный резерв для безопасного сокращения коэффициента замедления до 30% нормального времени, и к схватке присоединяются должным образом. К этому моменту, у нас 1600 активно противоборствующих пилотов, с быстрым и справедливым подтверждением запросов, но просто используется в 3 раза больше времени, чем обычно. Игроки во флотах могут заметить это, потому что замедлилась анимация элементов управления кораблём, и взрывы в космосе происходят как будто в замедленной съёмке. По мере того, как всё больше кораблей уничтожаются/улепётывают, нагрузка, вызываемая сражением, снижается, и, по достижении около 1200 участников, оценивая-предугадывая, мы вернёмся к 60% нормального времени. Может быть в этот момент один из командиров понимает, что проигрывает, и приказывает отступать. Отварп также дорог, поэтому часы замедляются, скажем, до 10%, пока флот сматывается. С завершением битвы, и уходом проигравших, нагрузка на сервер становится малой, и он возвращается к 100% времени.

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


Время управлять ожиданиями !

Замедление времени не решает всех вопросов. Некоторые нагрузки не привязаны к продолжительному времени, поэтому у нас не будет возможности обрабатывать бои бесконечного размера. Сегодня мы находимся в точке, в которой это будет охватывать все, что мы видим на регулярной основе. Я думаю, однако, мы должны будем поставить жесткое ограничение на то, как сильно мы готовы замедляться. Нет смысла в замедлении системы до 0,1% времени, поскольку никто не сможет ничего сделать, и это ни к чему не приведёт. Я не знаю, где будет этот порог - это то, с чем мы должны будем поиграться после развертывания. Если бои будут постоянно превосходить этот порог, каким бы он не был выставлен, мы окажемся ровно там же, где и сегодня – с сервером, становящимся невосприимчивым, противным, и прочим. Посмотрим.

Это был довольно длинный блог, всё, что здесь сказано – это супер-предварительно. Это была идея, всплывшая на моём радаре уже давно, но пока по ней выполнено не так много фактической работы, на настоящее время. Мы сделали прототип еще в августе, чтобы доказать, что игра может работать с замедленным временем, и он остался ровно на этом этапе. Положительные отзывы после упоминания идеи на фанфесте, в сочетании с освещением этой идеи CSM’ами как стоящей на вершине текущего списка их пожеланий убедили меня, что это идея, время которой пришло. Это довольно большой проект, так что я практически уверен, что она не будет реализована этим летом. Осень – весьма вероятно, если дела пойдут хорошо.


Короткая версия блога:

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


--------

Выборочные посты CCP Veritas в теме с обсуждением:

#1
McThife: Мне не понравилось, как вы отбросили вариант с многопоточностю. Работа в многопоточных средах на различных платформах с различными серверами приложений показывает, что многопоточность в системах с высокой нагрузкой является решением №1. Я знаю, что это, вероятно, не самая простая вещь для воплощения, и движок EvE, вероятно, архитектурно построен вокруг однопоточной модели, но, пожалуйста, не говорите, что этот подход не дал бы выигрыша.

CCP Veritas: Я лишь сказал, что он не дал бы такого большого выигрыша, как многие думают. Переход к, скажем, 4-ём потокам не учетверяет производительность, за исключением ошеломляюще лёгких случаев. С накладными расходами, и требующимися блокировками, нам сильно повезёт, если мы получим 2х-3х кратный прирост производительности при 4-ёх потоках.
Учитывая количество усилий, которые необходимо предпринять, чтобы это реализовать, и последующих усилиях на поддержку многопоточного кода, это не будет лучшим планом прямо сейчас. Мы это неизбежно сделаем, через какое-то время. По этому пути сейчас идут очень многие.


#2

fossura: Какого размера будет зона, испытывающая эффект замедления, будет ли это грид, в котором происходит бой в системе, и т.д. Интересует вопрос, если битва длится в 5 раз дольше обычного, даст ли это одной из сторон преимущество в возможности привести подкрепления, и можно ли вызвать такой эффект по желанию, к примеру, группируя оружие и выпуская/отзывая дронов всем флотом ?

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

Edited by prototype, 24 April 2011 - 11:05.

  • 3

#2
Houdan

Houdan

    Newbie

  • Tech I Pilots
  • 3 posts
-1
  • Client:Eng
Лучше бы лаги пофиксили

РО неделя, за оригинальность

Edited by Liteik, 23 April 2011 - 17:05.

  • -1

#3
Spitfire*Нейтрал

Spitfire*Нейтрал
  • Guests
Отано, пошаговая ММОРПГ про спейсшипы и их сериоус бизнесс.
Интересно, как это все будет работать, особенно с отдачей приоритетов кому чт оисполнять :)
  • 0

#4
DIMFIRE

DIMFIRE

    Кавайчег

  • Tech III Pilots
  • PipPipPipPipPipPipPipPipPipPip
  • 27549 posts
2125
  • EVE Ingame:DIMFIRE Dimiana DlMFlRE
  • Client:Eng
Что то мне уже страшно
Posted ImageИзвините за мой французкий

ИИИИИИИИИИИИ ДДДДДДДДДДДДДДАААААААААААААААААА ЗЗЗЗЗЗЗЗЗЗЗЗДДДДДДДДДДДДРРРРРРРРРРРРРААААААААААВВВВВВВВВВСССССССССССССТТТТТТТТТТ
ТТВВВВВВВВВВВУУУУУУУУУУУУУУЕЕЕЕЕЕЕЕЕЕТТТТТТТТТТТ ЭЭЭЭЭЭЭЭСССТТТОООНННСССССККККККОООООООЕЕЕЕЕЕЕЕЕЕЕЕЕЕЕ ПППППППППППППВВВВВВВВВВВППППППППППП

Единственное работающее решение-многопоточность-опять откладывается. И это печально

Edited by DIMFIRE, 23 April 2011 - 16:23.

  • 0

#5
January

January

    Clone Grade Mu

  • Tech III Pilots
  • PipPipPipPipPipPipPip
  • 7376 posts
330
Идея понятна, перевод ужасен. Всё равно спасибо, на английском просто лень было бы читать.

К сути раскрытого механизма пока не знаю как относится. Надо подумать.
  • 0

#6
Edgardus

Edgardus

    gaybond pilot

  • Tech III Pilots
  • PipPipPipPipPip
  • 2017 posts
308
  • EVE Ingame:sold
  • Ally:GE
  • Channel:noobian club
  • Client:Eng
неужто долгожданный фикс кта-лагалищ?
  • 0

Eve account - $15 US a month, dreadnaught - 2 Billion ISK, hiring a mercenary Dust group to assault a planet- $5 million ISK now, $50 million when the job is done.
Bombarding the Dust team from orbit and laughing like the machiavellian and sociopathic dickhead spreedsheet have made you, then recording the console tards emo tears and posting them on youtube? Priceless

 


#7
Aristash

Aristash

    Открылась бездна, звезд полна, Звездам числа нет, бездне дна.

  • Tech III Pilots
  • PipPipPipPip
  • 1140 posts
157
  • EVE Ingame:Aristash
  • Client:Eng
в исландии закончились грибы и начался сезон какой-то жосткой барбитуры.

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

про это и так всем ясно что Вам (ццпшникам) жалко денег на нормальный сервер(а) и вы попрубуете даже немного погореть в аду перед покупкой.

Не скупитесь, лучше подумайте о конкурентах и купите действительно мощщный сервер...
  • 1

"Те, кто достаточно умен, чтобы не лезть в политику, наказываются тем, что ими правят люди, глупее их самих" -- Платон

"В отсутствии достойного руководства, каждый может стать неблагонадежным" -- Роб Смит
"Смерть не имеет к нам никакого отношения, когда мы есть, то смерти еще нет, а когда смерть наступает, то нас уже нет" -- Эпикур


#8
DIMFIRE

DIMFIRE

    Кавайчег

  • Tech III Pilots
  • PipPipPipPipPipPipPipPipPipPip
  • 27549 posts
2125
  • EVE Ingame:DIMFIRE Dimiana DlMFlRE
  • Client:Eng
Нету конкурентов-потому и такое отношение. С надеждой ждем БП и инфинити-пусть даже мы и не будем в них играть(а может у будем)-но конкуренты полюбому заставят гадское ццп шевелиться.

Edited by DIMFIRE, 23 April 2011 - 16:38.

  • 0

#9
St1'n'Gear

St1'n'Gear

    Суровый карибас

  • Tech III Pilots
  • PipPipPipPip
  • 1033 posts
68

в исландии закончились грибы и начался сезон какой-то жосткой барбитуры.

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

про это и так всем ясно что Вам (ццпшникам) жалко денег на нормальный сервер(а) и вы попрубуете даже немного погореть в аду перед покупкой.

Не скупитесь, лучше подумайте о конкурентах и купите действительно мощщный сервер...

Как уже писали в теме про аномальки, проблема в том что у ппц нет конкурентов, поэтому они и сидят на попе ровно
  • 0

Пора бы уже понять, что карибас не будет страдать.

Не забывай, у всех капсулиров стальные яица в прямом смысле слова


#10
Aristash

Aristash

    Открылась бездна, звезд полна, Звездам числа нет, бездне дна.

  • Tech III Pilots
  • PipPipPipPip
  • 1140 posts
157
  • EVE Ingame:Aristash
  • Client:Eng

Как уже писали в теме про аномальки, проблема в том что у ппц нет конкурентов, поэтому они и сидят на попе ровно


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

"Те, кто достаточно умен, чтобы не лезть в политику, наказываются тем, что ими правят люди, глупее их самих" -- Платон

"В отсутствии достойного руководства, каждый может стать неблагонадежным" -- Роб Смит
"Смерть не имеет к нам никакого отношения, когда мы есть, то смерти еще нет, а когда смерть наступает, то нас уже нет" -- Эпикур


#11
Ange1

Ange1

    Clone Grade Theta

  • Tech III Pilots
  • PipPipPipPip
  • 1109 posts
106
  • EVE Ingame:xAnge1x
  • EVE Alt:Nlka
  • Corp:Red October
  • Ally:Fast Kick
  • Channel:RO Squad
  • Client:Eng

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

чукча не читатель... слабо прочитать первый пост до конца?
  • 0

#12
Баралгин

Баралгин

    Clone Grade Eta

  • Tech III Pilots
  • PipPipPipPip
  • 562 posts
-24
  • EVE Ingame:Баралгин
поздняк метаться, китайский сервер ДРФ не за горами, мега побоища уходят в историю.
  • 0
Я Баралгин, сын Аспирина.

#13
Kales

Kales

    Clone Grade Delta

  • Tech III Pilots
  • PipPip
  • 202 posts
9
  • EVE Ingame:Ruin Orman
  • Corp:A.OPS
  • Ally:Gy B.
  • Client:Eng
Прикольно. Всё равно в лагах всё активируется по 5-10 минут. Теперь зато можно будет смотреть в замедленной съёмке как взрывается очередной пимп мобиль. Или мучительно долго наблюдать свою смерть в капсуле. А так же не стоит забывать минутную очередь из пулемёта, непрекращающийся луч лазера и анимация думсдея длинной в час.

Edited by Kales, 23 April 2011 - 17:10.

  • 0

#14
Алекс диГриз

Алекс диГриз

    SN1054

  • Tech III Pilots
  • PipPipPipPipPip
  • 1580 posts
254
  • EVE Ingame:Alex diGriz
  • Client:Eng

Лучше бы лаги пофиксили

внезапно блог именно об этом
  • 0

Изображение


#15
DIMFIRE

DIMFIRE

    Кавайчег

  • Tech III Pilots
  • PipPipPipPipPipPipPipPipPipPip
  • 27549 posts
2125
  • EVE Ingame:DIMFIRE Dimiana DlMFlRE
  • Client:Eng

поздняк метаться, китайский сервер ДРФ не за горами, мега побоища уходят в историю.

Ты говоришь об этом так, как будто это плохо.

Что до того что будет китайский сервер-сомнительно. Если и захватим всю еву-то скорее всего просто сбросим стенды и начнется эпоха веселых роамингов
  • 0

#16
January

January

    Clone Grade Mu

  • Tech III Pilots
  • PipPipPipPipPipPipPip
  • 7376 posts
330
А разве у ССР и без апгрейдов, прям щас, не один из самых мощных кластерных суперкомпов в игровой индустрии? Так что пускай лучше ломают голову как код исправить. Тупо добавить железа и тупо его залагать всегда успеется.
  • 1

#17
prototype

prototype

    Clone Grade Delta

  • Tech III Pilots
  • PipPip
  • 219 posts
22
  • EVE Ingame:protohuman
  • Client:Eng

А разве у ССР и без апгрейдов, прям щас, не один из самых мощных кластерных суперкомпов в игровой индустрии?


На фанфесте говорили о сервере (статья с joystiq)

"We saw some impressive stats on recent server upgrades, with developers revealing they'd be the first company in the EU to own a new unannounced $50,000 IBM server using a new unannounced Intel processor. If that's not cutting-edge, I don't know what is."

$50,000 - это как для сервера, много, мало, или нормально ?
  • 0

#18
January

January

    Clone Grade Mu

  • Tech III Pilots
  • PipPipPipPipPipPipPip
  • 7376 posts
330
Для одного - нормально, даже жирно. А для всего кластера - жидко :)
  • 0

#19
DIMFIRE

DIMFIRE

    Кавайчег

  • Tech III Pilots
  • PipPipPipPipPipPipPipPipPipPip
  • 27549 posts
2125
  • EVE Ingame:DIMFIRE Dimiana DlMFlRE
  • Client:Eng

А разве у ССР и без апгрейдов, прям щас, не один из самых мощных кластерных суперкомпов в игровой индустрии? Так что пускай лучше ломают голову как код исправить. Тупо добавить железа и тупо его залагать всегда успеется.

Мощность кластера как такового значения уже не играет-ибо более одной машины систему обрабатывать не может. Производительность всего кластера начнет играть роль только в одном случае-переделка кода под многопоточность. НО именно это согластно девблогу откладывается на неопределенный срок

Edited by DIMFIRE, 23 April 2011 - 17:40.

  • 0

#20
January

January

    Clone Grade Mu

  • Tech III Pilots
  • PipPipPipPipPipPipPip
  • 7376 posts
330
Житу же побустили тупо в лоб апгрейдом железа. Но код менять надо, конечно. С этим спорить смысла нет.
  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users