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

Микроконтроль ядерных реакторов IC2exp

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

8 часов назад, NEO сказал:

Конечно неинтересен. Майн выдохся что ясно всем, чего в реакторе нового можно найти спустя кучу лет после выхода мода?

 

3 минуты назад, NEO сказал:

Предлагаю написать продвинутый симулятор реактора.

:D

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


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

 

:D

Так я не буду писать, а вы.

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


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

Моё мнение - вырубать реактор при ТПС ниже допустимого. Нашёл старенький код, позволяющий определить кол-во тиков в секунду.  

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

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


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

Да, код немного кривоват, склонен к завышению TPS, имеет неконтролируемое дрожание

Давно его делал, что поделать. 

1 минуту назад, eu_tomat сказал:

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

Ну тут увы дороги расходятся. Я бы не стал дожимать до последнего. 

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


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

Предлагаю написать продвинутый симулятор реактора.

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

 

Тут нужен симулятор не реактора, а всего Майнарафта с модами.

18 минут назад, NEO сказал:

Так я не буду писать, а вы.

По крайней мере, не для текущей задачи. А так да, почему бы и нет.

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


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

На грег тече крутые реакторы, там новые виды стержней которые больше дают больше греются и тд, новые компоненты которые больше остужают но жрут енергию. Можна творить чудеса

Изменено пользователем whiskas

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


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

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

Можно инверторы и репитеры из других модов поставить и все прекрасно контролируется.

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


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

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

 

7 часов назад, whiskas сказал:

На грег тече крутые реакторы, там новые виды стержней которые больше дают больше греются и тд, новые компоненты которые больше остужают но жрут енергию. Можна творить чудеса

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

 

2 часа назад, Doob сказал:

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

Можно инверторы и репитеры из других модов поставить и все прекрасно контролируется.

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

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


Ссылка на сообщение
Поделиться на других сайтах
В 20.11.2019 в 11:55, NEO сказал:

Конечно неинтересен. Майн выдохся что ясно всем, чего в реакторе нового можно найти спустя кучу лет после выхода мода?

всё так, но не совсем так. Взгляни на это под другим углом. К примеру, для тебя и меня засушенная муха на подоконнике, это просто муха, а для какого-то энтомолога это целый кладезь знаний и потенциальный объект пристального изучения под микроскопом. Ему интересно возиться с этой мухой. Он видит в ней неисчерпаемый источник знаний и огромный интерес.

А также не забывай про новых игроков 2010+ года рождения. Это, например, тебе или мне майновский индастриал реактор надоел давным давно, а эти игроки потенциально только открывают мир майнкрафта и индастриала, и для них там всё в диковинку:) 

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


Ссылка на сообщение
Поделиться на других сайтах
В 20.11.2019 в 21:23, BrightYC сказал:

Моё мнение - вырубать реактор при ТПС ниже допустимого.

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

 

Как я вижу схему аварийного включения сейчас:

  • Есть компьютер или микроконтроллер, управляющий реактором. Он выполняет свою основную задачу, заодно анализируя её выполнимость в текущих условиях. Это несложно. Если расчёты указывают на невозможность решения, комп пытается более-менее управляемо остановить процесс (в зависимости от использованной схемы) и переходит в режим лагомерки. Когда ситуация нормализуется, программа возобновит управление реактором. Если, конечно, не выключится сам комп.
  • Рядом с основным компьютером стоит микроконтроллер, который в режиме ожидания отслеживает статус соседа. Если тот погас, то микроконтроллер включает лагомерку, а когда лаги стихнут, с некоторой периодичностью пытается разбудить комп. Этот микроконтроллер наибольшую часть работы будет тратить на сон. Но если и он погаснет, то лишь во время чего-то действительно страшного и опасного.

Тут главное, чтобы сами лагомерки создавали минимальную нагрузку на сервер.

 

Как вам идея в качестве лагомерки использовать замеры computer.uptime() при циклическом выполнении этого кода?

for i=1,3 do
  computer.pullSignal(0)
end
computer.pullSignal(0.01)
t = computer.uptime()

Такой код по идее должен жрать очень мало ресурсов.

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


Ссылка на сообщение
Поделиться на других сайтах
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 тпс будет одинаков. Нужно сравнивать реальное время, только так можно определить тпс. 

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


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

Такой код по идее должен жрать очень мало ресурсов.

Мне непонятно зачем гнаться за "должен жрать очень мало ресурсов".  Ибо дефолтная сейчас заставка MineOS лагодромит в разы больше, чем если какой-то микроконтроллер будет дёргать фс раз в полторы секунды.

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


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

Зачем измерять тпс майна, если можно спокойно наблюдать прохождение тиков в самом реакторе?

К тому же, при лаге, реактор не будет сваливать тики в кучу. Он их может пропускать, но в такой ситуации, сервер уже лежит и не шевелится.

Искусственное изменение тпс другими модами и плагинами легко отследить - изменение тиков реактора на >10%

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


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

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


Ссылка на сообщение
Поделиться на других сайтах
В 22.11.2019 в 12:23, eu_tomat сказал:

Но когда реактор остановлен, нужен инструмент косвенной оценки лагов сервера, без реактора.

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

 

Компьютер можно запитать от таймера. При лагах, даже если он выключится, то он будет автоматически включен по сигналу редстоуна и снова станет ждать, когда лаги кончатся. Но вообще с проблемой TLWY может справиться что-то вроде pcall.

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


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

TPS можно измерить просто сравнив задержку os.sleep(n) с изменением реального времени, взятого где-нить из инета

 

  

15 минут назад, ProgramCrafter сказал:

Но вообще с проблемой TLWY может справиться что-то вроде pcall.

А если TLWY вывалится снаружи pcall?

Изменено пользователем hohserg

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


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

с проблемой TLWY может справиться что-то вроде pcall

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

 

9 минут назад, ProgramCrafter сказал:

Компьютер можно запитать от таймера.

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

 

18 минут назад, ProgramCrafter сказал:

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

За это время, пока я не был активен в этой теме, я нашёл более простой способ оценки лагов даже на выключенном сервере: измерять время, затраченное на чтение состояния реактора или его слотов. В норме на это требуется один тик, при микролагах изредка требуется два тика. А при огромных лагах у меня уходило даже 36 тиков. Я упоминал об этом эксперименте в теме с заказом "Очень много электричества".

 

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


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

TPS можно измерить просто сравнив задержку os.sleep(n) с изменением реального времени, взятого где-нить из инета

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

 

Но и оценка TPS относительно времени модификации файла тоже имеет свои ограничения. Я, пожалуй, напишу отдельный пост обо всех найденных мной лагомерках. У каждой есть свои достоинства и недостатки.

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


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

Изваял тепловой насос на разогнанных теплоотводах, как доведу до более- менее рабочего решения выложу(или нет)

Два реактора, нижний основной, верхний отстойник, с урана снял 1540 eu/t

К сожалению транспозер перемещает теплоотводы почти без прерывно, так как они очень быстро изнашиваются

Скрытый текст

9OFb2g7.png

eyHsAmb.png

 

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


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

Изваял тепловой насос на разогнанных теплоотводах, как доведу до более- менее рабочего решения выложу(или нет)

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

  • Какова схема размещения компонентов во втором реакторе?
  • Какой цели достигает использованное решение? В чём заключается его основное преимущество?
  • Каков общий тепловой баланс обоих реакторов?
  • Как решается проблема перегрева компонентов?

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


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

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

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

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

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

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

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

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

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


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