Насколько я слышал, они пытались. Но либо дорого (в промышленном масштабе), либо токсично, либо не сильно помогло. Гликоль стандартная опция в индустрии, но он используется в смеси с водой.
Если хочется сохранять аудиторию в течение 10 лет нужно позволять задавать одни и те-же вопросы снова и снова. Люди стареют. Старые пользователи уходят. Новички приходят, и если им не позволять задавать вопросы, пусть даже и глупые, они не вовлекаются. Т.е. старое коммунити умирает, а новичков, которые должны бы составить новое коммунити, просто отпугнули.
Водоблоки делать пытались (кто из FB/Google/Amazon/MSFT я не помню). Но увы! Во первых, дорого в производстве. Во вторых, ненадежно. Шансы, что хоть один из 192 процессоров в стойке потечет, не так уж и малы. А вылетает при этом вся стойка. В третьих, монтаж всей это сантехники на месте - отдельная радость для всех. В четвертых, принцип сантехника: все течет, ничего не меняется. Как результат отказались.
Повышение эффективности теплообмена тепловым насосом - так и делают. Это практически золотой стандарт пром установок. Иначе 1 МВт тепла просто не сдуть. Про игры с влажностью, туманом и фазовым переходом - ФБ так делает/делал в одном из поколений своих ДЦ. Но однажды при скачке температуры/влажности "за бортом" в ДЦ пошел дождь. Система не успела за изменением отн влажности приточного воздуха, и конденсация влаги началась прямо в помещении с серверами. Было забавно! Но при цене электричества в Калифорнии до 0.40 USD/kWh и не такие эксперименты выходят экономически оправданными.
Так, давайте поясним условия, для начала. Что такое датацентр - это площадка вынесенная за пределы города из-за требований по шуму и выхлопам. Обычно земли вокруг много на случай расширения. Расширение - это строительство новых Colo (отдельные одноэтажные здания). Строится в регионах с дешевой электроэнергией и низкими налогами. Часто это депрессивный регион, либо какие-то выселки где местная власть может дать налоговую льготу в обмен на создание рабочих мест. Обычно там нет в округе других больших производств. У датацентра есть требования по безопасности! Там обычно два периметра: внешний по територии, и внутренний на физический доступ в здание. Т.е. никакой движ с постоянным движением автотранспорта по територии недопустим.
Что-бы снимать тепло с теплого воздуха нужна большая площадь теплообмена и большой массовый расход воздуха. Это из-за того что теплоемкость воздуха невелика и разница температур тоже. Т.е. для ГВС придется строить гигантский теплообменник воздух-вода. Именно стоимость больших теплообменников является ограничивающим фактором.
Сбросить это тепло в атмосферу можно, оно сейчас так и происходит. Наиболее выгодные по цене варианты (все используются):
Потратить еще немного энергии на увеличение разницы температур тепловым насосом. Большая разница температур позволяет уменьшить размер радиатора. Тепло с радиатора сдуть в атмосферу вентилятором. Это размен дополнительных затрат энергии на меньший размер радиатора.
Активно продувать внешний воздух через помещение (проблемы с пылью и фильтрами).
Поднять влажность и сместить точку росы так, чтобы фазовый переход происходил в рабочем цикле охлаждения. А потом у ФБ в датацентре дождь идет :) Но расход воздуха снижается существенно.
Засунуть датацентр под воду. См. проект Майкрософта с подводным вычислительным контейнером. Работает хорошо, но дорого.
Строить поближе к полярному кругу. Из районов с достаточным энергообеспечением пока только Норвегия. Там много гидро генерации и в среднем не жарко. НО latency никого не радует если обслуживаешь не Европу.
Но дело в том, что во всех случаях тепло просто выкидывается, да еще и деньги на это тратятся. А хотелось бы тепло использовать, и на этом заработать. Вариант с прямым отоплением домов не работает, т.к. датацентры специально строятся подальше от жилья и офисов. С ними рядом очень некомфортно находиться из-за шума, выхлопа аварийных дизелей. Был вариант этим теплым воздухом теплицы греть. А их прям рядом с ДЦ ставить. Но экономика не срастается (если не коноплю выращивать). Да и с безопасностью вопросы. Греть воду горячим воздухом не получается из-за потребных размеров теплообменников (очень большие). Ставить гидроблоки на каждый ЦПУ и получать горячую воду напрямую - постоянные протечки и разводка трубок по датацентру выходит слишком дорого.
Адсорбционные холодильники точно можно использовать при таких температурах.
Конечно потребление энергии датацентрами растет, но эта энергия не потреблятся в одном месте. Локально стоит ориентироваться на 10000 серверов = типичное colo. Средний сервер 200 Вт. Коеффициент загрузки по мощности - порядка 50%. Т.е. потребление одного здания порядка 1 МВт в среднем.
Проблема в другом! Холодильник - тепловая машина которая потребляет энергию и прокачивает энергию от "холодного конца" к "горячему концу". Т.е. вся тепловая мощность (потребляемая + прокачиваемая) должна сбрасываться с горячего теплообменника. Сбрасывать 1 МВт имея температуру теплообменника в 50 градусов очень сложно. Теплообменник нужен гигантский и дорогой. Получается очень невыгодно. В жизни оно работает только если это тепло сбрасывается в воду. Тогда теплообменник имеет разумные размеры. Такие системы работают на сейнерах. Тепло от дизеля прокачивается через адсобционный холодильник в забортную воду. Холодильник морозит рыбу. Тоесть если речка рядом есть, то можно попробовать. Но экологи сильно не любят ТАКОЙ сброс тепла в местные водоемы. Могут и оштрафовать!
Низкопотенциальное - означает маленькую разницу температур теплоносителя на входе и на выходе. Например, датацентр производит много воздуха нагретого до 45-50 градусов. Или воды нагретой до 40. Забирать теплоноситель из водяного контура крайне нежелательно. Много денег порачено на водоподготовку, да и токсичный он. А использовать теплоноситель такой низкой температуры сложно, транспортировать такое тепло дорого.
О результатах конкурса почитать уже нигде. Это внутренний конкурс и в интернет эти данные никогда не попадали. Да и внутри корпорации эти документы скорее всего уже канули в лету, 14 лет прошло как никак.
С датацентра тепло идет низкопотенциальное (т.е. невысокой температуры). В 2011 Майкрософт проводил внутренний конкурс проектов куда это тепло можно пристроить. Никто не победил. Но идея про подвалы в принципе годная. т.к. транспортировать такое тепло далеко не надо.
Не нужно греть дом старыми телевизорами! У меня домашний десктоп неспроста имеет БП 1000 Вт мощности. Да и сервер числомолотилка легко скушает 1 кВт, а потом отдаст вам его в качестве отопления. При этом он еще и радостно будет рендерить видео, или распознавать объекты на снимках.
Можно перестать постоянно выключать свет и вообще экономить на освещении. Для большого дома это сотни ватт постоянно.
Нет конечно! Просто добавьте в список другие средства разработки. Например Visual Studio 2018, PyCharm. И сразу будет заметно, что можно сделать сильно эффективнее без сжирания всей доступной памяти в одно перекормленное лицо.
"Приличное моделирование" должно воспроизводить "неоднородности нейтронного поля на малой мощности" и "неустойчивость реактора в режимах малой мощности и активной работы стежнями СУЗ". Это критерий "приличности" с моей точки зрения. Какова потребная сложность модели? Видимо с точностью по ТВЭЛа, либо с точностью до кассеты (как минимум). По высоте активную зону придется разбивать на ячейки размером сравнимым с размер графитового наконечника срежня регулирования (точно не менее 100 ячеек по высоте). Т.е. активную зону моделировать как 1693 * 100 = 169300 независимых тепловыделяющих сборки (с точностью до кассеты). Либо как 1693 * 18 * 100 = 3047400 независимых тепловыделяющих элемента (с точностью до ТВЭЛа). Плюс каналы (и паросодержание в каждом), плюс положение каждого стержня регулирования. Итого расход памяти на такую модель от миллиона до первых десятков миллионов числовых параметров.
Теперь смотрим на упоминаемую машину М-200 как типичного представителя ЦВМ того времени:
ОЗУ от 4 до 16 тысяч 47-битных слов,
Накопители на магнитном барабане объёмом от 24 до 65 тысяч слов.
Накопитель на магнитной ленте (4 блока) ёмкостью от 4 до 16 миллионов слов
производительность — до 27000 оп/сек И видим, что как сову не натягивай, а нехватка по памяти полтора порядка даже при использовании магнитных барабанов. По производительности тоже все очень плохо. Расчет будет идти со скоростью несколько минут (десятков минут) на один шаг по времени. Т.е. на просчет одного режима уйдут недели и месяцы машинного времени в режиме монопольного использования ЦВМ. А режимов десятки.
Вот я и говорю, что "теми средствами" реалистичную модель было непотянуть. В 80-е что-то моделировать стало возможно. Но к тому времени проект был успешно сдан и снова тратить месяцы и годы на моделирование никто бы не дал.
Очевидно, что сложность модели сильно (О(h^3)) зависит от физических размеров активной зоны. Из-за этого ВВЭРы моделировать проще, а результат выходит точнее.
Печаль - тоска в том, что забывают/игнорируют сценарии реально тяжелого использования. А на них вся эта Electron'ная чухня дохнет, сожрав предварительно всю память. Если у тебя проект на несколько MLOC и ты открываешь по паре сотен файлов одновременно, сколько инстансов IDE ты можешь запустить одновременно? А ведь надо иногда! В том же Хроме 2 меня тоже больше сотни вкладок открыто одновременно. Так для удобства приходится 5 инстансов Хрома запускать. И что? Он же сссамка собаки течет и падает. А ведь когда-то это было нормальным сценарием и все работало! Вкладки в браузере в 3-4 ряда и нормально. Что-то недочитал, недоделал можно было вкладку оставить открытой и не бояться что браузер рухнет и потеряет контекст. Про падения VS вообще никто не думал что так бывает. А сейчас приложений на JS наклепали, да только они работают по сценарию "строго 1 инстанс, не более 5 файлов разом, раз в день рестартуем ибо течет сильно". Как будто при профессиональном использовании кроме этого приложения человек ничем не пользуется и больше на машине ничего не запускает!
Все электричество которое вы потребляете в доме в конечном итоге превращается в тепло. Поэтому гонять электрообогреватель идея изначально дурная. Нужно гонять оборудование, которое попутно производит что-то еще полезное. Компы которые майнят крипту, обучают нейросетки, обрабатывают видео, хостят что угодно. Телевизоры, освещение - да что угодно, только не тупые электрообогреватели. В содержании датацентров самое дорогое это не железо, а оплата счетов за электричество. Тут можно иметь и отопление, и национальную сеть по хостингу видео/распознанию образов/расчету фолдинга белков. И все это примерно за одни и те-же деньги.
Ну тут вот товарищ выше пишет, что теперь падает. Либо за последние 4 года начала, либо у него какой-то "особенный" плагин добавлен. Плагины и раньше могли Студию уронить, или всю память сожрать.
Так она раньше не падала. Я даже больше скажу. Она и месяцами работала стабильно, я на ночь ее и не закрывал. Раз в месяц приходили патчи и машина перезагружалась. А остальное время VS перезапускать и не приходилось. А еще у меня в ней по 200 файлов было открыто. И иногда я мог несколько экземпляров VS открыть для разных проектов. И все это прекрасно работало.
Да в том то и дело, что было не "планомерное снижение мощности", а была "игра мощностью вверх-вниз и долгая работа на половинной мощности". Это и загнало реактор в нестабильный режим ксенонового отравления. В этому добавилось желание провести эксперимент "во что бы ни стало", и регулирование без хорошего понимания процессов в реакторе. В конструкции реактора были недостатки как в системе регулирования - "положительная обратная связь" ака "положительная реактивность", так и в системе контроля - "параметры критически важные для работы на малой мощности на пульте не отображались".
Но это обычная история, что любая катастрофа это всегда сочетание многих факторов. И не будь любого, аварии бы не было.
Насколько я слышал, они пытались. Но либо дорого (в промышленном масштабе), либо токсично, либо не сильно помогло.
Гликоль стандартная опция в индустрии, но он используется в смеси с водой.
Если хочется сохранять аудиторию в течение 10 лет нужно позволять задавать одни и те-же вопросы снова и снова. Люди стареют. Старые пользователи уходят. Новички приходят, и если им не позволять задавать вопросы, пусть даже и глупые, они не вовлекаются. Т.е. старое коммунити умирает, а новичков, которые должны бы составить новое коммунити, просто отпугнули.
В России свои особенности, и тут я не в курсе.
Водоблоки делать пытались (кто из FB/Google/Amazon/MSFT я не помню). Но увы! Во первых, дорого в производстве. Во вторых, ненадежно. Шансы, что хоть один из 192 процессоров в стойке потечет, не так уж и малы. А вылетает при этом вся стойка. В третьих, монтаж всей это сантехники на месте - отдельная радость для всех. В четвертых, принцип сантехника: все течет, ничего не меняется. Как результат отказались.
Повышение эффективности теплообмена тепловым насосом - так и делают. Это практически золотой стандарт пром установок. Иначе 1 МВт тепла просто не сдуть. Про игры с влажностью, туманом и фазовым переходом - ФБ так делает/делал в одном из поколений своих ДЦ. Но однажды при скачке температуры/влажности "за бортом" в ДЦ пошел дождь. Система не успела за изменением отн влажности приточного воздуха, и конденсация влаги началась прямо в помещении с серверами. Было забавно! Но при цене электричества в Калифорнии до 0.40 USD/kWh и не такие эксперименты выходят экономически оправданными.
Так, давайте поясним условия, для начала. Что такое датацентр - это площадка вынесенная за пределы города из-за требований по шуму и выхлопам. Обычно земли вокруг много на случай расширения. Расширение - это строительство новых Colo (отдельные одноэтажные здания). Строится в регионах с дешевой электроэнергией и низкими налогами. Часто это депрессивный регион, либо какие-то выселки где местная власть может дать налоговую льготу в обмен на создание рабочих мест. Обычно там нет в округе других больших производств.
У датацентра есть требования по безопасности! Там обычно два периметра: внешний по територии, и внутренний на физический доступ в здание. Т.е. никакой движ с постоянным движением автотранспорта по територии недопустим.
Что-бы снимать тепло с теплого воздуха нужна большая площадь теплообмена и большой массовый расход воздуха. Это из-за того что теплоемкость воздуха невелика и разница температур тоже. Т.е. для ГВС придется строить гигантский теплообменник воздух-вода. Именно стоимость больших теплообменников является ограничивающим фактором.
Сбросить это тепло в атмосферу можно, оно сейчас так и происходит. Наиболее выгодные по цене варианты (все используются):
Потратить еще немного энергии на увеличение разницы температур тепловым насосом. Большая разница температур позволяет уменьшить размер радиатора. Тепло с радиатора сдуть в атмосферу вентилятором. Это размен дополнительных затрат энергии на меньший размер радиатора.
Активно продувать внешний воздух через помещение (проблемы с пылью и фильтрами).
Поднять влажность и сместить точку росы так, чтобы фазовый переход происходил в рабочем цикле охлаждения. А потом у ФБ в датацентре дождь идет :) Но расход воздуха снижается существенно.
Засунуть датацентр под воду. См. проект Майкрософта с подводным вычислительным контейнером. Работает хорошо, но дорого.
Строить поближе к полярному кругу. Из районов с достаточным энергообеспечением пока только Норвегия. Там много гидро генерации и в среднем не жарко. НО latency никого не радует если обслуживаешь не Европу.
Но дело в том, что во всех случаях тепло просто выкидывается, да еще и деньги на это тратятся. А хотелось бы тепло использовать, и на этом заработать.
Вариант с прямым отоплением домов не работает, т.к. датацентры специально строятся подальше от жилья и офисов. С ними рядом очень некомфортно находиться из-за шума, выхлопа аварийных дизелей.
Был вариант этим теплым воздухом теплицы греть. А их прям рядом с ДЦ ставить. Но экономика не срастается (если не коноплю выращивать). Да и с безопасностью вопросы.
Греть воду горячим воздухом не получается из-за потребных размеров теплообменников (очень большие).
Ставить гидроблоки на каждый ЦПУ и получать горячую воду напрямую - постоянные протечки и разводка трубок по датацентру выходит слишком дорого.
Адсорбционные холодильники точно можно использовать при таких температурах.
Конечно потребление энергии датацентрами растет, но эта энергия не потреблятся в одном месте. Локально стоит ориентироваться на 10000 серверов = типичное colo. Средний сервер 200 Вт. Коеффициент загрузки по мощности - порядка 50%. Т.е. потребление одного здания порядка 1 МВт в среднем.
Проблема в другом! Холодильник - тепловая машина которая потребляет энергию и прокачивает энергию от "холодного конца" к "горячему концу". Т.е. вся тепловая мощность (потребляемая + прокачиваемая) должна сбрасываться с горячего теплообменника. Сбрасывать 1 МВт имея температуру теплообменника в 50 градусов очень сложно. Теплообменник нужен гигантский и дорогой. Получается очень невыгодно.
В жизни оно работает только если это тепло сбрасывается в воду. Тогда теплообменник имеет разумные размеры. Такие системы работают на сейнерах. Тепло от дизеля прокачивается через адсобционный холодильник в забортную воду. Холодильник морозит рыбу.
Тоесть если речка рядом есть, то можно попробовать. Но экологи сильно не любят ТАКОЙ сброс тепла в местные водоемы. Могут и оштрафовать!
Низкопотенциальное - означает маленькую разницу температур теплоносителя на входе и на выходе. Например, датацентр производит много воздуха нагретого до 45-50 градусов. Или воды нагретой до 40. Забирать теплоноситель из водяного контура крайне нежелательно. Много денег порачено на водоподготовку, да и токсичный он. А использовать теплоноситель такой низкой температуры сложно, транспортировать такое тепло дорого.
О результатах конкурса почитать уже нигде. Это внутренний конкурс и в интернет эти данные никогда не попадали. Да и внутри корпорации эти документы скорее всего уже канули в лету, 14 лет прошло как никак.
В смысле потратить еще денег в дополнение к 1 bln USD по счетам за электричество? А результат отобьется?
https://www.dns-shop.ru/catalog/recipe/83b7b2608460a247/s-kostnoj-provodimostu - не вариант?
С датацентра тепло идет низкопотенциальное (т.е. невысокой температуры). В 2011 Майкрософт проводил внутренний конкурс проектов куда это тепло можно пристроить. Никто не победил.
Но идея про подвалы в принципе годная. т.к. транспортировать такое тепло далеко не надо.
Не нужно греть дом старыми телевизорами! У меня домашний десктоп неспроста имеет БП 1000 Вт мощности. Да и сервер числомолотилка легко скушает 1 кВт, а потом отдаст вам его в качестве отопления. При этом он еще и радостно будет рендерить видео, или распознавать объекты на снимках.
Можно перестать постоянно выключать свет и вообще экономить на освещении. Для большого дома это сотни ватт постоянно.
Нет конечно! Просто добавьте в список другие средства разработки. Например Visual Studio 2018, PyCharm.
И сразу будет заметно, что можно сделать сильно эффективнее без сжирания всей доступной памяти в одно перекормленное лицо.
"Приличное моделирование" должно воспроизводить "неоднородности нейтронного поля на малой мощности" и "неустойчивость реактора в режимах малой мощности и активной работы стежнями СУЗ". Это критерий "приличности" с моей точки зрения.
Какова потребная сложность модели? Видимо с точностью по ТВЭЛа, либо с точностью до кассеты (как минимум). По высоте активную зону придется разбивать на ячейки размером сравнимым с размер графитового наконечника срежня регулирования (точно не менее 100 ячеек по высоте).
Т.е. активную зону моделировать как 1693 * 100 = 169300 независимых тепловыделяющих сборки (с точностью до кассеты). Либо как 1693 * 18 * 100 = 3047400 независимых тепловыделяющих элемента (с точностью до ТВЭЛа). Плюс каналы (и паросодержание в каждом), плюс положение каждого стержня регулирования.
Итого расход памяти на такую модель от миллиона до первых десятков миллионов числовых параметров.
Теперь смотрим на упоминаемую машину М-200 как типичного представителя ЦВМ того времени:
ОЗУ от 4 до 16 тысяч 47-битных слов,
Накопители на магнитном барабане объёмом от 24 до 65 тысяч слов.
Накопитель на магнитной ленте (4 блока) ёмкостью от 4 до 16 миллионов слов
производительность — до 27000 оп/сек И видим, что как сову не натягивай, а нехватка по памяти полтора порядка даже при использовании магнитных барабанов. По производительности тоже все очень плохо. Расчет будет идти со скоростью несколько минут (десятков минут) на один шаг по времени. Т.е. на просчет одного режима уйдут недели и месяцы машинного времени в режиме монопольного использования ЦВМ. А режимов десятки.
Вот я и говорю, что "теми средствами" реалистичную модель было непотянуть. В 80-е что-то моделировать стало возможно. Но к тому времени проект был успешно сдан и снова тратить месяцы и годы на моделирование никто бы не дал.
Очевидно, что сложность модели сильно (О(h^3)) зависит от физических размеров активной зоны. Из-за этого ВВЭРы моделировать проще, а результат выходит точнее.
Печаль - тоска в том, что забывают/игнорируют сценарии реально тяжелого использования. А на них вся эта Electron'ная чухня дохнет, сожрав предварительно всю память.
Если у тебя проект на несколько MLOC и ты открываешь по паре сотен файлов одновременно, сколько инстансов IDE ты можешь запустить одновременно? А ведь надо иногда!
В том же Хроме 2 меня тоже больше сотни вкладок открыто одновременно. Так для удобства приходится 5 инстансов Хрома запускать. И что? Он же сссамка собаки течет и падает.
А ведь когда-то это было нормальным сценарием и все работало! Вкладки в браузере в 3-4 ряда и нормально. Что-то недочитал, недоделал можно было вкладку оставить открытой и не бояться что браузер рухнет и потеряет контекст. Про падения VS вообще никто не думал что так бывает.
А сейчас приложений на JS наклепали, да только они работают по сценарию "строго 1 инстанс, не более 5 файлов разом, раз в день рестартуем ибо течет сильно". Как будто при профессиональном использовании кроме этого приложения человек ничем не пользуется и больше на машине ничего не запускает!
Все электричество которое вы потребляете в доме в конечном итоге превращается в тепло. Поэтому гонять электрообогреватель идея изначально дурная. Нужно гонять оборудование, которое попутно производит что-то еще полезное. Компы которые майнят крипту, обучают нейросетки, обрабатывают видео, хостят что угодно. Телевизоры, освещение - да что угодно, только не тупые электрообогреватели.
В содержании датацентров самое дорогое это не железо, а оплата счетов за электричество. Тут можно иметь и отопление, и национальную сеть по хостингу видео/распознанию образов/расчету фолдинга белков. И все это примерно за одни и те-же деньги.
Ну тут вот товарищ выше пишет, что теперь падает. Либо за последние 4 года начала, либо у него какой-то "особенный" плагин добавлен. Плагины и раньше могли Студию уронить, или всю память сожрать.
Так она раньше не падала. Я даже больше скажу. Она и месяцами работала стабильно, я на ночь ее и не закрывал. Раз в месяц приходили патчи и машина перезагружалась. А остальное время VS перезапускать и не приходилось. А еще у меня в ней по 200 файлов было открыто. И иногда я мог несколько экземпляров VS открыть для разных проектов. И все это прекрасно работало.
Вы просто сравниваете 3-х перекормленных монстров и оказывается что все они примерно одинаковые.
Оно бы было хорошо, если бы не общие библиотеки. От просто общих до системных.
Да в том то и дело, что было не "планомерное снижение мощности", а была "игра мощностью вверх-вниз и долгая работа на половинной мощности". Это и загнало реактор в нестабильный режим ксенонового отравления. В этому добавилось желание провести эксперимент "во что бы ни стало", и регулирование без хорошего понимания процессов в реакторе.
В конструкции реактора были недостатки как в системе регулирования - "положительная обратная связь" ака "положительная реактивность", так и в системе контроля - "параметры критически важные для работы на малой мощности на пульте не отображались".
Но это обычная история, что любая катастрофа это всегда сочетание многих факторов. И не будь любого, аварии бы не было.