MSI Afterburner получил V/F-карту попаданий и плагин GPUProbe в новой бета-версии Вышла тестовая сборка MSI Afterburner v4.6.7 Beta 4, главной фичей которой стала карта попаданий (Hitmap) в редакторе кривых напряжения и частоты. По нажатию клавиши M программа накладывает на V/F-кривую до 256 последних рабочих точек с цветовым градиентом, отражающим частоту обращения к ним. Инструмент облегчает даунвольтинг и разгон, позволяя наглядно увидеть реальное поведение графического процессора и выявить неиспользуемые отрезки кривой. В дистрибутив также включили плагин GPUProbe для низкоуровневого мониторинга через MMIO и I2C Кроме того, Afterburner научился автоматически отключать низкоуровневый мониторинг на неизвестных/неподдерживаемых архитектурах GPU.

MSI Afterburner получит плагин GPUProbe для чтения скрытых датчиков видеокарт Создатель MSI Afterburner Алексей Unwinder Николачук представил встроенный плагин GPUProbe, который возрождает концепцию одноименного инструмента для RivaTuner. Плагин умеет считывать данные через регистры MMIO и шину I2C, открывая доступ к скрытым датчикам: температуре HotSpot, отдельных чипов VRAM, силовых элементов VRM и контроллеров питания. Пользователи смогут добавлять новые сенсоры самостоятельно через конфигурационные файлы, не дожидаясь официальных обновлений программы. В качестве примера автор показал интеграцию с кастомными картами ASUS ROG Astral. Плагин считывает ток с каждого контакта 12VHPWR и формирует «сигнал тревоги», если сила тока на пине превышает 12 А или разница между контактами составляет более 5,5 А. Afterburner может автоматически реагировать на аварийный статус — например, снижать Power Limit или выключать ПК. Из-за ограничений соглашений с NVIDIA полноценная встроенная поддержка этих функций в утилите отсутствует, поэтому GPUProbe останется плагином для энтузиастов.

В США 50 штатов и в каждом штате свои законы, акты постановления. И если корпорация достаточно велика – она зависит от всех 50 штатов и хотела бы на все эти 50 штатов влиять. Когда в профильном комитете конгресса условной Невады возникает очередная не очень приятная для бизнеса идея, то лоббисту Walmart надо бы на всех парах мчаться именно в Неваду, стучаться именно в этот комитет, и объяснять, доказывать, договариваться. #стартапдня State Affairs продает удобный инструмент для мониторинга таких идей. Его продукт – база знаний обсуждений, законопроектов, предложений и прочих личинок будущих законов. Они ещё не приняты и не опубликованы официально, на них ещё можно повлиять – и именно в этот момент живой человек прямо из здания конгресса вносит их в систему, а AI перерабатывает в пригодный для поиска и фильтрации вид. Клиент спрашивает что-то типа: “какие есть обсуждения по маркировке AI-контента” и сразу узнает общий срез по всем стране. Мониторинг одного штата стоит порядка 600 долларов в год – и State Affairs утверждает, что треть законодателей страны платят эту сумму, чтобы читать по сути про самих себя. Полная подписка на США целиком обходится корпорациям уже в десятки тысяч долларов – впрочем, для них всё равно копейки. Инвестиций стартап привлек около 70 миллионов. Любопытно, что существенную их часть он потратил на покупку старых, иногда столетних микробизнесов – местных парламентских вестников в столицах штатов. Их бывшие корреспонденты как сидели на слушаниях, так и сидят. Для них изменилась только админка, куда надо загружать отчеты. https://stateaffairs.com/ #сша #юристы #roundb

HWiNFO научится замерять температуру каждого чипа VRAM на видеокартах AMD и NVIDIA Разработчики утилиты HWiNFO внесли в список ближайших обновлений функцию почипового мониторинга температуры видеопамяти для карт AMD семейства Navi. Вместо единого общего значения датчики покажут нагрев каждого отдельного модуля GDDR6. Это поможет пользователям находить локальный перегрев, вызванный плохим контактом с термопрокладкой, неравномерным прижимом кулера или дефектами системы охлаждения. Точный список поддерживаемых поколений Radeon пока не объявлен, но архитектурно функция может затронуть серии от RX 5000 до RX 9000. Аналогичный мониторинг готовят и для карт NVIDIA с памятью GDDR6X и GDDR7.

