Комментарии 104
Да, например с помощью сфокусированного ионного пучка (Focused Ion Beam). Только дороговато пожалуй.
Fault injection это называется. Кроме излучений - игрища с наносекундными бросками питания Или наоборот, высокоточное отслеживание потребления, чтобы распознать что выполняется на чипе.
Гораздо проще поднять температуру на несколько десятков градусов выше. Медленно поднимаем температуру и рано или поздно будет сбой.
Не уверен насчёт взломать, но программировать так судя по этому комиксу можно:
А датчики альфы есть на таком принципе , Чип в неэкранирующем копусе , и считать сколько единиечек выбило?
Фотокамера смартфона для этого может использоваться 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 битными. Но некоторые сервера, прям отказывались работать без памяти с четностью. Соответственно, некоторые работали. И мы не знаем, какой именно сервер хранил данные о голосовании. Собственно, кроме памяти, в сервере полно мест, в которых может произойти инвертирование бита - шины данных, регистры процессора наконец. Не уверен я и в проверке четности в кеш-памяти процессора, она там есть? Была всегда или в какой-то момент появилась?
А причём тут серверы, ошибка произошла в электронной машине для голосования, там обычные 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)системы, которые для охлаждения полностью погружены в масло\воду более защищённые?
Что, если на микросхему приклеивать сверху и снизу свинцовые пластинки? Не в производстве, а в своих устройствах, критичных к целостности памяти.
Если в свинце будут радиоактивные примеси, то может стать только хуже
Изотопы свинца сами по себе являются источником ионизирующего излучения, а от них не так просто избавиться. В том числе по-этому отказались от свинцовых припоев в современной электронике. В вашей идее проще (и дешевле) использовать золото.
Но ведь всегда свинец считался хорошей защитой от радиации?
В защите от радиации материал не важен, важна масса. Чем больше масса защиты(количество атомов между источником радиации и мишенью) тем больше вероятность что излучение поглотиться каким-либо атомом. Поэтому материал не важен, хоть воздух, хоть пенопласт, хоть бетон.
Свинец удобен только при том что у него высокая удельная масса (защита получается компактнее).
Предположу, что речь о разных уровнях излучения.
Свинец - хорошая защита от мощного кратковременного излучения, но сам является источником слабого постоянного.
Так то и бананы интенсивно испускают радиоактивные частицы, просто уровень очень невысокий.
Фееричная неправда.
На практике тяжелые металлы не применяют в защите микросхем от космического излучения.
Очень редко бывают частицы с экстремальной энергией 50 Дж (на 1 частицу!). Полный эффект этой энергии был бы эквивалентен одномоментному получению примерно 77 рентген на объект в 65 кг (или 0,77 грей). То есть гипотетически, 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.и таких серверов у меня есть. а с единичными ошибками нет.
Космические лучи?
Кажется, в реальность воплотилась ещё одна идея из 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 памяти, но быстро цифры не нагуглились.
помочь сгенерировать файл мегабайт на 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")
Подождите, а как же старый-добрый контроль четности и "контрольный разряд" в регистре? Разве он не предназначен как раз и защищать от сбоя в один бит?
Доклад от А. Миловидова про баг, причиной которого являлись битфлипы в контроллере сетевой карты и совпадающей при этом контрольной сумме.
Он может помочь, но их ведь используют в процессах, где шум подразумевается (типа сети и дисков), но внутренняя среда компьютера считается надежной.
К тому же даже самые продвинутые системы не защищают 100 процентов (хотя конечно радикально снижают шанс)
Похоже, автор сейчас офлайн, и не может оперативно поправить публикацию. Поэтому напишу сюда, хотя об опечатках обычно лучше сообщать через механизм ЛС.
потому что лайнеры поднимаются в верхние слои атмосферы, где защита магнитного поля Земли намного слабее.
Тут ошибка, по-моему
Магнитосфера находится много выше атмосферы. Поэтому даже в полярных широтах подъем вверх на 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 этих частиц. Они, конечно, практически не взаимодействуют с веществом, тем не менее периодически детектируются специальными устройствами.
Клавиатуры в банкоматах умирают сразу по нескольку штук в регионе с сообщением зафиксировано вскрытие. Видимо микросхемы защиты криптомодуля ловят частицы.
Когда тестирование бессильно. Космические лучи меняют биты памяти чаще, чем принято думать