Перейти к содержимому
eu_tomat

Время в Майнкрафте

Рекомендуемые сообщения

В эту тему я планирую выкладывать разрозненные фрагменты знаний о времени в Майнкрафте.

 

Здесь можно обсудить всё, что связано с ходом времени в Майнкрафте:

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

 

 

Затравочный пост о лагомерках и лагодромах

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Затравочный пост о лагомерках и лагодромах

 

Выполняя обещание, данное в других темах, привожу список известных мне лагомерок без их подробного анализа:

  • os.clock() растёт быстрее при нехватке вычислительных ресурсов сервера. Предоставляет единственно верный способ оценить шансы приближения TLWY. Но значения os.clock() относительны и зависят от множества факторов.
  • computer.pullSignal(0) в норме выполняется около 4 раз за тик, но во время лагов количество вызовов за тик уменьшается. Вносит минимальный вклад в лаги сервера, т. к. почти всё время тратится на сон. Оно ненулевое, как может показаться.
  • Оценка соотношения роста computer.uptime() и реального времени сервера позволяет вычислить значение TPS. Но падение TPS в чанке не всегда указывает на лаги сервера, так могут проявлять себя штатные механики Майнкрафта и модов.
  • Обращения к периферии в норме требуют для своего выполнения одного тика. Время, затраченное сверх одного тика, сигнализирует о лагах сервера и о возможном устаревании данных, полученных компами от периферии.

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

 

Кроме того, любой интенсивно работающий код имеет ненулевой шанс аварийно завершиться с ошибкой too long without yielding. Этой ошибки на 100% может избежать лишь код, 100% времени проводящий в ожидании. Во всех остальных случаях возникновение TLWY определяется лишь вероятностью. Поэтому, скрипт должен дольше спать и меньше работать. Чем больший вклад вносит скрипт в лаги сервера, тем с большей вероятностью он аварийно завершится по TLWY.

 

Оборачивание кода в pcall не даёт 100% гарантии избежать аварийного завершения по TLWY. Шансы зависят не только от интенсивности вычислений в самом коде, но и от перегруженности сервера. На стабильном сервере pcall почти всегда спасает код от завершения по TLWY. Но на сильно лагающем сервере pcall почти всегда не успевает.

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А если сделать кучу вложенных pcall? Это позволит размазать вероятность TLWY по ним всем и тем самым уменьшить вероятность TLWY на pcall верхнего уровня?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
9 часов назад, hohserg сказал:

А если сделать кучу вложенных pcall? Это позволит размазать вероятность TLWY по ним всем и тем самым уменьшить вероятность TLWY на pcall верхнего уровня?

Каждый дополнительный уровень вложенности кода в pcall позволяет немного снизить шанс аварийного отключения компьютера. Для устремления этого шанса к нулю размер вложенности должен стремиться к бесконечности.

 

Имеющиеся ограничения в OpenComputers позволили мне достичь лишь 195 вложений pcall, а на 196'ом я получил «stack overflow».

 

Поэтому на сильно перегруженном сервере большинство лагодромов завершится синим экраном с надписью «too long without yielding». Максимальная же вложенность кода в pcall позволит лишь немного отсрочить неизбежное.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати, до сих пор я не видел чисел. Проводились ли кем-то статистические исследования TLWY? Известна ли зависимость вероятности возникновения TLWY от тпс при использовании какого-то эталонного кода(типо, бесконечный цикл с ожиданием 0 сек внутри)?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
28 минут назад, hohserg сказал:

Кстати, до сих пор я не видел чисел. Проводились ли кем-то статистические исследования TLWY? Известна ли зависимость вероятности возникновения TLWY от тпс при использовании какого-то эталонного кода(типо, бесконечный цикл с ожиданием 0 сек внутри)?

Я проводил исследования. Количество циклов в эталонном коде зависит от вычислительной мощности физического железа, а также интенсивности процессов, конкурирующих за ресурсы с Майнкрафтом, а потому может отличаться на несколько порядков в каждой конкретной ситуации. Максимум, что я могу дать, это показания, полученные на своей конфигурации, но как потом использовать эти цифры на другой конфигурации?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

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

Гость
Ответить в тему...

×   Вы вставили отформатированное содержимое.   Удалить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.


×
×
  • Создать...