Самые неприятные баги — это те, из-за которых система работает, потом не работает, а через пять минут снова работает, будто ничего не произошло. 😬 Именно такой баг жил на YHub целый месяц. Сегодня я наконец нашёл его причину, но сначала дам немного контекста. Уже месяц на YHub можно создавать собственные базы данных.

То есть если вы написали какое-то фронтенд-приложение и вам нужна база, то вместо того чтобы прикручивать сложные сторонние сервисы или пытаться хранить всё в Local Storage, вы можете прямо в админке своего сайта включить базу данных, создать необходимые таблицы и получить полноценный API для работы с ними.

Плюс можно создать таблицы, необходимые для аутентификации пользователей, и получить весь нужный функционал для регистрации, авторизации и так далее. 👌 В целом всё это работает хорошо. Я сам построил на этом несколько сайтов, моя игра тоже использует эту базу данных, а жена сделала несколько приложений, которые так или иначе с ней работают. 🤔 И вот как раз жена первой начала мне репортить, что иногда у неё просто пропадает таблица с рейтингом. Но после перезагрузки всё снова появляется и данные приходят. На тот момент я счёл этот баг не очень интересным. 🤷‍♂️ Подумал, что, может быть, произошла какая-то сетевая задержка или что-то было не так в её клиентском JavaScript. Я спросил: — Сейчас работает? Она сказала: — Сейчас работает. И мы такие: — Ну, работает — не трожь. Значит, всё хорошо. 👀 Но относительно недавно я прикрутил полноценный мониторинг ко всем функциям YHub. Раньше я мониторил только сам YHub и его основные модули: работает ли приложение, отвечает ли сервер. А теперь начал дополнительно проверять отдельные фичи, чтобы убедиться, что они тоже работают и ничего не отвалилось. И вот мониторинг начал ловить нестабильные ошибки. Условно, сначала он получает 200 OK: всё хорошо, база работает, данные записываются. ✅ Через пять минут приходит 404, будто база данных вообще не включена. ❌ А ещё через пять минут снова 200 OK, и всё опять прекрасно работает. ✅ Такое поведение — когда что-то работает, через пять минут не работает, а потом снова работает — это, наверное, самое неприятное, что может произойти при отладке. 😩 Баг не воспроизводится стабильно, поэтому непонятно, за что вообще цепляться. Но, вооружившись Codex, своими наблюдениями и несколькими теориями, я пошёл дебажить архитектуру и нашёл очень интересный момент. 🤔 На моём хостинге используется PHP Runtime. Чтобы всё это было безопасно, я изолирую сайты на уровне операционной системы. Для каждого окружения создаётся отдельный PHP-FPM-пул, который работает внутри собственного chroot. Благодаря этому процессы разных пользователей не должны видеть файлы друг друга. 😬 Но, когда я настраивал эту изоляцию, я пропустил одну важную настройку в OPcache. OPcache хранит в общей памяти уже скомпилированный байткод PHP-скриптов, чтобы не разбирать и не компилировать их заново при каждом запросе. Проблема была в том, что внутри каждого изолированного окружения сгенерированный API-скрипт находился по одному и тому же пути. А настройка opcache.validate_root, которая заставляет OPcache учитывать конкретный chroot, у меня была выключена. 🤦‍♂️ В результате для OPcache скрипты разных пользователей могли выглядеть как один и тот же файл. OPcache мог взять скомпилированный скрипт из одного окружения и использовать его при запросе к другому. 🤷‍♂️ В какой-то момент в кэше оказывалась скомпилированная версия скрипта сайта, на котором база была отключена. Поэтому мой сайт внезапно получал 404, хотя у него самого всё было включено и настроено. 💡 Это интересный пример того, как кэширование становится источником проблем в разработке. Кэширование — это, конечно, хорошо. Я не говорю, что его нужно избегать. Оно ускоряет работу системы и часто действительно необходимо. Но кэшировать тоже нужно с умом. В моём случае я просто забыл указать в настройках, что кэширование должно учитывать chroot пользователя, и получил вот такую интересную проблему. Причём именно мониторинг помог мне с ней разобраться. У меня были конкретные даты и время, когда всё работало, а когда отваливалось. Без мониторинга я вообще не представляю, как бы это отдебажил. 😅 Но теперь всё исправлено. После изменения настройки ошибка больше не повторялась, а мониторинг снова стабильно зелёный. 💪 Свята место | 10МДК | ВЕБМастер | YHub

