eu_tomat

Разрабы, скорее всего, и знать не знают, что кто-то пытается снять с реактора больше 8192 eu/t. А если и узнают, то, как минимум, потребуется добавить приёмники такой энергии. Интересно, а GT снимает с реакторов ограничение по выработке энергии? Там же есть соответствующие провода, трансформаторы и энергохранители.

А что мешает вместо красного контроллера использовать красную плату?

Состояние выходов красного контроллера сохраняется даже при выключенном компьютере. Но если реактором управляет компьютер с помощью встроенный красной платы, то реактор погаснет вместе с компьютером. Это возможно. По крайней мере, теоретически. В пределе можно заменить и 10 конденсаторов между реакторными тиками, но это уже на грани возможного. Малейший лаг приведёт к сгоранию конденсатора. На реальном же сервере всё зависит от лага OC относительно тиков реактора. Кстати, если синхронизировать свои действия с тиками реактора, то в большинстве случаев можно успеть отключить редстоун, заменить несколько конденсаторов и снова включить редстоун так, что реактор даже не успеет заметить отключение и даже не снизит выработку энергии.

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

Каждый дополнительный уровень вложенности кода в pcall позволяет немного снизить шанс аварийного отключения компьютера. Для устремления этого шанса к нулю размер вложенности должен стремиться к бесконечности. Имеющиеся ограничения в OpenComputers позволили мне достичь лишь 195 вложений pcall, а на 196'ом я получил «stack overflow». Поэтому на сильно перегруженном сервере большинство лагодромов завершится синим экраном с надписью «too long without yielding». Максимальная же вложенность кода в pcall позволит лишь немного отсрочить неизбежное.

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

Сервер можно положить с помощью как CC, так и OC. CC немного облегчает задачу, но и OC тоже имеет достаточный потенциал. Для этого не нужны даже 8 человек, достаточно и одного игрока, если тот поставит перед собой такую задачу. И проблема не столько в количестве самих компов, сколько в количестве и качестве лагодромав, запущенных на компах.

Про лагомерки и лагодромы ответил здесь

Затравочный пост о лагомерках и лагодромах Выполняя обещание, данное в других темах, привожу список известных мне лагомерок без их подробного анализа: 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 почти всегда не успевает. В этом посте я не раскрыл всех деталей использования перечисленных способов обнаружения лагов. Также, возможно, я забыл упомянуть другие достойные способы или даже не знал их. Поэтому задавайте вопросы, предлагайте свои решения, проводите собственные исследования, не дожидаясь моих. По результатам обсуждения я попробую собрать подробный гайд о лагомерках и лагодромах.

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

Измерение TPS сервера, ориентируясь на время из интернета является, пожалуй, одним из худших вариантов. Пакеты через интернет доходят с очень труднопрогнозируемым лагом. Реализация подобия NTP это отдельная задача. Для измерения небольших интервалов времени более предпочтительным выглядит получение времени через модификацию файла. Время же из интернета обычно требуется для оценки запаздывания или опережения времени на сервере, что для нашей задачи совершенно некритично. Но и оценка TPS относительно времени модификации файла тоже имеет свои ограничения. Я, пожалуй, напишу отдельный пост обо всех найденных мной лагомерках. У каждой есть свои достоинства и недостатки.

Не всегда. Даже если сразу после pcall выполнить computer.pullSignal, есть шанс, что уступка времени не успеет произойти до аварийного останова компьютера. Хоть десятикратным слоем pcall можно обернуть, это не всегда помогает. Да, в конечном итоге так и делаю. Либо таймер, либо дополнительный контроллер, выполняющий функцию таймера. Но в конечном итоге и дополнительный таймер и контроллер вносят свой вклад в снижение TPS, об этом тоже следует помнить. Кроме того, задержка между выключением и пробуждением управляющего компьютера должна быть минимальной, т.к. хороший микроконтроль должен обеспечивать манипуляции с реактором в точно отведённые для этого интервалы времени. Поэтому использование дополнительного микроконтроллера мне кажется более компактным и гибким способом. За это время, пока я не был активен в этой теме, я нашёл более простой способ оценки лагов даже на выключенном сервере: измерять время, затраченное на чтение состояния реактора или его слотов. В норме на это требуется один тик, при микролагах изредка требуется два тика. А при огромных лагах у меня уходило даже 36 тиков. Я упоминал об этом эксперименте в теме с заказом "Очень много электричества".

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

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

