Comments 134
С нейтрино еще сложней. :)
Интересный эксперимент. Я думаю, если финансы позволяют, есть смысл его продолжить чтобы дождаться активности на Солнце и проверить, будут ли случайные заходы.
Хотя, что-то мне подсказывает, что можно сделать гораздо проще. Можно написать программу, которая создаст 3 больших массива с одинаковыми данными и через определенные промежутки времени сравнивать их между собой. Или просто, вычислить контрольную сумму для каждого мегабайта и периодически проверять.
Эффект должен зависеть от площади кристалла, а в одном ПК он минимален.
Я когда-то так и делал.
чтобы доказать, что в сетевом оборудовании есть какие-то сбои, файл из 10 миллионов нулей гонял по сети. За час появлялось пару измененных байтов.
Это называется "тройное модульное резервирование". Для МК в космосе этот принцип реализуется аппаратно для ОЗУ.
У вас сервера на проде без ECC? :)
Так, по идее, заходят-то клиенты на битфлипнутые домены. А у клиентов какой только хлам в качестве компов не стоит.
Правда, тут другая проблема вырисовывается - а где гарантия, что битфлип произошёл от заряженной частицы, а не из-за высохшего электролита на древней мамке и/или в кЕтайском БП?
Пойду протру линзы :)
У меня сразу мысль появилась, что это имело бы хоть какой-то смысл на сервере - изменение ссылок в коде страниц (какой-нибудь горячий кэш nginx например). А на клиенте - это слишком многое должно наложиться чтобы произошло именно так. Кмк можно считать вероятность такого события стремящейся к нулю.
У меня тоже коллизии с 1 апреля после прочтения.
Пусть, вероятность флипа какого-то одного бита в 4Гб памяти в течение 3 суток равна 0.96. Тогда, вероятность флипа того-самого бита за сутки будет 1e-11, если считать, что равновероятен флип любого из битов (однако, я не уверен, не имеет ли места быть что-то типа парадокса дней рождения, из-за чего вероятность поменьше). Пусть у домена 1млн посетителей в сутки и они проводят на сайте по 30 минут. Итого, 2e-7 вероятность такого события за день. Или 0.72% (0.0072) за 100 лет.
Путь лучше те мошенники ждут, что Вы промахнётесь пальцем по клавише.
У исследователей был ntp, где достаточно одного пакета (с). У вас tls over tcp. Вряд ли вы дождетесь.
Несомненно они врядли дождутся.
Но какой вклад в это вносит tls over tcp ? Вероятность того, что при безопасном для оператора радиационном фоне бит в адресе доменном имени будет испорчен непосредственно в момент установки соединения настолько мала, что ей можно полностью пренебречь.
А в ситуации когда где-то в памяти доолго лежит (попорченная за время лежания) строчка c адресом доменным именем не так уж важно по udp ли будет идти коннект после резолвинга, или по tcp, а сверху - tls. Да, могут быть (а могут и не быть) нюансы с проверкой сертификата клиентом, но в логи сервера такие (попытки установки) подключения все равно попадут (при их правильной настройке).
Как раз вероятность искажения бит в момент передачи очень высока, потому во всяких Ethernet избыточное кодирование. А поверх этого контрольные суммы в tcp. Ну а если ещё поверх этого и tls, то вероятностью непреднамеренного искажения можно вообще пренебречь.
Исходная статья про ошибки связанные с воздействием ионизирующего излучения на электронные компоненты (в первую очередь - память), а не про помехи в линиях связи.
Впрочем, это не столь важно: ибо описанная в статье атака пытается эксплуатировать предположение, что у кого-то из пользователей в результате искажения бита станет испорчен адрес доменное имя целевого ресурса. Процессу же разрешения доменного имени абсолютно безразлично, будет ли разрешенный адрес дальше использоваться для UDP, или TCP с TLS.
ps: нет во всяких Ethernet никакого избыточного кодирования. Лишние битики в поток данных добавляют (плюс скремблируют) не для коррекции ошибок, а для упрощения приемо-передающей части (в частности - возможности использования трансформаторной развязки, и синхронизации тактовых последовательностей).
В радиоканалах (wi-fi) применяют прямую коррекцию ошибок, FEC, а в медных каналах (over twisted) хватает повторного запроса по CRC. В оптике тем более только повторный запрос. То есть зависит от типа физической среды передачи.
Хотя в гигабитном ethernet over twisted применяется FEC, ибо скорость высокая (не 100 Мб/с), но та же среда передачи.
на компьютере с 4 Гб оперативной памяти есть 96% шанс переворота битов в течение трех дней.
ввел в адресную строку браузера домен windows.com, бит перевернулся
Пусть даже не "ввел в адресную строку" (что требует переворота бита не за три дня, а за три секунды) а "где-то в памяти хранится". Мы же понимаем, что даже при 100% вероятности переворота одного бита в 4GB памяти, вероятность того, что этот переворот произойдет именно в 16 байтах time.windows.com - 
, т.е. 0,0000004 %. А если учитывать то, что из этих 16 байт реально доступны для атаки всего 8 (.windows), а в этих байтах можно атаковать далеко не все биты, то шансы еще меньше.
Впрочем количество количество windows ПК столь велико, что единичные (но никак не 200000) события с обусловленным SEU доступом к условному windo7s.com представляются относительно вероятными.
А вот затея со sbis.ru практически наверняка обречена на провал: во-первых буковок меньше, а в главных - на многие порядки менше количество ПК.
А сталкивались ли вы с космической проблемой?
Каждый раз, покупая ECC-память вы сталкиваетесь с ее решением (не 100%, но близким к тому).
Крайне мало персоналок поддерживает ЕСС.
Нонче не проблема купить неынтерпрайзные проц, мамку и память, поддерживающие ECC. AMD-only. А ынтiль как обычно причмокивает :)
90% персоналок на платформе AMD с 2017 г.
\* 10% упоротых моделей матерей, где ECC заводится только под Linux, потому производитель не удосужился хоть как-то включить ECC в прошивке. Поздние матери все без официальной на то поддержки заявляют работоспособность c ECC.
Простите? Я уже двадцать лет как немного далек от компьютерного железа (хвала эппл, абстрагировала меня от этого), но всегда полагал intel - вендором с 70% рынка, а amd - фаблесс-конторкой на оставшиеся 30. А успехи AMD последних лет связанными с геймерами, то есть преходяще.
Хм, и первая ссылка в гугле согласна: In the second quarter of 2024, 64 percent of x86 computer processor or CPU tests recorded were from Intel processors, while 33 percent were AMD processors. When looking solely at laptop CPUs, Intel is the clear winner, accounting for 75 percent of laptop CPU test benchmark results in the second quarter of 2024
upd: извините, я понял - кажется, вы про наличие ECC на PC.. Комментарий можно удалить?
upd: извините, я понял - кажется, вы про наличие ECC на PC.. Комментарий можно удалить?
Да, комментарий был только об этом. Но я считаю нужным развеять неверное, оставшееся со старых времен мнение.
и первая ссылка в гугле согласна
По статистике (и у меня есть приложение с ЦА игроков) Intel/AMD так и идут 70/30 - 65/35. Тут вравне со статистикой Steam. Последние пару поколений Intel, где их AMD прижала по производительности, они должны были серьезно опустить цены в бытовом сегменте, чтобы у них была конкурентноспособная линейка. Прошедшие пару лет Intel хорошо держались за счет high-end сегмента (как и nVidia сейчас), потому что достаточно людей, которым дай "самое быстрое". В итоге в нижнем ценовом сегменте Intel и AMD поменялись. Долгое время, во время Ryzen 5000 (и конца Ryzen 3000) -- у Intel было дешевле взять средне-нижний проц. Сейчас я правда вижу очень вкусные цены по AMD у одного онлайн-магазина.
а amd - фаблесс-конторкой
Пока всё идет по тому сценарию, что Intel просирает корпоративную культуру и (эффективный) менеджмент. Они скрипя выпускали свои 10нм в свое время. А сейчас и они уперлись в economies of scale, подпирая сзади инвесторами и плохими результатами, хотят открыть свой фаб для заказов других фирм. И пока у них курс на просирание своих полимеров, потому что 15th gen уже планируют отчасти делать на TSMC. Часть -- то есть чиплеты. Говоря о чипчиках...
В 2017 г. AMD выдала свою микроархитектуру Zen, которая изначально была нацелена в первую очередь масштабирование, на серверный сегмент. То что раньше было многосокетным процессором, они решили поместить в один сокет - до четырех (в принципе независимых) чипов на одной подложке. А фундамент этой идеи было почти 100% масштабирование, кстати, технологию купили и доработали вместе с компанией, которая использовала её для склейки процов Intel Atom, делая из них серверы-блейды.
Zen 1 (Ryzen 1000), Zen+ (Ryzen 2000), Zen 2 были пошаговыми улучшениями заложенной архитектуры. А вот Zen 3 перешли к иной топологии: чип ввода/вывода (I/O die) + чипы с ядрами процессора (chiplet architecture). Именно благодаря этому масштабированию они уверенно конкурировали с Intel на протяжении Zen1-Zen2 в серверном сегменте, а начиная с Zen 3 (и соотв. кодовых названий серверных процов) и в ДЦ сегменте тоже. Потому что чиплеты - это высокий выход годного кремния, значит низкая цена / хорошая маржа. Соответственно, можно отбирать чипы более высокого качества и комбинировать их для старших линеек. Intel долго держался за свой старый техпроцесс, обновляя его под высокие частоты и конское энергопотребление. В серверном сегменте они, видимо, хорошо продавали за счет специализированных расширений (AVX-512 + дополнения, bfloat16 etc.), это не говоря о хороших связях и походах в рестораны со стороны своих продавцов (бытует мнение, что wine and dine было не последним аргументом в пользу контрактов с ними).
X3D чипы с, в принципе, L4 кэшем в легкую конкурируют в игровом сегменте с до предела разогнанных с завода камней Intel. Что там творится в серверном сегменте с ними - не знаю. Так то, обычные чипы выигрывают на голову в general compute благодаря кол-ву холодных ядер, энергопотреблению -- Total Cost of Ownership (TCO).
Поэтому успех AMD - не от геймеров. Наоборот, первое их поколение "геймерам" не зашло, хаили за низкие частоты, низкую производительность на ядро.
и первая ссылка в гугле согласна
Статистика верная, но иронично, что человек, написавший это на Statista, работал(-ает) в Intel: Thomas Alsop.
В эти "крайне мало" входят AMD Ryzen 2000, 3000, 5000 плюс 3000G Pro и 4000G Pro. Кроме того, ECC поддерживают некоторые модели Intel, в частности младшие i3 (например 9100), а так же, как будто бы, многие другие старшие модели intel, начиная с 12000 серии (но там вроде надо дорогой чипсет).
Ну и в DDR5 ECC насколько я понимаю во всех.
DDR5 подавляющее число без ECC, хотя и можно найти модели из официального списка совместимости памяти с сайта производителя материнских плат. Есть даже обсуждение на Реддите на тему успешных конфигураций с ECC. И если коротко, там в основном упоминается ASUS X670 + память Kingston KSM48E40BD8KM-32HM.
Ситуация с DDR4 ещё хуже. Эксперимент по установке серверной памяти например на не самую старую гигабайтовскую материнку B550 + AM-4 + Ryzen 5950X успеха не имел даже с последними версиями BIOS.
Конечно корректируются. Вы попросту не дождетесь ошибочного события.
Единичные ошибки очень просто обнаружить и исправить. Это можно делать прямо в динамике работы оперативной памяти.
Можно, нужно и давно делается в ecc-памяти.
Проблема только в том, что используется ecc‑память в основном в серверном оборудовании. В ПК, ноутбуках, планшетах‑телефонах по традиции продолжают экономить. Ну и в том, что SEU возможны не только в [основном объеме] памяти.
Кажется, сейчас ЕСС память для коррекции одиночных ошибок не требуется, подтягивание битов (регенерация) реализовано во всех модулях, автоматом с коррекцией одиночных сбоев.
ЕСС это уже профессиональное решение с коррекцией более сложных паттернов ошибок.
Какой бы алгоритм не применялся, в какой бы части системы он бы не был реализован, для того, чтобы распознать (а тем более - скорректировать) ошибку в хранимой информации должна присутствовать избыточность. Т.е. в случае памяти - дополнительный физический объем. Это стоит денег.
ЕСС это уже профессиональное решение с коррекцией более сложных паттернов ошибок.
Ну прям. Классический вариант - одну [ошибку в слове] исправляем, о двух и более - сигнализируем (если повезет).
Да, избыточность необходима.
Вот за эту избыточность (место для ее хранения) деньги и берут. Не важно, по старинке ли она отдельным корпусом на модуле распаяна, или как в DDR5 непосредственно на кристалле. А в потребительских устройствах деньги экономят.
Да и к тому же в потребительских устройствах 90+% памяти занято картинками с котиками и прочей устойчивой к искажениям единичных бит информацией: ну слетит один пиксель в каком-то элементе GUI, да и фиг с ним.
В ядре ОС может быть software ECC
Не может: каждое обращение к памяти не перехватишь, это слишком долго.
Да по любому где-то это отслеживается/корректируется, иначе бы периодически ПК сваливались в BSOD. Где-нибудь вычисляются CRC для блоков и стоит, например, код Рида-Соломона в режиме восстановления стертого символа - блока, как это делается в data storage.
иначе бы периодически ПК сваливались в BSOD
Так они периодически и сваливаются. Раз во много лет это тоже периодически. Кому какое дело? Перезагрузили и поехали дальше. На всем важном стоит ECC память.
Программно валидировать память вам никаких ресурсов не хватит. Так никто не делает.
Возможно, это просто диссертация.
Значит сейчас чипы памяти достаточно качественные на уровне технологии.
Там скорее не код Рида-Соломона - на него нужно довольно много дополнительной памяти - а простая перезагрузка страниц с диска. Может быть по ошибке CRC, а может быть просто периодическая. Потому что большая часть памяти, повреждение которой может привести к BSOD, занята исполняемым кодом, а он часто является просто файлом, отображенным на память, а если нет - его всё равно легко перезагрузить.
В data storage - именно они. Про оперативную память - не знаю.
В хранении данных скорость ответа не измеряется в наносекундах и IOPS - не в миллиардах.
Речь шла про длительное хранение данных в оперативной памяти. Почему компьютеры без ECC не сваливаются в BSOD с периодичностью в сутки, если работают круглосуточно без перезагрузки.
PS поздно увидел, что это ответ не на мой комментарий. При добавлении контроля целостности кода в оперативной памяти дело не в IOPS и скорости ответа, а в расходе памяти и вычислительной мощности на контроль и восстановление программными средствами.
В ECC программные средства на однобитные ошибки не задействуются в принципе уже давно, этим занимаются отдельные транзисторные цепочки (даже в L1 кэшах процессоров!). С многобитными история другая, т.к. появляется треугольник выбора "минимальное кол-во транзисторов - точность детектирования - минимальное время ответа", и коды Рида-Соломона не попадают в первый и третий критерии совсем.
С первым абсолютно согласен.
А вот по кодам Рида Соломона... не совсем. Они являются кодами с максимальным достижимым расстоянием, и точность обнаружения ошибок у них на высоте. С исправлением ошибок - проблема, но та же проблема и у кодов Хэмминга и у любых блоковых кодов. Лучше исправляют сверточные коды. А вот с режимом восстановления стертых символов у кодов Рида Соломона все очень хорошо)
По количеству транзисторов - что ж поделать, ресурс он и в Африке ресурс, особенно не с экономить. Код Рида Соломона - циклический код и описывается полиномом, экономнее уже некуда)
Я прекрасно понимаю. Однако и в flash data storage применяется тот же подход с erasure encoding. Но оперативная память - да, всё ещё быстрее.
Тоже верно... Космические лучи ограничивают потенциал компьютерных систем человечества)
В DDR5 тот ECC, о котором вы написали, только сглаживает изьяны производства кристалла.
Да, более распространены модули с коррекцией одной ошибки. Там абсолютная избыточность примерно log N, где N - длина слова в битах. Код Хэмминга) или определение локации ошибки методом деления пополам.
по традиции продолжают экономить.
Тут не столько традиция, сколько жадность intel, которые как-то сегментировали рынок для извлечения побольше прибыли. Часть этой стратегии заключалась в ограничении поддержки ECC только в серверных процессорах. Если бы не эта умышленная деталь, давно бы уже ECC распространилась во всей памяти.
не столько традиция, сколько жадность intel
Не столь давно были времена, когда контроллер памяти был интегрирован не в процессор, а в чипсет (а самих производителей чипсетов для x86 было больше двух). И что-то и тогда не наблюдалось массового применения ECC в customer сегменте. Да и не массового, откровенно говоря, тоже не вспомню. Так что сегментировал рынок интел вполне следуя уже сложившейся традиции.
И это только про x86. Всякие ARM и причий MIPS интел под себя не подмял, но опять же не наблюдается что-то ECC ни в телефонах с хромбуками, ни в soho (и даже части не совсем уж и soho) маршрутизаторах. В последних, кстати, вполне уместно было б.
Познавательная статья, спасибо!
Эта статья - напоминание каждому программисту (от ардуино до энтерпрайз-сегмента), что глюки и порча данных возможны в любой программе, даже написанной на самом безопасном языке и использующей самые математически точные алгоритмы. И это не обязательно приводит к полному отказу системы, она может какое-то время спокойно работать дальше :)
предлагаю совместить исследования и неплохой заработок.
а именно - завести много-много банковских счетов, и как только на одном из них в результате сбоя от космического излучения окажется миллион долларов - немедля их снимать и бежать в Аргентину.
не забываем плюсовать мне карму, ибо завистники и интриганы, действуя в составе банды и по предварительному сговору, опустили мне ее по самое немогу.
заранее спасибо.
Крайне сомнительно, что сценарий включает какие то частицы, я быстрей поверю в разогнанное или некачественное железо, а то и в нейлоновые чулки, правда не в курсе носят их сейчас или нет)
В конце 90х меняющийся текст в NC под DOS или сообщениях загрузчика встречался, изменение настроек всяких таймингов и режимов BIOS иногда приводило к положительному результату. DOS и Windows при этом, как правило, продолжали работать, Linux мог зависнуть, Warp ругался и вис. Причина была в совместимостях и обычных сбоях обмена по шинам из за помех по питанию и некачественрого проектирования.
Насколько я помню, с ростом высоты над уровнем моря число ошибок действительно растёт.
Но оценки вероятности сбоев, упомянутые в статье, сильно завышены по сегодняшним меркам, мы спокойно пользуемся ноутбуком и смартфоном в самолёте, да и на Марсе, считай лишённом зашиты магнитным полем и атмосферой, вертолётик с обычной консьюмерской электроникой достаточно долго и успешно летал.
Интересно, если бы радиофизик был бы радио инженером, то он стал бы охотиться за космическими частицами бороздящими корпус компьютера?
на компьютере с 4 Гб оперативной памяти есть 96% шанс переворота битов в течение трех дней.
Почему не получилось поймать ошибку? Может быть, активность космического излучения за последние два года не была высокой.
Тут еще нужно угадать, чтобы перевернулся именно тот бит, который отвечает за реквест урл в браузере, это может быть почти какой угодно адрес в 4гб.
То есть шанс в 96% делим на, ну например 4 гб и на 8 бит, получаем 0.000000003.
Теперь делим шанс, что перевернется бит именно в ту (мили)секунду, когда его вводят. Ну или хотя бы секунду. 0.000000003 / (24*60*60) = .00000000000003472222 (виндовый калькулятор,кстати уже не осилил, заюзал bc)
И это я явно не учел еще какие-то мелочи, которые легко могут добавить еще множество порядков.
что на компьютере с 4 Гб оперативной памяти есть 96% шанс переворота битов в течение трех дней
Более тщательный анализ говорит про большую разницу в разных чипах памяти.
80-96% чипов DIMM не дали ни единой ошибки за год, в то время как плохие ловили их гораздо чаще.
Хороший чип получит один-единственный случайный переворот битов за 6 лет его типичной жизни с вероятностью 1/5.
Гораздо больше вероятность его порчи (1/3 за пару лет) и перехода после этого в категорию "плохих".
Плотное накрытие Wi-Fi и всякие микроволновки через стену (была какая-то история про компьютер который выключался когда через стенку включали микроволновку) и прочие наводки GSM на слабо экранированный вывод с подгулявшим тактированием (из-за сохнущих конденсаторов) намного более вероятно поломает биты.
Я сталкивался с тем, что esp8266 периодически перелетая через границу долетали до заказчика в "невключаемом" состоянии и грешили на рентген аппараты в аэропортах, но насколько это правда - не понятно. А так, периодически даже включенные ноутбуки не крашаться проезжая через сканнер.
была какая-то история про компьютер который выключался когда через стенку включали микроволновку
Плохое электропитание, высокий входной ток микроволновки, плохой БП компа, железо компа на грани стабильности. Врядли прямо из-за наводки. У нас проводка старая, новая микроволновка пробки вышибала. Пришлось старую оставить.
Проще сверять контрольную сумму дампов оперативной памяти. И не надо какие-то сайты делать, запросы их отслеживать и т.п. выделили массив в несколько Гб и знай себе считай КС. Это намного эффективнее. Ловятся все дефекты в этой области памяти. Просто, оценив такие события, можно оценить вероятность замены в определённом байте. Можно еще положить какой-нибудь источник радиоактивного излучения, например свинцовую фольгу. Кстати, от свинцовых припоев отказались еще и потому, что в свинце присутствуют короткоживущие изотопы, которые нельзя удалить, но распад которых на контактных площадках микросхем памяти, может вызывать как раз эти сбои. Раньше, когда у микросхем выводы были удалены от кристалла и нормы топологии были большие, это не так влияло. А сейчас контактные площадки находятся непосредственно под кристаллом. И вероятность сбоя резко увеличивается.
Поясните кто эрудирован : частица реально прошибает атмосферы, крышу, стены и железный корпус компа? Ладно еще в комосе (но там и электроника соответвующая).
И после всего этого она из милионов битов прошибает именно нужный??? Я еще вроде помню теорию вероятности. Иголку в стоге сена искать - не такая уж плохая идея выходит.
Для меня пока что выглядит как дикая профанация.
А что до оригинального случая, 4096 конечно намекает, на "взрыв болотного газа в верхних слоях атмосферы". Явно где то че то програмисты учудили.
Говорят, что на высоте 10 км в 300 раз повышается вероятность bit-flip по сравнению с уровнем моря. На самолетах уже надо отслеживать сбои, а в космосе тем более. А мы тут возле поверхности: либо покупай ECC память, либо рой бункер и организуй там ЦОД).
Там же одна высокоэнергетическая частица создает каскад из частиц с постепенным уменьшением энергии каждой. И это только в атмосфере, сравнительно разреженном газе.
С ростом плотности вещества шансы взаимодействия с ним у частицы возрастают на порядки, т.е. снижение энергии одной частицы за каджую единицу расстояния возрастает скачком. И несколько жб перекрытий способно погасить очень многое, что долетело из соседней галактики )
Но даже если что и долетит в ячейку памяти, нужно, чтобы заряда захваченной частицы хватило на "перезапись" всего заряда ячейки - а это сильно больше одного электрона (хотя с возрастанием плотности записи уменьшается объем каждой ячейки и как следствие, ее заряд).
Т.е. шансы сбоев тем выше, чем более современный у вас комп)
Ну и как выше люди написали - там, где это критично - используются избыточность и алгоритмы коррекции ошибок (где-то читал, что в космосе расчеты ведут сразу 3 чипа, и значение считается верным, если у как минимум двух результат совпал).
В остальных случаях - семь бед, один резет.
Т.е. шансы сбоев тем выше, чем более современный у вас комп)
Почему-то это не так, оценки прошлых десятилетий говорят, что на системах с сотнями гигабайт ОЗУ мы должны видеть коррекции ошибок чуть ли не ежедневно, а реально на большинстве серверов этих ошибок нет годами.
Техпроцесс уменьшается - размер элементов меньше - меньше вероятность удачно попасть в нужное место.
Реально на DDR4 ECC - алерты вылетают в dmesg примерно раз в 1-2 месяца.
У меня две планки DDR4 (2х32) в домашнем сервачке, алерты были ДВА раза за чуть меньше чем три года.
и наверняка по одним и тем же адресам.
99%, что у вас «слегка сбойная» память. но с такой частотой возникновения проблемы вероятность двойной ошибки, которую ecc не сможет исправить, околонулевая, так что особого смысла в замене железа нет.
на большинстве серверов я никогда не видел ошибок ecc. на некоторых массовые ошибки (которые исчезают после замены железа).
P.S. если ошибки по разным адресам, я бы на всякий случай проверил нет ли повышенного излучения
Так, так, вот были же компы с ОЗУ на ферритовых кольцах и эл.вак.лампах - не было таких сбоев :))
Для частицы проще прошибить крышу и стены, и даже железный корпус компа, чем прошибить магнитное поле Земли. Но да, прошибают.
Особо высокоэнергетическая частица слабенького магнитного поля земли вовсе не замечает. А те что от солнца летят -- медленные (низкоэнергетичные) и у них пролететь атмосферу до земли нет никаких шансов.
Вот прям все что от солнца летит - медленное и низкоенергетичное?
Странно, зачем нужны кремы от солнца.. и вспышки на солнце вообще маркетологи придумали наверное.. И в океане недавно связь вырубили наверное из-за инопланетян
Все солнечные частицы типа протонов -- да. Медленные (относительно), низкоэнергетичные. Атмосферу вообще не прошибают, магнитным полем земли сгребаются на полюса, где и высыпаются северными (или южными) сияниями. Фотоны -- это отдельная история, те, для кого атмосфера прозрачна, задерживаются буквально тонюсеньким слоем вашей кожи, внутрь электроники в приниципе попасть не могут. Высокоэнергетические фотоны, точно так же как и остальные высокоэнергетические частицы, устраивают в атмосфере буквально ливень частиц, который может и прошибить чего.
А эти ваши вспышки на солнце в основном "покачивают" магнитное поле земли настолько, что "связь вырубили".
частица реально прошибает атмосферы, крышу, стены
... НИИ, потом фундамент, уходит в толщу Земли, попадает в подземную камеру, где и регистрируется немудрёным прибором - чаном с жидкостью, которая светится от ударов частиц.
Я в серверах почти ноль. Мне тут достался недавно один со свалки, а там RAID1 из ECC. Это перебор, или нормально? А то физически 32 гига, а на уровне операционки 16.
Начать предлагаю с таблеток от жадности :) Я правильно понимаю: хочется в два раза больше памяти за те же деньги? Я бы просто рассматривал в вопрос не как норм (это вообще то от задачи зависит), а можно ли вообще что то сделать с этим (и каких усилий это будет стоить), возможно есть какая то магическая настройка, а возможно вообще все залочено.
А если RAM память используется в режиме сжатия (компрессии)? Тогда там наверняка поверх используется CRC, которая обнаружит сбой. Возможно даже программный ECC. Как в архиваторе RAR)
Как минимум, в линуксе контрольные суммы считаются только если включена дедупликация сжатой памяти. По умолчанию - их нет.
Да, сжатую память можно и защитить программным ECC. Но это лишь частичное решение, потому что программы не могут работать со сжатой памятью напрямую, сжатая память - это та же подкачка, только не на диск а в память.
Вот тут интересное видео на эту тему:
Намедни засегфаултился компилятор пару раз. Я запустил memtester, который указал на одну и ту же сбойную ячейку для 4 тестов подряд. Перегрузился, загрузил memtest86+. Сбоя нет. Загрузил систему, запустил опять memtester - сбоя нет.
Космос?
Была точно такая же ситуация. Никакого космоса, одна ячейка то залипала, то отлипала. Пришлось планку целиком менять. Причём проработала всего около года.
Физический дефект, типа диффузии элементов на кристале. Может приходить и уходить при определённой температуре, и так просто. Короче, он к вам ещё вернётся. Можно попробовать расслабить бул тайминги.
плавающие железные проблемы бывают.
у меня на одном старом сервере то ошибки ecc выдаются по несколько раз в день, то месяцами нет ошибок.
на одну и ту же сбойную ячейку для 4 тестов подряд
Космос?
не думаю
Я так и не понял - при чем здесь вафли? 🤔 Ожидал развязку, что это всё из-за чаепития с вафлями случилось...
Если вы вручную как-то красили, то не выбирайте этот цвет, пожалуйста. Текст трудночитаем.
Классный эксперимент! Было интересно почитать)
Сколько машин под управлением Windows работало в мире в то время, когда собиралась статистика с битфлипами? Как регулярно программа обращается к серверу, чтобы сверить часы? Сама программа постоянно находится в памяти или подгружается по таймеру? А теперь посмотрите на эти же вопросы, но применительно к своей ситуации, и увидите, что подобное событие придётся ждать очень долго, и отрицательный результат опыта ещё ничего не доказывает и не опровергает. Кстати, интересный момент: при разработке программ хорошо бы закладывать необходимость регулярно обновлять в памяти (считывать заново по истечении некоторого интервала времени) не только данные, с которыми приходится работать, но и, возможно, исполняемый программный код.
https://www.google.com/amp/s/amp-blog.robertelder.org/causes-of-bit-flips-in-computer-memory/
🙃
Google AMP? Считаю централизацией и злом. https://blog.robertelder.org/causes-of-bit-flips-in-computer-memory/
Есть такой момент, я неоднократно замечал нестабильность работы техники в горах ближе к экватору, конкретно в Боливии и Непале, высота в обоих случаях 4+ км, были развернуты локальные сети со шлюзом в инет. Довольно часто вылетали ошибки из ниоткуда разного рода
Что насчёт флеш памяти? Возможно ли изменение данных, либо же на поверхности земли не будет для этого достаточной энергии?
Hidden text
Буквально на днях у сестры телефон в очередной раз запросил пароль, что она только не пробовала вводить — ничего не подошло (хотел предложить перебор по таблицам, с расчётом на то, что поменялся один бит, в итоге не делали), пришлось сбрасывать. Это при том, что он требует ввода пароля раз в какое-то время (вроде бы 72 часа, так что вариант "забыла пароль" исключен)
Хрен вы угадали. В оперативе биты дублируются и с огромной частотой постоянно перезаписываются. Вероятность двойного попадания ничтожна. Скорее всего избирательные участки были оборудованы не компьютером а устройством с микроконтроллером и с флеш памятью старого типа с сильно ограниченными количеством циклов перезаписи.
Раньше программу управления светофором микроконтроллером писали защищённой от единичных сбоев, чтоб машины не поубивались. А теперь выборы считают без проверок. Авиация и АБС одни остались
Эту статью нельзя показывать пользователям нашей компании)) у них появится подтверждение вечной проблемы "я ничего не делал компьютер сам"
https://www.pcworld.com/article/395107/what-is-ddr5.html
В ddr5 автоматом есть коррекция однократных ошибок, но только внутри памяти)
Мне вот стало интересно, много комментариев про ECC, и в целом да, оно спасет от битфлипа в памяти.
Но как быть с битфлипом, например, в кэшах процессора? Вероятность конечно меньше исходя из площади кристалла, но ведь космический луч может и промахнуться на пару сантиметров, и попасть не в RAM. :)
Как от такого защищаться? В процессорах ведь нет всяких чек-сумм для L1/2/3?
Ого, похоже что, у нас на выборах происходит атака космических частиц на компьютеры, что приводит к битовым искажениям и 146% проголосовавших)
Причины компьютерных сбоев, о которых вы даже не думали