Инженеры Google и Facebook предположили, что постоянное уменьшение размеров техпроцессов в сочетании с возрастающей сложностью архитектурного проектирования приводит к снижению надёжности микросхем. Микроэлектроника выходит из строя из-за перегрева, интенсивного использования компьютера, перепада напряжения, механического воздействия, неисправности материнской платы и огрехов при проектировании и сборке. Тем не менее, частота появления ошибок до этого не вызывала сильного беспокойства по поводу надёжности микросхем у производителей электроники и её пользователей.  В последние годы инженеры фиксируют рост числа неполадок, связанных с работой процессоров. Например, устройства выявляли несуществующие ошибки в крупных хорошо отлаженных приложениях. Дополнительная диагностика приложений не подтверждала наличие ошибок.  Инженеры Google занялись изучением задействованных кодов и операционной телеметрии своих устройств. В результате они обнаружили больше ошибок, чем ожидали. Ошибки носят случайный, спорадический характер и проявляются не на целых микросхемах или семействах компонентов, а на отдельных ядрах спустя много времени после начала эксплуатации процессора. По мнению инженеров, неполадки появляются из-за «неустойчивых ядер», время от времени совершающих ошибки в расчётах. Специалисты утверждают, что выявленные неполадки не связаны с архитектурой микросхем, и их нельзя обнаружить во время производственных испытаний.  В феврале этого года Facebook опубликовала статью, где приводит пример проявляющейся от случая к случаю ошибки. По словам инженеров, подобное искажение в дата-центрах встречается им всё чаще. Такие ошибки трудно обнаружить и исправить.  Инженеры Facebook приводят пример из практики. В крупных инфраструктурах незадействованные в работе файлы сжимаются. Программа распаковывает их, когда поступает запрос на чтение. Перед распаковкой программа проверяет размер файла: он должен быть больше 0. В примере из статьи алгоритм показал нулевое значение для файла ненулевого размера, из-за чего файл не попал в распаковку базы данных. В результате совершившая запрос инфраструктура сообщает о потере данных при распаковке. В системах большого масштаба обнаружить и воспроизвести подобный сценарий сложно, поэтому инженеры работали с одним устройством. Затем инженеры обнаружили, что ошибка носила единичный характер при многопоточной рабочей нагрузке и постоянный при однопоточной нагрузке для определенного подмножества значений данных на одном конкретном ядре устройства.  После нескольких повторений на устройстве исследователи поняли, что вычисление Int (1.1^53) в качестве входных данных для функции math.pow в Scala всегда выдаёт результат 0 на ядре 59 процессора. Когда они заменили вычисление на Int (1.1^52), программа выдала ожидаемый результат 142.  Приведённая выше диаграмма показывает поток первопричин. Неправильный результат приводит не только к нулю в качестве результата. Инженеры определили, что вычисления влияют на положительные и отрицательные степени для конкретных значений данных. Примеры ошибок: Int [(1.1)^3] = 0, расчётный = 1; Int [(1.1)^107] = 32809, расчётный = 26854; Int [(1.1)^-3] = 1, расчётный = 0.  В реальном приложении эта ошибка приводит к распаковке файлов с неправильными размерами и некорректной меткой end of file, из-за чего данные терялись или повреждались. По словам инженеров, им трудно определять подобные проблемы по причине прямой зависимости от корректности работы процессора.  Инженеры Google столкнулись со схожими ошибками и назвали её проблемой  «неустойчивых ядер». 2 июня они опубликовали статью на эту тему.  Специалисты назвали найденные в ядрах ошибки CEE (ошибка выполнения с искажениями — corrupt execution error). Незаметные CEE затрагивают работу отдельных ядер, а не всего чипа. Они появляются незаметно и постепенно выводят устройство из строя. Примеры ситуаций, при которых инженеры сталкивались с CEE: Нарушения семантики блокировки, приводящие к повреждению данных приложений и сбоям. Повреждение данных, вызванное различными операциями загрузки, хранения, направления и когерентности. Неправильное вычисление AES: шифрование и дешифрование в одном и том же ядре выполняли функцию идентификации, но дешифрование в другом месте выдавало тарабарщину. Повреждение, влияющее на сборку мусора в системе хранения и приводящее к потере данных в реальном времени. Повреждение индекса базы данных, приводящее к тому, что некоторые запросы, не зависящие от того, в каком ядре происходит обработка, повреждены. Повторяющиеся битовые сдвиги в строках в определенной позиции бита (что вряд ли появилось в результате ошибок в коде). Повреждение ядра, приводящее к сбоям в работе процессов и приложений. В своей работе Google пытается объяснить причины появления этих ошибок. Производители приближаются к пределам масштабирования чипов и усложняют архитектуру устройств. Из-за этого инженерам приходится дорабатывать и усложнять методы диагностики, что всё равно не гарантирует отсутствие случайных ошибок. Размеры кремниевых элементов измеряются в нанометрах. Это сужает поле для ошибок, но повышает риск сбоев при перегреве. Кроме того, наложение слоёв увеличивает сложность структуры и производственные риски. Повышение сложности приводит к специфическому поведению CEE при общей правильной структуре ядра.  Инженеры Google отмечают сниженную эффективность диагностики при работе с крупномасштабными структурами. Они утверждают, что эта проблема со временем будет только усугубляться, и пока нет эффективного метода диагностики случайных ошибок в «неустойчивых ядрах».  Специалисты отмечают, что их работа основана на анализе поведения реальных микросхем, а не исследованиях происходящих в них физических и химических процессов. Они хотят разработать симуляторы процессора и загрузить в них разные виды незаметных CEE. Таким образом инженеры планируют разработать эффективные методы диагностики ошибок и устойчивые к CEE алгоритмы. На данный момент инженеры планируют работать совместно с разработчиками над повышением надёжности оборудования:  Производство программ для тестирования процессоров и поиск ядер с незначительными производственными дефектами. После передача этих тестовых характеристик конечным пользователям.  Непрерывная проверка, при которой функциональные подразделения всегда проверяют свои собственные результаты.  Консервативное проектирование критически важных функциональных блоков с учётом дополнительной площади и мощности для обеспечения надёжности.  Информационная служба Хабра