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

[eu_tomat 2 154]

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

 

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

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

 

 

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

[eu_tomat Автор темы 2 154]

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

 

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

• 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 почти всегда не успевает.

 

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

 

[hohserg 197]

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

[eu_tomat Автор темы 2 154]

9 часов назад, hohserg сказал:

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

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

 

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

 

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

[hohserg 197]

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

[eu_tomat Автор темы 2 154]

28 минут назад, hohserg сказал:

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

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

[Taruu 30]

А можно ли лаги сервера ловить при помощи реального времени?
Или же там тоже будут жуткие неточности? 

Просто программа може проверять TPS после сна, перед выполнением программы.
Запросить текущее реальное время, поспать N число тиков и посмотреть сколько времени прошло и сравнить с ожидаемым результатом.

[eu_tomat Автор темы 2 154]

1 час назад, Taruu сказал:

А можно ли лаги сервера ловить при помощи реального времени?
Или же там тоже будут жуткие неточности? 

Конечно же, можно.

В 29.07.2020 в 11:25, eu_tomat сказал:

Оценка соотношения роста computer.uptime() и реального времени сервера позволяет вычислить значение TPS. Но падение TPS в чанке не всегда указывает на лаги сервера, так могут проявлять себя штатные механики Майнкрафта и модов.

 

[Taruu 30]

А да. Чет проморгал )