Очевидно, с кондиционером первая задача - понять, какие фичи нужны (нужен ли инверторный? мультисплит? какие ограничения на длины магистралей? обогрев?). Это фаза исследования, которую сложно разбить на этапы заранее, но можно останавливаться и фиксировать промежуточные этапы, как описано в статье.
То, что описано в верхнем комменте ветки - это когда выбор поставлен на поток. В работе такое безусловно часто встречается, все эти задачки по перекрашиванию кнопок и перекладыванию json-ов.
В 90х годах было много рекламы изучения английского по курсу Илоны Давыдовой - там еще кассеты были, которые якобы нельзя копировать, иначе эффект пропадёт. Я как прочитал про циклически-волновой способ - сразу вспомнил.
Почему вы пишете, что это первый ARM процессор от Nvidia? У них уже много лет есть опыт, в 2008 году вышел процессор Tegra, потом Jetson - для embedded применений, 3 года назад серверный Grace. Они даже чуть не купили сам ARM - сделка была заблокирована антимонопольными комитетами.
Если будете подобное еще раз проектировать - посмотрите в сторону разъёмов именно для внутри-системного использования, типа SlimSAS 8i (до gen4 можно использовать, в зависимости от спек конкретного кабеля и разъемов), либо MCIO, он же sff-ta-1016.
Прорыв всё же случился раньше, когда они выпустили 32ТБ диски, там впервые были масс-прод диски с технологией HAMR. забавно, что первой в поиске про них как раз статья из блога Селектел на хабре: https://habr.com/ru/companies/selectel/articles/868396/
Иммерсионка, погружные ДЦ - нишевые истории, там всё очень плохо с обслуживанием.
Дальше, про реакторы - больше всего энергии будут потреблять кластера обучения для всяких нейросеток, у которых есть очень неприятная особенность: они синхронно потребляют либо очень много энергии (цикл обучения), либо потребление резко падает в ноль (чекпоинты, восстановление после ошибки, перезапуск джобов и т.д.). И это крайне плохой тип нагрузки почти для любой генерации, кроме гидро, но особенно плохо для атомных реакторов. Потребление кластеров обучения при этом растёт, уже сейчас это единицы и десятки мегаватт, через 5 лет это будут сотни мегаватт и даже единицы гиваватт. Про космос уже сказали, охлаждение в вакууме - это огромная проблема, получение даже единиц мегаватт энергии - тоже. Опять же, огромные проблемы с обслуживанием. Радстойкие высокоэффективные ИИ акселераторы- тоже смешно. Сейчас рядом в картами от нвидии чихнуть опасно, из строя могут выйти, а вы радстойкие хотите.
Про видеть процесс - я почувствовал радикальное улучшение жизни, когда приладил настольную лампу, чтобы светить с нужной стороны на свариваемый участок. Всё же маска притеняет свет, даже когда "открыта", и на "закрытой" яркость высокая.
А ещё - как будто бы электрод 2.4мм примерно всегда можно использовать, но он всегда должен быть наточен хорошо.
Я особо хорошо варить не научился, но TIG прям заставляет видеть ванну, куда как электрод вести, расстояние держать. После этого обычными электродами - вообще халява варить. Но вот нормально подавать пруток я не научился ещё.
Чёрную сталь, конечно, удобнее всего полуавтоматом с углекислотой варить.
Серые кружки снизу - leaf, посередине spine, сверху super-spine, жёлтые плоскости - это edge pod, то, что у вас на картинках подписано как border leaf + spine рядом с ним.
Табличка сравнения ещё более странная, особенно с учётом того, что большие коробки для Fat Tree часто представляют из себя многочиповые устройства, поэтому говорить об отсутствии задержек там.. ну, сомнительно. К тому же, как раз именно Clos проще собрать без переподписки, в отличие от Fat Tree.
Про современные GPU суперкомпьютеры можете почитать в методичках Nvidia про infiniband, там clos или dragonfly+, он же megafly.
Вы хотели мнение читателей? Вот оно: это какой-то неструктурированный поток сознания.
А к чему всё это? Эта статья – не очередное нытье "как плохо быть сисадмином". Эта статья – возможное решение некоторых проблем, с которыми я и мои коллеги сталкиваемся из раза в раз.
Воспринимается ваша статья именно нытьём. Проблемы внятно не обозначены, решения - тоже. Если не согласны - попробуйте сами выписать проблемы, каждая проблема должна быть сформулировать в одном предложении, итоговое решение (или предложение) - 1 абзац текста.
Ещё вам стоит подумать над тем, что стоит перестать ненавидеть своих коллег. Скажем, от наставничества менее опытных коллег в нормальной организации все в выигрыше: он растут, у вас меньше рутины и типовых задач, руководство начинает ценить вас как специалиста, который не только руками умеет работать.
Если аккуратно переписать код, то можно pressureArray и timeArray использовать как циклический буфер, тогда не придётся копировать данные сразу после комментария "// move the array one position to the left".
(Специально пишу отдельным комментарием) С точки зрения реализации в коде, вариометр с капиляром корректнее всего реализовать в виде экспоненциального скользящего среднего, где коэффициент α равен соотношению сечения входящей трубки к сечению капиляра, либо соотношение между сечением капиляра и объёма полости, в зависимости от устройства вариометра.
P.S. Дада, конечно, программистам знать математику совершенно не обязательно, эти основы ЦОС любой же может загуглить :)
Смотрите, вы скопипастили код вариометра, который не очень оптимально работает (как минимум можно убрать копирования в начале), и который вы, полагаю, не до конца понимаете, как работает.
Это код, который написал какой-то итальянец 15 лет назад со словами "я тут из аппнота копирнул и чуть оптимизировал", и дальше логика его работы всё сильнее терялась, путешествуя между форумами и проектами.
Скажите, вот вы сами поняли, что именно считает этот кусок кода?
Как вы определяете реальные потребности конкретного софта в железе, если не через нагрузочное тестирование? Скажем, вам надо развернуть объектный сторадж на Ceph/Minio, или L7 балансировщик нагрузки (он же API GW) - как вы будете выбирать, сколько под это надо "железа"?
С профилировкой и оптимизациями уже запущенного понятно, там правда начинать придётся с продакшен нагрузки, потому что надо ещё придумать, как (и получится ли) повторить синтетикой.
Мне, например, до сих пор непонятно - как этому вообще можно научиться, не запустив ну хотя бы с десяток высоконагруженных проектов. А человеку без опыта никто не даст их запускать, и круг замыкается.
Не обязательно новое запускать, это больше про нагрузочное тестирование. Характерные паттерны потребления железа разными видами систем как раз можно таким образом изучить, и дальше, когда надо будет планировать что-то новое, у вас уже будут в голове цифры, от которых можно отталкиваться.
Очевидно, с кондиционером первая задача - понять, какие фичи нужны (нужен ли инверторный? мультисплит? какие ограничения на длины магистралей? обогрев?). Это фаза исследования, которую сложно разбить на этапы заранее, но можно останавливаться и фиксировать промежуточные этапы, как описано в статье.
То, что описано в верхнем комменте ветки - это когда выбор поставлен на поток. В работе такое безусловно часто встречается, все эти задачки по перекрашиванию кнопок и перекладыванию json-ов.
В 90х годах было много рекламы изучения английского по курсу Илоны Давыдовой - там еще кассеты были, которые якобы нельзя копировать, иначе эффект пропадёт. Я как прочитал про циклически-волновой способ - сразу вспомнил.
Возможно, вы хотите сказать, что не было интерливинга? Пробовали переключать опцию, которая обычно называется Memory channel interleaving?
Почему вы пишете, что это первый ARM процессор от Nvidia? У них уже много лет есть опыт, в 2008 году вышел процессор Tegra, потом Jetson - для embedded применений, 3 года назад серверный Grace. Они даже чуть не купили сам ARM - сделка была заблокирована антимонопольными комитетами.
На хабре про всё это тоже было: https://habr.com/ru/companies/serverflow/articles/838040/
Если будете подобное еще раз проектировать - посмотрите в сторону разъёмов именно для внутри-системного использования, типа SlimSAS 8i (до gen4 можно использовать, в зависимости от спек конкретного кабеля и разъемов), либо MCIO, он же sff-ta-1016.
Прорыв всё же случился раньше, когда они выпустили 32ТБ диски, там впервые были масс-прод диски с технологией HAMR. забавно, что первой в поиске про них как раз статья из блога Селектел на хабре: https://habr.com/ru/companies/selectel/articles/868396/
Скажите, а вы в дата-центре были?)
Иммерсионка, погружные ДЦ - нишевые истории, там всё очень плохо с обслуживанием.
Дальше, про реакторы - больше всего энергии будут потреблять кластера обучения для всяких нейросеток, у которых есть очень неприятная особенность: они синхронно потребляют либо очень много энергии (цикл обучения), либо потребление резко падает в ноль (чекпоинты, восстановление после ошибки, перезапуск джобов и т.д.). И это крайне плохой тип нагрузки почти для любой генерации, кроме гидро, но особенно плохо для атомных реакторов. Потребление кластеров обучения при этом растёт, уже сейчас это единицы и десятки мегаватт, через 5 лет это будут сотни мегаватт и даже единицы гиваватт. Про космос уже сказали, охлаждение в вакууме - это огромная проблема, получение даже единиц мегаватт энергии - тоже. Опять же, огромные проблемы с обслуживанием. Радстойкие высокоэффективные ИИ акселераторы- тоже смешно. Сейчас рядом в картами от нвидии чихнуть опасно, из строя могут выйти, а вы радстойкие хотите.
Про видеть процесс - я почувствовал радикальное улучшение жизни, когда приладил настольную лампу, чтобы светить с нужной стороны на свариваемый участок. Всё же маска притеняет свет, даже когда "открыта", и на "закрытой" яркость высокая.
А ещё - как будто бы электрод 2.4мм примерно всегда можно использовать, но он всегда должен быть наточен хорошо.
Для алюминия переменка нужна, чтобы оксидную плёнку разбивать. У неё температура плавления почти в 2 раза выше, чем у самого алюминия.
А вот нержа - для неё достаточно среды аргона, ну и присадку из нержавейки, а дальше хоть TIG, хоть MIG (полуавтомат с баллоном аргона) - норм будет.
Я особо хорошо варить не научился, но TIG прям заставляет видеть ванну, куда как электрод вести, расстояние держать. После этого обычными электродами - вообще халява варить. Но вот нормально подавать пруток я не научился ещё.
Чёрную сталь, конечно, удобнее всего полуавтоматом с углекислотой варить.
Почему? Новые маски просто по приколу делать? Это же дорого, единицы миллионов долларов.
У вас весь раздел про Clos и Fat Tree некорректный.
В части про Clos нету ничего про плейны, и ничего про radix - а это основа расчёта портовой ёмкости сети в топологии Clos. Хорошие картинки есть у фб в этой статье: https://engineering.fb.com/2019/03/14/data-center-engineering/f16-minipack/
Серые кружки снизу - leaf, посередине spine, сверху super-spine, жёлтые плоскости - это edge pod, то, что у вас на картинках подписано как border leaf + spine рядом с ним.
Табличка сравнения ещё более странная, особенно с учётом того, что большие коробки для Fat Tree часто представляют из себя многочиповые устройства, поэтому говорить об отсутствии задержек там.. ну, сомнительно. К тому же, как раз именно Clos проще собрать без переподписки, в отличие от Fat Tree.
Про современные GPU суперкомпьютеры можете почитать в методичках Nvidia про infiniband, там clos или dragonfly+, он же megafly.
Ради чего вы хотите применять двухфазный коммит вместо обычной sql транзакции?
Вы хотели мнение читателей? Вот оно: это какой-то неструктурированный поток сознания.
Воспринимается ваша статья именно нытьём. Проблемы внятно не обозначены, решения - тоже. Если не согласны - попробуйте сами выписать проблемы, каждая проблема должна быть сформулировать в одном предложении, итоговое решение (или предложение) - 1 абзац текста.
Ещё вам стоит подумать над тем, что стоит перестать ненавидеть своих коллег. Скажем, от наставничества менее опытных коллег в нормальной организации все в выигрыше: он растут, у вас меньше рутины и типовых задач, руководство начинает ценить вас как специалиста, который не только руками умеет работать.
Если аккуратно переписать код, то можно pressureArray и timeArray использовать как циклический буфер, тогда не придётся копировать данные сразу после комментария "// move the array one position to the left".
(Специально пишу отдельным комментарием)
С точки зрения реализации в коде, вариометр с капиляром корректнее всего реализовать в виде экспоненциального скользящего среднего, где коэффициент α равен соотношению сечения входящей трубки к сечению капиляра, либо соотношение между сечением капиляра и объёма полости, в зависимости от устройства вариометра.
P.S. Дада, конечно, программистам знать математику совершенно не обязательно, эти основы ЦОС любой же может загуглить :)
Смотрите, вы скопипастили код вариометра, который не очень оптимально работает (как минимум можно убрать копирования в начале), и который вы, полагаю, не до конца понимаете, как работает.
Это код, который написал какой-то итальянец 15 лет назад со словами "я тут из аппнота копирнул и чуть оптимизировал", и дальше логика его работы всё сильнее терялась, путешествуя между форумами и проектами.
Скажите, вот вы сами поняли, что именно считает этот кусок кода?
Как вы определяете реальные потребности конкретного софта в железе, если не через нагрузочное тестирование? Скажем, вам надо развернуть объектный сторадж на Ceph/Minio, или L7 балансировщик нагрузки (он же API GW) - как вы будете выбирать, сколько под это надо "железа"?
С профилировкой и оптимизациями уже запущенного понятно, там правда начинать придётся с продакшен нагрузки, потому что надо ещё придумать, как (и получится ли) повторить синтетикой.
Не обязательно новое запускать, это больше про нагрузочное тестирование. Характерные паттерны потребления железа разными видами систем как раз можно таким образом изучить, и дальше, когда надо будет планировать что-то новое, у вас уже будут в голове цифры, от которых можно отталкиваться.
Windows 95, кажется, поставлялся на 14 дискетах.