Ошибки в компьютерных системах обнаруживают постоянно, причем они могут быть связаны не с дизайном процессора, а внешним воздействием. Например, из-за радиации, поэтому для работы в космосе изготавливаются специальные чипы.
Но даже естественный радиационный фон может приводить к битовым ошибкам памяти. Подобные битовые ошибки возникают с вероятностью одна в год на гигабайт памяти DRAM. Для домашних пользователей подобные ошибки угрозы не представляют, чего нельзя сказать о крупных дата-центрах с несколькими тысячами вычислительных узлов и терабайтами памяти. Поэтому там используется дополнительная защита памяти с помощью ECC, что позволяет выявлять и исправлять битовые ошибки. Однако они могут происходить и из-за перегрева, например.
В компьютерных системах встречается совсем другой класс ошибок, который не был хорошо изучен ранее. Представьте крупный дата-центр с несколькими тысячами вычислительных узлов, каждый из которых содержит не менее одного 64-ядерного процессора. Причем все тысячи ядер должны работать одинаково, то есть при нагрузке вычислительной работой выдавать одинаковый результат. Но так бывает не всегда. Исследователи Google опубликовали документ (PDF) под названием "Cores that don't count", где рассмотрен как раз данный эффект. Ранее феномен тоже был известен как Corrupt Execution Errors (CEE). Facebook провела похожее исследование и назвала эффект Silent Data Corruption (SDC).
Google обнаружила повторяющиеся ошибки в своих дата центрах на определенных компонентах. Причина явно заключалась в дефекте производства, но все тесты не смогли выявить ошибки. Дело в том, что отдельные ядра дают ошибки только при определенных условиях и наборах инструкций. Кроме того, ошибки возникают лишь через некоторое время, а не с самого начала. Причем ошибки возникают в отдельных ядрах, но не во всех процессорах данного типа. Эти ядра названы Mercurial Cores, что можно трактовать как "непостоянный" или "капризный".
Причем феномен Mercurial Cores возникает намного чаще, чем предполагалось ранее. Google оценивает единицы "капризных" ядер на несколько тысяч серверов, но без подробностей. Facebook тоже оценивает число ядер весьма размыто.
Google видит несколько причин появления подобного класса ошибок:
- Постоянное увеличение размера и сложности процессоров
- Переход на все меньшие техпроцессы снижает устойчивость к сбоям и увеличивает риск эффекта выгорания
- 3D-корпусировка чипов еще сильнее увеличивает сложность
Появлению Mercurial Cores способствуют некоторые сочетания частоты, напряжения и температуры. Но ошибки могут возникать как на высоких напряжениях и частотах, так и на низких. Динамическое изменение частоты/напряжения современных CPU затрудняет выявление ошибок. И теперь мы переходим к главному вопросу: как можно быстро выявить "капризные" ядра и изолировать их в системе, чтобы они больше не вносили ошибки в вычисления? Авторы предлагают несколько теоретических подходов, от тестирования железа перед установкой в дата-центр до определения "на лету". Однако гиперскейлеры вряд ли захотят выводить из работы компоненты для тестирования, поскольку это приведет к простою. Поэтому требуется решение, способное удовлетворить всех.
После определения Mercurial Core его следует изолировать и отключить, чтобы процессор больше не использовал его для вычислений. Исследователи говорят о том, что производители должны улучшить дизайн своих чипов для выполнения автоматического тестирования, а также для постоянной верификации результатов. Подобные ошибки могут приводить к серьезным проблемам, поскольку если Mercurial Core занимается шифрованием данных, то их можно полностью потерять.
Исследователи уже привлекли внимание Google к данной проблеме. Одно можно сказать точно: "капризные" ядра возникают намного чаще, чем хотят показать в своих симуляциях и отчетах производители чипов и серверов. Еще только предстоит разработать эффективные способы определения и предотвращения подобных проблем. Причем ошибки могут наблюдаться на чипах всех видов, будь то классические процессоры, GPU, ускорители AI/ML, Smart NIC и многие другие. Google не указывает название компонентов, которые тестировались. Лишь один раз упоминаются собственные TPU.
Подписывайтесь на группы Hardwareluxx ВКонтакте и Facebook, а также на наш канал в Telegram (@hardwareluxxrussia).