Это, наверное, зависит от комбинаций модов и настроек. Я сейчас проверил ограничение выхода энергии. Схему выкладывал не самую лучшую и реактор грел не до максимума. Получил выход энергии 4200 eu/t на уране и 20237 на MOX. MFSU за секунду работы набрал 404753 eu, что полностью соответствует выходу 20237 eu/t. Получается, что ограничение в 8192 eu/t проявляет себя не всегда.

Даже в самых смелых фантазиях я не планировал осуществлять микроконтоль этой схемы роботом. В отличие от транспозера робот в большинстве случаев просто не успеет обменять компоненты в интервале между реакторными тиками. Реактор от этого не взорвётся, но немного снизит среднюю производительность. Кроме того, я бы не стал поручать роботу какие-то дополнительные задачи кроме обслуживания реактора. Схемы, требующие микроконтроля, обязывают постоянно держать руку на пульсе. Как минимум, требуется отслеживать лаги сервера и не отключаться по TLWY. Для увеличения производительности я рекомендую рассмотреть метастабильные схемы на MOX. Им требуется микроконтроль лишь на этапе разогрева и во время замены отработанных стержней. Реакторы с такими схемами можно смело оставлять без присмотра. Содержащиеся в них компоненты не перегорают, а сами реакторы не взрываются.

Сложность задачи напрямую зависит от используемой схемы и режимов работы реактора. А требования использовать экстремальные варианты в этой теме не было. Обычный реактор на уране с генерацией 420 eu/t не взрывается из-за лагов, и какого-то сложного управления не требует.

Не совсем. Так файл не закроется. Вот API для компонента Filesystem. Можно закрывать, например, таким кодом: fs.close(fs.open("/time", "w"))

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

В программе присутствует ошибка. Из-за неё 96% попыток обновлений времени являются холостыми, и поэтому фактические обновления происходят со средней частотой примерно 4 раза в секунду. При этом интервалы обновления неравномерны, они заданы случайными факторами. Если не закрывать открытый файл, то последующие попытки его открытия будут безуспешными до тех пор, пока файл не будет закрыт сборщиком мусора. Закрытие файла + задержка между обновлениями в 1/4 секунды дадут гораздо более приятный глазу эффект. И нагрузка на сервер снизится раз в 30.

Да, подтвердилась гипотеза о лагах при получении ответа от периферии. Я провёл эксперимент, имитируя сильные и продолжительные лаги. Оказалось, что вызов transposer.getStackInSlot() может иногда длиться до 36 тиков. И это, я думаю, не предел. Реактор за время между двумя последовательными чтениями состояния одного слота иногда успевал отработать три своих такта. Выводы: Алгоритм микроконтроля должен быть по возможности экономным. Любое лишнее действие сужает пространство до манёвра. Иногда будет отсутствовать не только возможность успеть выключить реактор, но и даже зарегистрировать момент перед взрывом. Даже самый лучший алгоритм микроконтроля может не спасти реактор во время сильных лагов. Риск можно минимизировать, отключая реактор при обнаружении лагов, но шанс не успеть всё равно сохранится. Впрочем, не всё так плохо. Если принять все необходимые меры, то шансы на взрыв не велики. А риск может быть оправдан возможностью обойти ограничение на количество реакторов в привате. Для отдельного реактора риск можно было бы снизить, чуть чаще заменяя конденсаторы, например, не за секунду, а за несколько секунд до критического износа, но это палка о двух концах: чем чаще выполняются какие-либо манипуляции со стороны OpenComputers, тем сильнее будут лаги в других компах. Поэтому по возможности следует стремиться не повышать, а снижать частоту любых действий.

Стандартная частота обновления объектов в Майнкрафте составляет 20 тиков в секунду. А про бюджеты вызовов недавно писал @Fingercomp в своём блоге: Прямые и кривые методы компонентов.

Какие именно механики?

Без задержки эти часы будут пытаться обновить показания с частотой около 120 раз в секунду. А сервер сможет обновить картинку на мониторе с частотой не более 20 раз в секунду. Значит, добавив задержку всего в один тик, можно без заметного ухудшения снизить нагрузку на сервер в 6 раз. Да и 20 раз в секунду нет особого смысла обновлять часы. Уже при частоте около 4 раз в секунду обновление перестаёт играть заметную роль.

@Taruu А почему эти часы не уходят с сон хотя бы на тик? Чем оправдана такая нагрузка на сервер?