Контроль температуры: энтузиасты научились мониторить нагрев чипов памяти GDDR7 Разработчики утилит MSI Afterburner, RTSS и HWinfo смогли обойти ограничения Nvidia и активировали мониторинг температурных датчиков памяти нового стандарта GDDR7 на видеокартах серии RTX 50. Свежая версия HWinfo уже позволяет считывать эти данные в реальном времени, что ранее было доступно только для чипов GDDR6 и GDDR6X. Поскольку интеграция проводилась без официальной документации производителя, пока есть ограничения по детализации. На флагманской RTX 5090 отображается 8 температурных точек на 16 чипов памяти (один датчик на пару), а на RTX 5060 Ti с 16 ГБ доступны данные всего с двух сенсоров. Кроме того, софт пока не показывает точное физическое расположение наиболее горячих зон на плате, но авторы планируют исправить это в ближайших обновлениях.

Сайты падают по расписанию рабочей недели, а в выходные почти нет В четверг сайты падают на треть чаще, чем в воскресенье. Серверам к концу недели не тяжелее, просто в выходные никто не деплоит и не трогает прод. Сайты ломают люди, а не энтропия. Та же логика в графике по часам: главный пик приходится на рабочий день, но пятый по аварийности час суток это полночь, когда стартуют кроны и ночные выкатки в духе «всё равно никто не смотрит». За год мониторинга 6 500 сайтов набежало 108 312 инцидентов, и картина выходит скучнее любых страшилок про взломы и DDoS. Половина всех падений это простой таймаут, когда сервер жив, но задумался. А самое обидное ждёт ночью. Короткие сбои чинит автоматика, которой всё равно, который час, но если она не справилась, длинные инциденты в темноте закрывают на 35% дольше, потому что дальше всё зависит от человека, а человек спит. Выясним, сколько сайтов на деле держат обещанные три девятки аптайма и что за аномалия случилась в июне.

Еще раз обращаю внимание на англоязычный канал Brandmauer Report. Там публикуется то, чего здесь не будет. В силу того, что всякие международные темы будут просто неинтересны читателям на русском. Ну, например, вот про британскую цензуру, которая объявила всех жителей Великобритании детьми: https://t.me/brandmauer_report/36 Или что творится в отношениях между Китаем и Тайванем в области трансграничной интернет-слежки: https://t.me/brandmauer_report/34 В Бразилии, вот, запилили "счетчик посадок в тюрьму" (тюрьмометр?) и сделали из этого шоу, которое продвигает сеть камер видеонаблюдения Smart Sampa. https://t.me/brandmauer_report/33 Я сам об этом бы и не узнал, потому что никто (из живых людей) не способен отслеживать такой объем информации. А вот теперь с инструментами ИИ — можно. Вот вам пример "Искин на страже демократии". Или как хотите называйте. Но проект буду развивать. И там важно, чтоб была аудитория, которая отмечает посты реакциями. Кстати, о реакциях. И почему на этом канале их только две, и они максимально упоротые: "хот-дог" и "синий кит". Да потому, что непонятно, как эти реакции интерпретировать. Субъект и объект поста не уточнены. Ну, то есть, вот эта вот "какашка" — она кому поставлена? Автору или объекту, упомянутому в посте? Я думаю как раз как бы это красиво резвести, но пока решил просто набрать данных.

Раньше ПО работало шустро, потому что иначе было никак Пайплайн упал — подняли память. Сервис затупил — добавили ядер. Дежурный заложил буфер, потому что никто не хочет подрываться ночью. Через полгода исходного контекста уже никто не помнит, и эта конфигурация становится строгим требованием. Парадокс в том, что сервис при этом выглядит здоровым. Он использует 10% от выделенных 64 ГБ, мониторинг светится зелёным, команда эксплуатации спокойна. Мы научились поднимать тревогу при перегрузке, но почти никогда не создаём алёрты на структурную пустоту. Разберёмся, где именно проходит граница между неизбежной сложностью и накопленным суеверием.