Comments 176
Да, например с помощью сфокусированного ионного пучка (Focused Ion Beam). Только дороговато пожалуй.
Fault injection это называется. Кроме излучений - игрища с наносекундными бросками питания Или наоборот, высокоточное отслеживание потребления, чтобы распознать что выполняется на чипе.
Гораздо проще поднять температуру на несколько десятков градусов выше. Медленно поднимаем температуру и рано или поздно будет сбой.
Можно гораздо проще - есть сфокусированные лазеры. Их, кстати, используют при тестировании микросхем как дешевые имитаторы заряженных частиц.
Обычно алгоритм такой: пробуют сломать->получается->скандал->придумывают антивзламывалку. Так было, например, с генератором случайных чисел на основе источника шума в карточке: карту облучали сильным периодическим сигналом, усилитель шумелки начинал усиливать этот сигнал вместо шума, соответственно, механизм шифрования получал детерминированный сигнал в качестве исходного и взламывался.
После чего системы, причастные к деньгам стали использовать многоразличные степени защиты: генерируемый шум проверяется математически на похожесть на "настоящий", системы питания снабжены детекторами импульсных помех, даже топологически есть защита от того, чтоб в эту микросхему кто-то подключался при помощи ion beam.
Не уверен насчёт взломать, но программировать так судя по этому комиксу можно:
А датчики альфы есть на таком принципе , Чип в неэкранирующем копусе , и считать сколько единиечек выбило?
Фотокамера смартфона для этого может использоваться https://habr.com/ru/post/389569/
Гамма-кванты, электроны и мюоны (редко) отлично ловятся, да, веб-камерой ноутбука или камерой смартфона (особенно интересны "большие" пятна, хотя один раз я поймал их три за несколько часов, причем в довольно близких точках матрицы, что странно). Но альфа не пройдет сквозь оптику, нужно "аппаратное" вмешательство.
Да, и это один из простейших способов регистрации альфа-излучения. В качестве чипа берется просто диод. Есть детекторы медленных электронов на том же принципе, используются в электронных микроскопах.
Ну вот все и выяснилось, когда программа падает с ошибкой - это не у разработчиков руки из задницы, а космические лучи :))))))))
Я должен ЭТО лайкнуть :)
Вообще звучит как оправдание для Олега от мира тестировщиков :)
Сервера комплектуются памятью ECC, о которой в статье даже мельком упомянуто. Поэтому ну я бы не доверял даже официальному отчету о том, что (скорее всего, но мы точно не знаем, бла-бла-бла) вот прям так уж космический луч проголосовал сразу 4096-ю голосами за какого-то конкретного доброго и все такое прочее претендента на какой-то там престол или что там у них есть. Если один бит поменялся, то ЕСС уже покажет, что данные невалидны - тут достаточно одного бита четности - так что нужно, чтобы несколько бит поменялись в "одной ячейке", а это уже точно "воля божья".
По космические лучи и память в последнее время что-то много статей. А тут, видимо, и тестеры решили с этого профит поиметь, чтобы не отвечать лишний раз за баги )))
Это было в 2003 году
https://www.ixbt.com/mainboard/memfaq2.html#21
Тут про модули с четностью рассуждают из тех времен, когда еще пентиумы третьи бороздили просторы. Так вот там был какой-то лайфхак, когда появились т.н. модули с "логической четностью", суть которой отсутствовала от слова совсем. Но "во всех серверах того времени" были модули с контролем четности. Более того, до изобретения этой самой "логической четности" вообще вроде как не было модулей памяти без этого самого "контроля четности".
Реально, в интернетах так мало про контроль четности в исторической ретроспективе, что я даже устал искать ))) Но DDR1 на 2003-й году уже очень как была, даже DDR 2 вроде как, хотя точных дат я и не нашел (
Контроль четности я видел на военной советской технике родом из 70-80-х. А если учесть что существенная ее часть подсмотрена у IBM, то контроль четности очень стар и распространен в этих ваших айти.
В те времена без контроля четности мне кажется вообще ничего бы не завелось - слишком грубые технологии.
Как раз нет. Память малой плотности намного устойчивей – смотрите таблицы в статье. Просто тогда все делали "как надо", а не "чтобы дешевле было". На ранних PC/XT иногда возникала "parity check" с рестартом системы. Но это было примерно раз в месяц. Но кстати, здесь имеется и другое соображение – если ошибка четности возникает раз в месяц, то ошибка именно там где лежат важные данные наверное случалась раз в год. Потому что память и так полна неважными данными. А сбой раз в год, никто даже и не заметит. Все знают, что компьютеры зависают просто так и тогда их надо перезагружать. Ведь они именно так и должны работать. :)
На SIMM 30 пиновой для PC уже был контроль четности - грубо говоря память была 9-битной. Для мака память была 8-битной, т.е. контроля те было. ,т.е. это еще времена 486 и пентиумов.
Он конечно был в стандарте модулей, но в связи с ценой памяти, (как сейчас помню, прям константа была непреложная, 35$ за мегабайт лет 10 наверное, буду признателен за ссылочку на график цены ОЗУ от начала эпохи ПК до наших дней), большинство модулей для настольных ПК выпускали 8 битными. Но некоторые сервера, прям отказывались работать без памяти с четностью. Соответственно, некоторые работали. И мы не знаем, какой именно сервер хранил данные о голосовании. Собственно, кроме памяти, в сервере полно мест, в которых может произойти инвертирование бита - шины данных, регистры процессора наконец. Не уверен я и в проверке четности в кеш-памяти процессора, она там есть? Была всегда или в какой-то момент появилась?
полно мест, в которых может произойти инвертирование бита — шины данных, регистры процессора наконец.
Все эти места — намного "дубовее" ДОЗУ, там статические триггеры.
Вы так говорите, как будто статические триггеры сильно устойчивее ДОЗУ или СОЗУ. На самом деле это не так)
"Я так думаю" (С). Ибо, по нубски, что такое — какой-то конденсатор против открытых транзисторов?
Вероятно — следует перечесть Ваши предыдущие лекции.
Ибо, по нубски, что такое — какой-то конденсатор против открытых транзисторов?Конденсатор в dram против конденстора затвора транзистора в sram )
Там, конечно, все чуть сложнее на самом деле, но принципиально речь идёт ровно о том, чтобы зарядить конденсатор затвора. А открытые транзисторы, о которых идёт речь — они же близкого к минимальному размера.
Я просто заморочился несколько лет назад с этими симмами, тк они ставились еще и в синтезаторы. И большинство ПКшных модулей что мне попадались были 9битными, т.е. либо стояло 9 однобитных чипов , либо 2 4х битных и 1 однобитная.
вот например, можно посмотреть в даташитах, крайние правые чипы будут однобитные, а слева и посередине - 4х битные
Наверно тут дело еще в том что в ПК мог быть контроль четности, а мог и не быть - в целях экономии, но это не мешало клепать память с контролем.
А причём тут серверы, ошибка произошла в электронной машине для голосования, там обычные PC внутри
The Belgian electronic voting system permit some silly kind of recount. Citizen do vote on magnetic card with the help of a diskless PC equiped with a light pen and a card reader/writer. Then those card are inserted into an electronic ballot box for counting. It is assumed that it is the computer controlling that ballot box that did fail. A quotBelgian-evoting-recountquot consist in recounting the magnetic card... but of course it assume the magnetic card has not been modified and contain an accurate expresion of the voter intent. That's where the 4096 discrepency was detected, after the culprit ballot box was identified because it is forbiden by law to publish result of a single ballot box, so result are always merged by a minimum of 10.
Тема нераскрыта:
1)как часто типичный компьютер может столкнуться с данной проблемой?
2)как на это влияет толщина корпуса?
3)системы, которые для охлаждения полностью погружены в масло\воду более защищённые?
Что, если на микросхему приклеивать сверху и снизу свинцовые пластинки? Не в производстве, а в своих устройствах, критичных к целостности памяти.
Если в свинце будут радиоактивные примеси, то может стать только хуже
Изотопы свинца сами по себе являются источником ионизирующего излучения, а от них не так просто избавиться. В том числе по-этому отказались от свинцовых припоев в современной электронике. В вашей идее проще (и дешевле) использовать золото.
Но ведь всегда свинец считался хорошей защитой от радиации?
В защите от радиации материал не важен, важна масса. Чем больше масса защиты(количество атомов между источником радиации и мишенью) тем больше вероятность что излучение поглотиться каким-либо атомом. Поэтому материал не важен, хоть воздух, хоть пенопласт, хоть бетон.
Свинец удобен только при том что у него высокая удельная масса (защита получается компактнее).
Количество атомов и масса это несколько разные вещи.
Сравните свинец с водородом.
Ок, уточню: чем больше количество нуклонов - тем лучше
хм... масса на единицу объёма это плотность.
а какой параметр характеризует количество нуклонов на единицу объёма?
понятно что можно пересчитать из средней массы нуклона и плотности, но есть такой отдельный параметр? чтоб его загуглить и вообще посмотреть насколько сильно материалы отличаются?
Ну чем больше нуклонов - тем выше атомный вес, он указан в таблице Менделеева. Соответственно надо брать таблицу Менделеева и справочник плотности и выбирать оптимальный материал (спойлер: это будет свинец, достаточно компактный и дешевый)
Но я о другом писал - что гасить излучение можно любым материалом, главное набрать достаточную массу, т.е. килограмм свинца защитит от радиации также как килограмм пенопласта. Нас например вообще хорошо атмосфера защищает, хотя она состоит не из свинца, а из воздуха.
килограмм свинца защитит от радиации также как килограмм пенопласта.
У меня не получилось нагуглить, по быстрому, но вроде не так. И в комментах что-то про протоны пишут.
Килограмм свинца даст осколки, которые вызовут вторичную радиацию. В комментариях к этой статье https://habr.com/ru/news/t/512760/ обсуждалось.
Ну дык любой материал даст осколки при должном потоке нейтронов/протонов, свинец тут не исключение. Все останавливающее действие любого материала - то что условно говоря нейтрон наткнется на ядро атома и застрянет в нем, превратив его в менее стабильный изотоп (соответственно чем больше атомов между источником и целью - тем лучше защита). Ну и понятно что эти изотопы потом начнут распадаться - что и будет вторичной радиацией.
но можно выбрать материал со стабильными изотопами. Водород к примеру.
Ну во первых у водорода тоже есть и дейтерий и тритий, во вторых как сделать защиту из водорода, его и так сложно хранить, даже без всяких затей вроде защиты.
1)чтоб из водорода тритий сделать это он аж 2 нейтрона сожрал. А дейтерий стабилен.
2)Еслиб его было легко хранить, то вопросов из чего делать защиту бы небыло. Можно к примеру хранить в виде оксида. Или метана. Метан конечно тоже охлаждать надо, на маск вроде справляется.
вода отличный (но не наилучший) экран с точки зрения качества и наилучший с точки зрения цена/качество.
Если же мы рассматриваем применение для космоса, и нам нужно снизить вес, то вода не лучшая с точки зрения соотношения экранирование/вес
Про растворение тяжёлых металлов не слышал, что-то не верится в эффективность метода.
Есть книга "Коротеев А.С. и др. Пилотируемая экспедиция на Марс (2006)" (например на NNM). На странице 289 написано, что экипаж будет защищаться запасами воды, топлива и т.д. - т.е. емкости, запасы продовольствия, оборудование размещаются так, чтобы заслонять экипаж от мощных солнечных вспышек.
Это очевидно. Но солнце не единственный источник радиации. Есть мнение, что этой защиты может не хватить, тогда возникает вопрос: что тащить именно для защиты от радиации?
вариантов 2:
1)вещество с макс защитой от радиации по отношению к весу (с учётом систем хранения этого вещества)
2)взять больше топлива, чтобы сократить время полёта (+ будет больше топлива для торможения, значит и для защиты)
Молярная плотность.
Но в вашем случае легче загуглить молярный объем и отсортировать материалы по возрастанию.
Рассматривая соударения как упругие — получим, что для протонов и нейтронов — наилучшая экранировка обеспечивается протонами (водой, предельными углеводородами). На каждом соударении с веществом экрана — рассеивается половина энергии.
Тяжёлые ионы (ТЗЧ) производят большие эффекты, но их интенсивность — мала.
КМК.
Протонами в смысле ядрами водорода, или в смысле при равном весе нам нужно максимальное отношение протонов к нейтронам?
Протонами в смысле ядрами водорода
Да.
или в смысле при равном весе нам нужно максимальное отношение протонов к нейтронам?
Не понял.
КМК — диаметры атомов довольно мало изменяются при увеличении атомного веса. Поскольку все нуклоны — в маленьком ядре, то шанс протону или нейтрону столкнуться с протоном экранирующего вещества должен быть выше у лёгких веществ.
По экранировке — надо поискать и перечесть посты amartology.
Предположу, что речь о разных уровнях излучения.
Свинец - хорошая защита от мощного кратковременного излучения, но сам является источником слабого постоянного.
Так то и бананы интенсивно испускают радиоактивные частицы, просто уровень очень невысокий.
Фееричная неправда.
На практике тяжелые металлы не применяют в защите микросхем от космического излучения.
Очень редко бывают частицы с экстремальной энергией 50 Дж (на 1 частицу!). Полный эффект этой энергии был бы эквивалентен одномоментному получению примерно 77 рентген на объект в 65 кг (или 0,77 грей). То есть гипотетически, 1 такая частица могла бы (в благоприятных условиях для конверсии своей энергии) нанести заметный урон здоровью космонавта, вплоть до лучевой болезни. В реальности такое обычно пролетает насквозь, оставляя гораздо меньшую дозу.
Судя по тому, что чем выше(меньше слой атмосферы) тем больше радиация, данный эффект недостаточно силён для земных условий.
Зачем тогда свинцовые фартуки в рентген-кабинетах?
1 такая частица могла бы (в благоприятных условиях для конверсии своей энергии)
что-то мне кажется, что свинцовой пластины не хватит, чтобы «поймать» такую частицу, слишком велика её кинетическая энергия.
Единственный прилетевший протон высоких энергий, вместо того чтобы инвертировать один бит, а скорее всего просто пролететь мимо полупроводникового перехода, вызовет лавину вторичных менее энергетических частиц и массированный сбой. В общем, клейте свинцовые радиаторы на память врагов!
Читал, что в космических изделиях чипы памяти располагают неким оптимальным образом относительно друг друга, минимизируя вероятность одновременного сбоя.
1)как часто типичный компьютер может столкнуться с данной проблемой?
На компьютере с серверной материнкой работающем почти 24/7 видел в логах биоса 1 ошибку ECC за пару лет работы. Не знаю в какой момент они туда попадают, но если всегда при работе то вот.
ECC на памяти в 512Гб дает одну ошибку каждый месяц.Зависит как бы от общего обьема RAM.
Еще некоторые сервера умеют дублировать вычисления на втором сокете.
Ну и сам сокет как минимум закрыт алюминиевой пластиной радиатора и со всех сторон еще куча корпусов и конструкций.
Памяти там в 32 раз меньше, так что все сходиться.
ECC на памяти в 512Гб дает одну ошибку каждый месяц
На 32Гб серверах hetzner один раз в год. Оно не особо то линейно.
как раз достаточно линейно получается.
а что вы на этих серверах делаете?
я уже писал, с одиночными ошибками памяти практически не сталкивался, массовые были, лечились заменой памяти или сервера.
но число ошибок зависит от активности работы с памятью (контрольная сумма проверяется же при чтении памяти), есть подозрение, что я просто недостаточно нагружаю свои сервера )
В основном куча мелких тупых запросов к базам данным в пол террабайта.
На всех серверах в памяти, в осномном, будет кэш.
На самом деле нелинейно. На серверах до 16Гб вообще все работает без ECC, проблемы начинаются где-то как раз с 32.
И проблемы сильно растут с ростом обьемом ОЗУ/кешей.
ну у меня тоже есть машины с 128-256-384 гигами памяти, не много, но больше десятка точно, многим уже не так мало лет.
и там тоже есть базы данных. ну вот чистые логи ошибок, хоть ты тресни )
если брать последние лет пять и актуальное железо, то ошибки ecc встречал только на одной машине на ryzen у хетцера, пожаловался, поменяли, ошибки продолжились, пожаловался ещё раз, поменяли, ошибки пропали.
при этом да, встречал несколько отзывов о массовости единичных ошибок памяти, нет оснований им не верить, но не согласуется с моим опытом.
Некоторые материнки показывают только в SEL лог, тоесть для просмотра надо перегрузиться и посмотреть в БИОС.
Я знаю, поскольку у меня кластера master-slave и в списке операций стоит просмотр того лога…
Единичные ошибки это норма, для них собственно ECC и придумано.
Некоторые материнки показывают только в SEL лог, тоесть для просмотра надо перегрузиться и посмотреть в БИОС.
так они не только в лог bmc пишутся, можно ещё через edac-util смотреть, да и в dmesg, помнится, при наличии ошибок были сообщения.
root@test:~# uptime
00:44:43 up 370 days, 5:05, 2 users, load average: 28,59, 20,28, 18,61
root@test:~# free -h
total used free shared buff/cache available
Mem: 187Gi 85Gi 6,5Gi 29Mi 95Gi 100Gi
Swap: 0B 0B 0B
root@test:~# edac-util -v
mc0: 0 Uncorrected Errors with no DIMM info
mc0: 0 Corrected Errors with no DIMM info
mc1: 0 Uncorrected Errors with no DIMM info
mc1: 0 Corrected Errors with no DIMM info
mc2: 0 Uncorrected Errors with no DIMM info
mc2: 0 Corrected Errors with no DIMM info
mc3: 0 Uncorrected Errors with no DIMM info
mc3: 0 Corrected Errors with no DIMM info
edac-util: No errors to report.и таких серверов у меня есть. а с единичными ошибками нет.
Космические лучи?
Скорее батч обработка, например внесение в систему обработанной (вручную посчитанной) почты.
sarcasm_for_sheldon.jpg
:)
У республиканцев там тоже рывок симметричной формы, просто меньше.
И до этого есть совпадающие рывки.
Это может быть подключение другого штата или сельских / городских регионов с другим соцдемом.
Но конечно и вбросы могут быть, в том числе через ту же почту.
Кто ж их знает, что у них там
Как объясняется тот факт, что только демократы голосуют по почте? :)
Так, что демократы специально просили своих сторонников голосовать по почте, а Трамп специально просил своих сторонников этого не делать.
Кажется, в реальность воплотилась ещё одна идея из 1990-х - "меньше транзистор делать нельзя - его будут переключать пролетающие мимо ...-частицы" :)
Глядишь придёт время и начнут не ускорять процессоры, а оптимизировать софт.
С синхронным исполнением, к слову, уже всякие блокчейны есть, правда там обычно какая-нибудь своя виртуальная машина со своим языком и пачкой ограничений, в том числе такими что процесс внутри поддерживаться не может и только сценарная логика, как в старых PHP, кстати, а крона там встроенного нет, оракулы - не то. Но глядишь и любой код начнет поддерживаться. Я, к слову, даже стартовал такой проект, но притормозил - не знаю нужно ли миру p2p облако, с запуском JS скриптов, для начала, p2p доменами, статикой и прочим всяким, но не знаю - не будет ли как пятая нога собаке, однако некоторое время и ресурс в это вложил.
а про большой компьютер я серьезно, не где то в облаке а по одному на многоквартирный дом, сотни человек пользуются одной большой машиной, эффективно расходуя энергию… для клиентов бесшумные удобные (например беспроводные включая подачу энергии) терминалы
да подобная схема не применима в современном мире, где человек человеку волк, и большие дяди спят и видят как сделать гадость большинству, но помечтать то можно? С другой стороны предприятиям такая схема идеальна (ее и используют — rdp, но современное лицензирование и цены сводят все бонусы ее использования на нет)
Как раз когда-то я на таком работал - большой офис разработки, у всех тонкие клиенты с rdp до серверной стойки в одной из комнат на этаже. Что-то в этом есть, но сложно рассуждать о плюсах-минусах, почти 10 лет прошло, возможно иначе всё сейчас, но нынче в моде раздать ноутбуки, как минимум там где наблюдаю сам.
мне нравится реализация от ibik aster (то же самое заводится нативно на linux — multiseat) когда в сервер пихается по максимуму мониторов клавиатур и мышек, длинные кабели (hdmi 20-30 метров легко и есть на сотни метров правда дорого) и usb трансиверы по ethernet — доступно уже сейчас, есть ряд неудобств исключительно программного характера, например при использовании рабочего места win не серверной ревизии, все пользователи получают доступ к флешкам, в linux так же по умолчанию, или сложности с настройкой звуковых карт, доступ в интернет с разных ip и прочее прочее, но все решаемо, и конечно лицензионные ограничения, если софт не желает работать в многопользовательском окружении то селяви.
ну и конечно перезагрузка, много ситуаций, когда машину все же нужно перезагружать, и это затрагивает сразу всех пользователей
я пробовал, когда второе рабочее место (linux multiseat) запускает windows в виртуалке, и сидит в фулскрине, глупо но работает
При подсчёте результатов голосования в брюссельском муниципалитете Schaerbeek произошёл странный инцидент.
В мае 2003 года а не 2013 как можно сделать вывод из абзаца выше.
Пожалуй, проведу эксперимент: запишу на microSD файлы, запущу в небо на воздушном шарике на 10..20 км, а после полёта (1...4 часа) сравню файлы. Кто желает помочь сгенерировать файл мегабайт на 100 из одних единичек? Как располагать флешку?
Ну флешку горизонтально к небу, дабы площадь возможного контакта была больше, под углом то частицы часть энергии потеряют, с горизонтальным вероятность должна выходить выше. И хотя эксперимент из разряда буханки хлеба и троллейбуса, всё равно любопытно что получится.
На высоте 20 км начинают возникать дополнительные факторы - https://habr.com/ru/post/379345/ .
Так та статья утверждает, что при снижении температуры надежность хранения флэшки возрастает....
В статье говорится о рисках связанных с повышением температуры в пределах допустимого диапазона температур.
Экстремально низкие температуры там не рассматриваются, за исключением фразы:
>Для дисков достаточно промежутка между −40° и 70°, а для SSD может потребоваться контролируемая температура — к примеру, твердотельник недопустимо забывать на несколько дней в автомобиле на солнце.
Так что, учитывая физику процесса и размер ячеек, экстремально низкие температуры могут повлиять.
Я знаю только один способ узнать что выйдет. Постараюсь до конца недели запустить.
Сделайте один контрольный образец,в металлическом футляре.
Это уменьшит влияние лучей и будет рассматриваться как влияние исключительно холода.
помочь сгенерировать файл мегабайт на 100 из одних единичек?
Ctrl-C / Ctrl-V :)
А если серьезно, не надо из одних единичек. Намедни знакомые принесли битую карту памяти из телефона с просьбой восстановить фото-видеофайлы. Так вот, часть битых файлов была заполнена кодом 0xFF. Лучше возьмите, к примеру, старую утилиту h2testw, она как раз для проверки подойдет.
Да, действительно, лучше чтоб и единички, и нолики были. Тем более, что физически ноль это наличие заряда, т.е. пролетающая частица из ноля сделает единицу.
Всё сложнее. В рамках flash памяти действительно вполне можно попасть в саму ячейку, а вот в случае с DRAM можно так же с большим успехом попасть в затвор транзистора и 1 превратится в 0. У меня есть ещё предположение, что в flash величина заряда должна быть на порядок больше, чем у DRAM памяти, но быстро цифры не нагуглились.
Тем более, что физически ноль это наличие заряда, т.е. пролетающая частица из ноля сделает единицу.
Пролетающие частицы в разных типах памяти вполне умеют делать нули из единиц. Например, в SRAM, где ячейка симметричная.
помочь сгенерировать файл мегабайт на 100 из одних единичек?
$ dd if=/dev/urandom of=~/file100mb bs=1024 count=100К сожалению, для меня это просто набор символов. Если есть возможность, скиньте пожалуйста ссылки на готовые файлы из единичек, и из ноликов
Если кому интересно будет, сделал так, именно с нулями и еденицами.
$ shuf -i 0-1 -r -n 104857600 | tr -d '\n' > ~/100mbbs в байтах - у вас 100кб получилось
$ dd if=/dev/urandom of=~/file100mb bs=1M count=100Почему 100мб, а не на всю емкость SD?
Для чистоты эксперимента надо 10 карт на земле и 10 поднять высоту и через недельку (а лучше через полгода) сравнить и данные усреднить
Лучше не из одних единичек, а некоторый паттерн
например 01010101
Забить все байтовыми 85
Вот вам питончик, скопировать в файл и запустить
Там где 1024*1024 - указать размер, например 512*1024*1024 - файл на 512 МБ
file_size = 1024*1024
symbol = int('01010101', 2) # 85 code 'U' symbol
with open('test_file.txt', 'w') as f:
for s in range(file_size):
f.write(chr(symbol))
print("done")
UPD: жизнь сложилась так, что флэшка потерялась улетев не пойми куда.
Подождите, а как же старый-добрый контроль четности и "контрольный разряд" в регистре? Разве он не предназначен как раз и защищать от сбоя в один бит?
Доклад от А. Миловидова про баг, причиной которого являлись битфлипы в контроллере сетевой карты и совпадающей при этом контрольной сумме.
Он может помочь, но их ведь используют в процессах, где шум подразумевается (типа сети и дисков), но внутренняя среда компьютера считается надежной.
К тому же даже самые продвинутые системы не защищают 100 процентов (хотя конечно радикально снижают шанс)
IBM в SystemZ лечит проблему тем, что 1) кроме ECC есть ещё и RAIM из памяти, 2) есть режим для процессора повторять каждую команду дважды и сравнивать результаты. Цена за это, кроме цены самой техники — более медленная работа (out-of-order исполнения по факту очень мало).
Похоже, автор сейчас офлайн, и не может оперативно поправить публикацию. Поэтому напишу сюда, хотя об опечатках обычно лучше сообщать через механизм ЛС.
потому что лайнеры поднимаются в верхние слои атмосферы, где защита магнитного поля Земли намного слабее.
Тут ошибка, по-моему
Магнитосфера находится много выше атмосферы. Поэтому даже в полярных широтах подъем вверх на 10км от поверхности очень слабо влияет на
защитный эффект магнитного поля
Разумеется, в полярных широтах этот защитный эффект слабее, чем в низких. Но мы-то сравниваем не низкие широты с высокими, а защитный эффект магнитного поля на разных высотах в одной и той же географической точке...
А вот толщина атмосферы над самолетом на земле и в полете меняется в разы (точнее, в 2- 3 раза). И вот как раз ее защитный эффект ослабевает пропорционально уменьшению массы атмосферы над самолетом.
Частота компьютерных сбоев резко возрастает при увеличении высоты над уровнем моря, за пределами гелиосферы.
Может быть, все-таки имелась в виду атмосфера? Или хотя бы магнитосфера?
Гелиосфера — это от ГЕЛИОС, т.е. Солнце. Это зона, где солнечный ветер и связанное с ним магнитное поле преобладают над магнитным полем межзвездной среды. Для выхода за пределы гелиосферы надо очень сильно подняться над уровнем моря - на много астрономических единиц. Насколько я знаю, пока что такой опыт имеется только у Вояджеров. А вот за пределами магнитосферы уже побывало множество космических аппаратов, и там уже накоплена определенная статистика по подобным сбоям.
Похоже, автор сейчас офлайн, и не может оперативно поправить публикацию Поэтому напишу сюда
А если сюда напишете, то 1) автор сразу станет онлайн или 2) сможет оперативно поправить публикацию?
А если сюда напишете, то 1) автор сразу станет онлайн или 2) сможет оперативно поправить публикацию?
Если я напишу сюда, то это поможет читателю узнать, что по некоторым затронутым в публикации вопросам существует альтернативная точка зрения. Да, ему для этого придется прочитать комментарии - это менее удобно, чем если бы в публикации изначально не было опечаток. Но все-таки лучше, чем если такая опечатка останется непрокоментированной.
Хотя Вы наверно правы, что мои извинения за выбранный формат исправления опечаток сформулированы
чересчур витьевато :-(
Автору я сперва отправил ЛС, - понадеялся, что он сразу ответит. Но оперативного ответа не получил, а статью-то читают. Поэтому вот так :-((( Извините за косноязычие :-(((
136,5(3) битфлипов на 1 ТБ в день
то есть 10 ошибок в день на 128 гб озу?
Как ловить непойманные неизвестно, но шанс на них на порядок меньше
Это больше похоже на правду, т.к. если я сейчас запущу мемтест, то и близко не получу значений, упомянутых в статьею
E3-1535M V5 наше всё.
Эта проблема так же стара, как и интегральные схемы, но внимания ей уделяется по-прежнему мало. Сбой может произойти как в мощной серверной машине, так и в микроконтроллере, стоящем в промышленном или медицинском оборудовании. Проблема в том, что система обычно не крашится сразу, а продолжает спокойно работать до какого-то момента. Одно дело, если испортятся числовые данные, и совсем другое - порча указателя или программного кода, тогда программа может совершить непредсказуемые действия.
Интересно, есть ли в современных ОС контроль целостности данных (ядра, драйверов, прикладного ПО)? И насколько он эффективен?
На первый взгляд кажется, что многозадачные системы имеют неплохую защиту от ошибок на уровне межпроцессного интерфейса. Любой системный вызов с недопустимыми параметрами сразу же вызовет ошибку. Доступ к недопустимому адресу памяти будет заблокирован контроллером памяти. Для Java-приложений множество проверок обеспечивает JVM - на выход за границы массива, на валидность указателей и т.д. Это всё хорошо, а кто-нибудь предусмотрел ситуацию, что баг может случиться в самой JVM? Например, из-за кривого указателя изменилось количество объектов в куче, и как на это отреагирует сборщик мусора - промолчит или выдаст исключение?
Наверно, разработчики ОС и прикладного софта должны вводить больше явных проверок в свой код. Ошибку лучше выявить своевременно, особенно во встраиваемых системах. В ответственных участках кода стоит проверять не только аргументы функций, но и результаты вычислений, индексы массивов, указатели стека (в разумных пределах). Желательно использовать вычислительно устойчивые алгоритмы, для которых малое изменение входных данных мало влияет на результат.
Писать код, который подразумевает, что КАЖДАЯ операция может стать любой другой — практически невозможная задача. Дубликация делает sync через определенные промежутки.
аже в космических аппарата ставят три процессора(а надо три, чтоб знать какое решение правильное) в паралель только на аппаратах дальнего космоса.
Это неправда. Бортовые компьютеры с двумя полукомплектами по три чипа в каждом - это норма и в "ближнем" космосе. И еще активно применяются чипы с внутренним резервированием, где не три чипа, а три ядра на чипе делают одну и ту же работу.
Прикладные программы это усложнит и замедлит, а профит минимальный. К тому же едва ли возможно полностью, а в таком случае смысла ещё меньше.
Не хватает упоминания о сверхмощных космических частицах - Частица Oh-My-God
Интересно, а нейтрино когда-нибудь были причиной подобных сбоев? Ведь каждую секунду каждый см^2 земли пересекает более чем 10^10 этих частиц. Они, конечно, практически не взаимодействуют с веществом, тем не менее периодически детектируются специальными устройствами.
Клавиатуры в банкоматах умирают сразу по нескольку штук в регионе с сообщением зафиксировано вскрытие. Видимо микросхемы защиты криптомодуля ловят частицы.
В общем-то, это обычный наброс с целью привлечь внимание и развлечь. Никаких конкретных данных о статистике явления не показано, кроме указания на то, что Mozilla каждый день собирает со своих пользователей 100 ТБ какой-то полезной мозилле информации, из которой кто-то в мозилле каким-то непонятным образом вычислил некую цифирь.
То, что мозилла за нами следит, это интересно, но память с коррекцией ошибок сегодня очень распространена, поэтому закатывать глаза и делать грустное лицо совершенно нет необходимости. Ну а у кого память без ECC, тому оно и так не надо, потому что глючность обычного хомячкового софта на много порядков больше, нежели могут при всём своём желании выдать космические лучи.
Проблема в том, что космическая частица может поразить любой бит память, включая критические компоненты ядра, пользовательские баги не имеют доступа к ядру.
Для конечного пользователя любой вариант будет выглядеть как "неправильное" поведение программы, включая такое поведение, о котором пользователь только думает, что оно неправильное, а на самом деле так было задумано.
Теперь прикиньте количество таких неправильных варинтов. И сравните с количеством частиц, целенаправленно развлекающихся с вашим ядром линукс.
Ну как это нет? Есть данные на начало 80-х.
Другое дело, что память на CCD (шта-а-а?) не взлетела. А динамическая КМОП память, при использовании "low alpha mold", — достаточно надёжна в "быту". И, при минимальной ECC, — "в проде".
Есть данные на начало 80-х.
Перечисленные в статье эксперименты (не из 80-х) проводились по разным методикам на разном железе. Например, изучали влияние радиоактивных корпусов на их внутренности, или летали на самолёте и считали некие события, которые интерпретировали как "нападение космических лучей".
Всё это к тому, что само явление, видимо существует, но каких-то серьёзных статистических данных по его воздействию на современное железо не приведено. Экстраполировать же эксперименты с самолётами в облаках на сегодняшние реалии с кардинально отличающимися плотностями упаковки микросхем, которые чаще всего находятся не в самолётах, есть занятие не совсем обоснованное.
Принципиально тестирование не выглядит сложным, если есть в наличии источник с близкими характеристиками частиц. Почему его не провести на современной базе? Хотя по возможности генерации частиц соответствующей энергии я не в курсе.
Когда моя программа аварийно завершается, я действую в следующем порядке. Вначале предполагаю, что это космическая частица влетела в микросхему и что-то там сделала. Если же программа падает снова и снова, то, видимо, микропроцессор содержит аппаратную ошибку. Если тщательное тестирование микропроцессора ничего не выявило, то, возможно, дефект оперативной памяти. После этого моё подозрение падает на компилятор — скорее всего, он забагованный. Потом надо проверить операционную систему. Если к этому моменту меня ещё не уволили, то после проверки операционной системы можно и в исходный код программы заглянуть.
Выпуск Veritasium про это с похожими примерами – https://www.youtube.com/watch?v=AaZ_RSt0KP8.
Благодврю за статью.
Теперь у конспирологов есть научное обоснование почему они носят шапочки из фольги :)
Статья полезна, как сборник ссылок по теме.
Собственных идей 0.
Когда тестирование бессильно. Космические лучи меняют биты памяти чаще, чем принято думать