Chebuya 415 Опубликовано: 20 ноября, 2019 8 часов назад, NEO сказал: Конечно неинтересен. Майн выдохся что ясно всем, чего в реакторе нового можно найти спустя кучу лет после выхода мода? 3 минуты назад, NEO сказал: Предлагаю написать продвинутый симулятор реактора. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
NEO 541 Опубликовано: 20 ноября, 2019 1 минуту назад, BrightYC сказал: Так я не буду писать, а вы. 2 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat Автор темы 2 148 Опубликовано: 20 ноября, 2019 7 минут назад, BrightYC сказал: Моё мнение - вырубать реактор при ТПС ниже допустимого. Нашёл старенький код, позволяющий определить кол-во тиков в секунду. Да, код немного кривоват, склонен к завышению TPS, имеет неконтролируемое дрожание, но идея понятна. Всё же это не мой путь на данном этапе. Сейчас я буду пытаться держать реакторы включенными до последнего и, по возможности, улучшать алгоритмы поддержания их живучести. А момент отключения я буду выбирать, скорее всего, измерением не TPS сервера, а запаса времени между действиями, необходимыми для управления реактором. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Chebuya 415 Опубликовано: 20 ноября, 2019 1 минуту назад, eu_tomat сказал: Да, код немного кривоват, склонен к завышению TPS, имеет неконтролируемое дрожание Давно его делал, что поделать. 1 минуту назад, eu_tomat сказал: Всё же это не мой путь на данном этапе. Сейчас я буду пытаться держать реакторы включенными до последнего и, по возможности, улучшать алгоритмы поддержания их живучести. А момент отключения я буду выбирать, скорее всего, измерением не TPS сервера, а запаса времени между действиями, необходимыми для управления реактором. Ну тут увы дороги расходятся. Я бы не стал дожимать до последнего. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat Автор темы 2 148 Опубликовано: 20 ноября, 2019 20 минут назад, NEO сказал: Предлагаю написать продвинутый симулятор реактора. Мне кажется, это не поможет. Все обсуждённые здесь экстремальные схемы можно подтвердить или опровергнуть расчётами, без симуляции. Главная проблема этих схем в другом. Тут на первое место выходит время обработки операций компьютером даже с хорошим TPS. При снижении TPS возникает заметная рассинхронизация реакторов и компьютеров. Но для некоторых схем даже рассинхронизация не критична. Тут нужен симулятор не реактора, а всего Майнарафта с модами. 18 минут назад, NEO сказал: Так я не буду писать, а вы. По крайней мере, не для текущей задачи. А так да, почему бы и нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
whiskas 144 Опубликовано: 20 ноября, 2019 (изменено) На грег тече крутые реакторы, там новые виды стержней которые больше дают больше греются и тд, новые компоненты которые больше остужают но жрут енергию. Можна творить чудеса Изменено 20 ноября, 2019 пользователем whiskas Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Doob 2 748 Опубликовано: 21 ноября, 2019 Не понял, в чем проблема, плавятся только блоки индастриала и ванильные. Можно инверторы и репитеры из других модов поставить и все прекрасно контролируется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat Автор темы 2 148 Опубликовано: 21 ноября, 2019 Я намеренно избегаю применения других модов в этой теме, чтобы не уходить в нюансы их использования. Почти всегда есть мод, который решает ту или иную задачу лучше другого, и, погружаясь в модоведенье мы рискуем надолго застрять в нём. Если существует решение задачи, позволяющее обойтись без дополнительных модов, то я предпочиту исследовать именно его. Моды же позволят улучшить это решение в зависимости от предпочтений игрока или администратора сервера. 7 часов назад, whiskas сказал: На грег тече крутые реакторы, там новые виды стержней которые больше дают больше греются и тд, новые компоненты которые больше остужают но жрут енергию. Можна творить чудеса Насколько я помню, в GT наиболее существенным нововведением для реакторов IC2 является охлаждение охлаждающих капсул в холодильнике. А новые стержни просто имеют другие соотношения выработки энергии и тепла при сохранении общей механики. Поэтому микроконтроль сохранит свою актуальность и для GT тоже, позволяя творить новые чудеса на новом поле чудес. 2 часа назад, Doob сказал: Не понял, в чем проблема, плавятся только блоки индастриала и ванильные. Можно инверторы и репитеры из других модов поставить и все прекрасно контролируется. Нет проблемы, но есть задача. Существуют решения и без модов, просто их поиск более сложен. Этим я и занимаюсь в этой теме. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Alex 4 683 Опубликовано: 21 ноября, 2019 В 20.11.2019 в 11:55, NEO сказал: Конечно неинтересен. Майн выдохся что ясно всем, чего в реакторе нового можно найти спустя кучу лет после выхода мода? всё так, но не совсем так. Взгляни на это под другим углом. К примеру, для тебя и меня засушенная муха на подоконнике, это просто муха, а для какого-то энтомолога это целый кладезь знаний и потенциальный объект пристального изучения под микроскопом. Ему интересно возиться с этой мухой. Он видит в ней неисчерпаемый источник знаний и огромный интерес. А также не забывай про новых игроков 2010+ года рождения. Это, например, тебе или мне майновский индастриал реактор надоел давным давно, а эти игроки потенциально только открывают мир майнкрафта и индастриала, и для них там всё в диковинку Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat Автор темы 2 148 Опубликовано: 21 ноября, 2019 В 20.11.2019 в 21:23, BrightYC сказал: Моё мнение - вырубать реактор при ТПС ниже допустимого. Я сейчас прогулялся по морозцу и свежим мозжечком вот что надумал. Ты прав. Пытаться во что бы то ни стало включить комп, управляющий реактором, сейчас является плохой идеей. Идя по этому пути, готовые схемы микроконтроля реакторов я ещё долго не выложу. Как я вижу схему аварийного включения сейчас: Есть компьютер или микроконтроллер, управляющий реактором. Он выполняет свою основную задачу, заодно анализируя её выполнимость в текущих условиях. Это несложно. Если расчёты указывают на невозможность решения, комп пытается более-менее управляемо остановить процесс (в зависимости от использованной схемы) и переходит в режим лагомерки. Когда ситуация нормализуется, программа возобновит управление реактором. Если, конечно, не выключится сам комп. Рядом с основным компьютером стоит микроконтроллер, который в режиме ожидания отслеживает статус соседа. Если тот погас, то микроконтроллер включает лагомерку, а когда лаги стихнут, с некоторой периодичностью пытается разбудить комп. Этот микроконтроллер наибольшую часть работы будет тратить на сон. Но если и он погаснет, то лишь во время чего-то действительно страшного и опасного. Тут главное, чтобы сами лагомерки создавали минимальную нагрузку на сервер. Как вам идея в качестве лагомерки использовать замеры computer.uptime() при циклическом выполнении этого кода? for i=1,3 do computer.pullSignal(0) end computer.pullSignal(0.01) t = computer.uptime() Такой код по идее должен жрать очень мало ресурсов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Chebuya 415 Опубликовано: 22 ноября, 2019 52 минуты назад, eu_tomat сказал: Как вам идея в качестве лагомерки использовать замеры computer.uptime() при циклическом выполнении этого кода? for i=1,3 do computer.pullSignal(0) end computer.pullSignal(0.01) t = computer.uptime() Такой код по идее должен жрать очень мало ресурсов. Проблема в том, что os.time, что computer.uptime возвращает майновское время. Во время низкого тпс'а тикать начнёт медленнее - соответственно computer.uptime при стабильных 20 тиках в секунду и 10-15 тпс будет одинаков. Нужно сравнивать реальное время, только так можно определить тпс. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Chebuya 415 Опубликовано: 22 ноября, 2019 4 часа назад, eu_tomat сказал: Такой код по идее должен жрать очень мало ресурсов. Мне непонятно зачем гнаться за "должен жрать очень мало ресурсов". Ибо дефолтная сейчас заставка MineOS лагодромит в разы больше, чем если какой-то микроконтроллер будет дёргать фс раз в полторы секунды. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Doob 2 748 Опубликовано: 22 ноября, 2019 Зачем измерять тпс майна, если можно спокойно наблюдать прохождение тиков в самом реакторе? К тому же, при лаге, реактор не будет сваливать тики в кучу. Он их может пропускать, но в такой ситуации, сервер уже лежит и не шевелится. Искусственное изменение тпс другими модами и плагинами легко отследить - изменение тиков реактора на >10% Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat Автор темы 2 148 Опубликовано: 22 ноября, 2019 1 час назад, Doob сказал: Зачем измерять тпс майна, если можно спокойно наблюдать прохождение тиков в самом реакторе? Да, при штатной работе программы достаточно соотнести тики реактора с тиками, которые смог обработать компьютер. TPS как таковой вообще не обязательно знать. Но когда реактор остановлен, нужен инструмент косвенной оценки лагов сервера, без реактора. 2 часа назад, BrightYC сказал: Мне непонятно зачем гнаться за "должен жрать очень мало ресурсов". Чем меньше ресурсов потребляет комп, чем чаще он находится в простое, тем ниже вероятность, что он отключится по TLWY. Правда, на практике может оказаться, что наш код выполнил уступку времени на несколько тиков, передав управление методу компонента, и поэтому формально наш компьютер простаивает. При этом сам майн, обрабатывая вызванный кодом метод, может лагать. Это предстоит выяснить экспериментально. Но в целом это правило подтверждается: чем больше времени код тратит на вычисления и чем реже обращается к периферии, тем меньше его вклад в лаги, и тем меньше вероятность возникновения TLWY конкретно для этого компьютера. 2 часа назад, BrightYC сказал: Ибо дефолтная сейчас заставка MineOS лагодромит в разы больше, чем если какой-то микроконтроллер будет дёргать фс раз в полторы секунды. MineOS кроме прочих несёт ещё и эстетическую функцию в "мирное" время. И аварийное отключение компа с MineOS во время лагов меня не огорчит. Но лагомерки в наших watchdog'ах, должны погаснуть в последнюю очередь. 6 часов назад, BrightYC сказал: Проблема в том, что os.time, что computer.uptime возвращает майновское время. Во время низкого тпс'а тикать начнёт медленнее - соответственно computer.uptime при стабильных 20 тиках в секунду и 10-15 тпс будет одинаков. Нужно сравнивать реальное время, только так можно определить тпс. Это не проблема, если отказаться от измерения именно TPS. Более того, как верно заметил @Doob, тикрейт может быть штатно изменён модами. Да, метод computer.uptime всегда показывает тики, хотя и представляет их в виде секунд. Фокус же в том, что выполнение одного и того же кода может занимать разное количество тиков в зависимости от лагов сервера. И для лагомерки я предлагаю эксплуатировать именно эту особенность. 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
ProgramCrafter 544 Опубликовано: 28 июля, 2020 В 22.11.2019 в 12:23, eu_tomat сказал: Но когда реактор остановлен, нужен инструмент косвенной оценки лагов сервера, без реактора. Возможно, чтобы измерить лаги, стоит держать корпус реактора в нагретом состоянии, а в выключенный реактор класть теплоотвод? Тогда компьютер сможет проверить, в какой момент изменилась температура реактора и насколько низок TPS. Компьютер можно запитать от таймера. При лагах, даже если он выключится, то он будет автоматически включен по сигналу редстоуна и снова станет ждать, когда лаги кончатся. Но вообще с проблемой TLWY может справиться что-то вроде pcall. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
hohserg 189 Опубликовано: 28 июля, 2020 (изменено) TPS можно измерить просто сравнив задержку os.sleep(n) с изменением реального времени, взятого где-нить из инета 15 минут назад, ProgramCrafter сказал: Но вообще с проблемой TLWY может справиться что-то вроде pcall. А если TLWY вывалится снаружи pcall? Изменено 28 июля, 2020 пользователем hohserg Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat Автор темы 2 148 Опубликовано: 28 июля, 2020 5 минут назад, ProgramCrafter сказал: с проблемой TLWY может справиться что-то вроде pcall Не всегда. Даже если сразу после pcall выполнить computer.pullSignal, есть шанс, что уступка времени не успеет произойти до аварийного останова компьютера. Хоть десятикратным слоем pcall можно обернуть, это не всегда помогает. 9 минут назад, ProgramCrafter сказал: Компьютер можно запитать от таймера. Да, в конечном итоге так и делаю. Либо таймер, либо дополнительный контроллер, выполняющий функцию таймера. Но в конечном итоге и дополнительный таймер и контроллер вносят свой вклад в снижение TPS, об этом тоже следует помнить. Кроме того, задержка между выключением и пробуждением управляющего компьютера должна быть минимальной, т.к. хороший микроконтроль должен обеспечивать манипуляции с реактором в точно отведённые для этого интервалы времени. Поэтому использование дополнительного микроконтроллера мне кажется более компактным и гибким способом. 18 минут назад, ProgramCrafter сказал: Возможно, чтобы измерить лаги, стоит держать корпус реактора в нагретом состоянии, а в выключенный реактор класть теплоотвод? Тогда компьютер сможет проверить, в какой момент изменилась температура реактора и насколько низок TPS. За это время, пока я не был активен в этой теме, я нашёл более простой способ оценки лагов даже на выключенном сервере: измерять время, затраченное на чтение состояния реактора или его слотов. В норме на это требуется один тик, при микролагах изредка требуется два тика. А при огромных лагах у меня уходило даже 36 тиков. Я упоминал об этом эксперименте в теме с заказом "Очень много электричества". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat Автор темы 2 148 Опубликовано: 28 июля, 2020 4 часа назад, hohserg сказал: TPS можно измерить просто сравнив задержку os.sleep(n) с изменением реального времени, взятого где-нить из инета Измерение TPS сервера, ориентируясь на время из интернета является, пожалуй, одним из худших вариантов. Пакеты через интернет доходят с очень труднопрогнозируемым лагом. Реализация подобия NTP это отдельная задача. Для измерения небольших интервалов времени более предпочтительным выглядит получение времени через модификацию файла. Время же из интернета обычно требуется для оценки запаздывания или опережения времени на сервере, что для нашей задачи совершенно некритично. Но и оценка TPS относительно времени модификации файла тоже имеет свои ограничения. Я, пожалуй, напишу отдельный пост обо всех найденных мной лагомерках. У каждой есть свои достоинства и недостатки. 2 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
serafim 271 Опубликовано: 4 августа, 2020 Изваял тепловой насос на разогнанных теплоотводах, как доведу до более- менее рабочего решения выложу(или нет) Два реактора, нижний основной, верхний отстойник, с урана снял 1540 eu/t К сожалению транспозер перемещает теплоотводы почти без прерывно, так как они очень быстро изнашиваются Скрытый текст Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
eu_tomat Автор темы 2 148 Опубликовано: 4 августа, 2020 2 часа назад, serafim сказал: Изваял тепловой насос на разогнанных теплоотводах, как доведу до более- менее рабочего решения выложу(или нет) Скорее, нет, чем да. Прежде чем писать код, предлагаю обосновать эту схему с математической точки зрения. Если я верно понял задумку, схема неоптимальна или даже бессмысленна. Но это при условии, что я смог её понять. Чтобы найти общий язык, для начала предлагаю ответить на следующие вопросы: Какова схема размещения компонентов во втором реакторе? Какой цели достигает использованное решение? В чём заключается его основное преимущество? Каков общий тепловой баланс обоих реакторов? Как решается проблема перегрева компонентов? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах