Что происходит при гамма-излучении?
Reality check: если с вероятностью 1/100000, то у тебя будет десять ошибок на мегабайт и всё упадёт.
В этом и вопрос - действительно ли десять ошибок на мегабайт приведут к падению?
Да.
При тестировании памяти под виндой (обычно тестируют сразу значительные объёмы: 16-256мб) появление уже нескольких ошибок (этому очень далеко до нескольких ошибок на мб.) обычно сопутствует крайне нестабильной работе всей системы. Потому, что программа для тестирования памяти нагружает её так, что вероятность проявления ошибок максимизируется.
При тестировании памяти под виндой (обычно тестируют сразу значительные объёмы: 16-256мб) появление уже нескольких ошибок (этому очень далеко до нескольких ошибок на мб.) обычно сопутствует крайне нестабильной работе всей системы. Потому, что программа для тестирования памяти нагружает её так, что вероятность проявления ошибок максимизируется.
появление уже нескольких ошибок (этому очень далеко до нескольких ошибок на мб.) обычно сопутствует крайне нестабильной работе всей системы.Вроде как, несколько ошибок при тестировании памяти - это обычно несколько областей в памяти, которые совсем нерабочие (т.е. не один раз один бит испортился, а всегда портится большой кусок)?
Вроде как, несколько ошибок при тестировании памяти - это обычно несколько областей в памяти, которые совсем нерабочие (т.е. не один раз один бит испортился, а всегда портится большой кусок)?вовсе не обязательно, есть понятие точечных ошибок.
И ещё раз повторяю, ошибки могут воспроизводиться только во время тестирования (или интенсивных расчётов а при обычной работе не замечаться.
Вопрос в том, что будет происходить при условной переадресации и балансе скажем 0.50р, когда денег на входящий\исходящий звонок в роуминге недостаточноТак ты ответь на вопрос - эти ошибки не будут замечаться, или всё-таки работа системы будет очень нестабильной?
Возьми источник гамма-излучения да проверь.
или всё-таки работа системы будет очень нестабильной?конечно, будет нестабильной, т.к. при этом будут пороться указатели, а чтения по невалидным указателям или запись по не тем указателям фатальны для программы.
конечно, будет нестабильной, т.к. при этом будут пороться указателиКак мне кажется, в памяти сами данные занимают на порядки больше места, чем адреса этих данных. Так что не факт, что будут пороться.
В памяти по большей части лежат не данные, а код.
Большие массивы даныых в памяти по-долгу не хранятся имхо.
Большие массивы даныых в памяти по-долгу не хранятся имхо.
Подозреваю, что критичный для работы винды код, к которому идут частые обращения, занимает всяко более мегабайта. Думаю что процент случаев в которых сбой бита приведёт к неконтролируемому сбою в выполнении кода достаточен для того, чтобы система быстро упала.
Большие массивы даныых в памяти по-долгу не хранятся имхо.И чем же, по-твоему, ИЕ сейчас занял 200МБ моей памяти?
Подозреваю, что критичный для работы винды код, к которому идут частые обращения, занимает всяко более мегабайта.Да.
Только непонятно, в каком количестве случаев изменение одного бита в этом "более мегабайта" приведёт к чему-то критичному.
>И ещё раз повторяю, ошибки могут воспроизводиться только во время тестирования (или интенсивных расчётов а при обычной работе не замечаться.
И наоборот
И наоборот
И чем же, по-твоему, ИЕ сейчас занял 200МБ моей памяти?HTML-ным dom-ом, а это фактически в памяти сидят указатели чуть ли не на каждый символ.
ps
jpg - опять указатели на каждый "кластер"
avi - еще больше ссылок (ключевые кадры, изменения и т.д.)
бд - тоже сплошные ссылки.
что еще объемное бывает?
Только непонятно, в каком количестве случаев изменение одного бита в этом "более мегабайта" приведёт к чему-то критичному.Изменение адреса перехода в коде нулевого кольца - это скорее всего bsod. Изменение команды - как повезёт, но в большинстве случаев произойдёт экскалация ошибок, в итоге - тоже bsod. Если, конечно, ошибка попадёт на неиспользуемые байты между функциями, то ничего не произойдёт, но процент таких мест невелик.
Да, bsod в данном случае я рассматриваю как лучший выход: будет весело, если какой-то системный вызов будет переадресовываться на запись случайной информации в случайный сектор на диске.
Ты неправ.
Программа вылетает, если испортился указатель, указывающий на место нахождения данных в оперативной памяти (да и то только тогда, когда она попытается по этому указателю пройти). Если это - адрес данных в файле, ничего настолько критичного не будет.
А если есть указатель (который занимает каких-то четыре байта) - то есть и данные; и, судя по тому, что потребление программами памяти увеличивается при переходе с 32битной на 64битную архитектуру совсем не в два раза, этих данных - гораздо больше, чем указателей.
Тот же ИЕ - я не замечаю практически никакой разницы в его потреблении на ноуте с 32битной вистой и на десктопе с 64битным ws2008. Если эта разница укладывается в 10% - то, значит, указатели занимают как раз эти 10% от общего объёма памяти; кроме того, программа вылетит не сразу, а только при попытке пройти по этому указателю; и ещё один важный момент - далеко не каждая порча указателя приведёт к такому результату (например, если испортился указатель на pascal-style строку, то, в общем-то, практически никто ничего и не заметит).
Программа вылетает, если испортился указатель, указывающий на место нахождения данных в оперативной памяти (да и то только тогда, когда она попытается по этому указателю пройти). Если это - адрес данных в файле, ничего настолько критичного не будет.
А если есть указатель (который занимает каких-то четыре байта) - то есть и данные; и, судя по тому, что потребление программами памяти увеличивается при переходе с 32битной на 64битную архитектуру совсем не в два раза, этих данных - гораздо больше, чем указателей.
Тот же ИЕ - я не замечаю практически никакой разницы в его потреблении на ноуте с 32битной вистой и на десктопе с 64битным ws2008. Если эта разница укладывается в 10% - то, значит, указатели занимают как раз эти 10% от общего объёма памяти; кроме того, программа вылетит не сразу, а только при попытке пройти по этому указателю; и ещё один важный момент - далеко не каждая порча указателя приведёт к такому результату (например, если испортился указатель на pascal-style строку, то, в общем-то, практически никто ничего и не заметит).
Да, bsod в данном случае я рассматриваю как лучший выходЯ поэтому и интересуюсь - интересно, если в памяти вдруг перемешаются биты, не расчитанная на это домашняя ос упадёт, или будет делать хуйню, или особо этого и не почувствует.
Ты неправ.если бы...
если бы я был бы не прав, то проги хотя бы не валились бы от битых файлов: картинок, avi-шек, флэшек, звука и т.д.
сейчас уже основные декодирующие либы вылизаны на такого рода ошибки, но это за 20 лет...
а ты предлагаешь портить даже не данные, а указатели, и в памяти, а не на винте, да на это вообще ни один код не рассчитан.
интересно, если в памяти вдруг перемешаются биты, не расчитанная на это домашняя ос упадёт, или будет делать хуйню, или особо этого и не почувствует.и первое и второе и третье, четкого ответа быть не может.
а ты предлагаешь портить даже не данные, а указателиЕщё раз - я предлагаю портить рандомные биты, а в памяти данные занимают на порядок (или на несколько) больше места, чем указатели.
то проги хотя бы не валились бы от битых файлов: картинок, avi-шек, флэшек, звука и т.дНасчёт звука - не сталкивался с таким.
Насчёт авишек - ну так обычно "битые авишки" - это недокачанные, а это гораздо серьёзнее, чем изменение нескольких бит.
Получим комп с женcкой логикой вместо математической. 
Один чел примерно так ломал код помнится, прописал по всей памяти безусловные переходы на свой код, запустил искомую прогу, положил в печку, стал греть потихоньку повышая температуру, получил что хотел - управление перешло к его коду.
В подобных ситуациях специальное железо применяется имхо и код к нему. Целые числа (указатели например, можно представлять остатками от деления на 2, 3, 5,...,p_n. При высокой радиации снижаем диапазон представления чисел - много "разрядов" уходит на исправление ошибок, при нормальных условиях разрядность повышается. Ещё свинец вокруг небось и т.д. Честно говоря давно не интересовался.
Но что на обычном компе проблемы будут - очевидно. Это дело так и открыли американцы, когда чуть война с СССР не началась. Сначала сбоят компы от высокоэнергетических космических частиц, потом они самолёты на взлёт, наши в ответ свои, они в ответ шахты например открывают, наши это видят со спутников - открывают свои. И т.д. система с положительной обратной связью. Потом сообщение ТАСС в центральных газетах на первой полосе внизу мелкая заметочка - вчера СССР 11 минут находился в состоянии ядерной войны с США. Я видел лично. Впечатляет.
Может быть часть проблем в разных сложных системах этим тоже объясняется, а не только китайскими/арабскими и т.д. хакерами, повалившими энергосеть например.
Один чел примерно так ломал код помнится, прописал по всей памяти безусловные переходы на свой код, запустил искомую прогу, положил в печку, стал греть потихоньку повышая температуру, получил что хотел - управление перешло к его коду.
В подобных ситуациях специальное железо применяется имхо и код к нему. Целые числа (указатели например, можно представлять остатками от деления на 2, 3, 5,...,p_n. При высокой радиации снижаем диапазон представления чисел - много "разрядов" уходит на исправление ошибок, при нормальных условиях разрядность повышается. Ещё свинец вокруг небось и т.д. Честно говоря давно не интересовался.
Но что на обычном компе проблемы будут - очевидно. Это дело так и открыли американцы, когда чуть война с СССР не началась. Сначала сбоят компы от высокоэнергетических космических частиц, потом они самолёты на взлёт, наши в ответ свои, они в ответ шахты например открывают, наши это видят со спутников - открывают свои. И т.д. система с положительной обратной связью. Потом сообщение ТАСС в центральных газетах на первой полосе внизу мелкая заметочка - вчера СССР 11 минут находился в состоянии ядерной войны с США. Я видел лично. Впечатляет.
Может быть часть проблем в разных сложных системах этим тоже объясняется, а не только китайскими/арабскими и т.д. хакерами, повалившими энергосеть например.
что такое адрес данных в файле?
Где у тебя уверенность, что 32битный IE не употребляет 64битные (или даже больше) указатели? под "указателями" понимаются не конструкции "void *p". это либо индексы в известных массивах, либо те же индексы, но "многоуровневые", с префиксами и т.п. Видел не один проект, где "указатели" имели вид гуидов.
Где у тебя уверенность, что 32битный IE не употребляет 64битные (или даже больше) указатели? под "указателями" понимаются не конструкции "void *p". это либо индексы в известных массивах, либо те же индексы, но "многоуровневые", с префиксами и т.п. Видел не один проект, где "указатели" имели вид гуидов.
что произойдёт?
Запусти винду в VMWare или VirtualBox, поставь на паузу и в образе ВМ на диске внеси битовые изменения с заданной вероятностью, после чего запусти дальше. Потом нам расскажешь.
скорректируется ECC
если в памяти обычного домашнего компьютера с обычными домашними ОС и софтом каждый бит с вероятностью, например, 1/100000 заменится на противоположный - что произойдёт?
хм, а я вот подумал про SoftICE. мне кажется если менять образ на диске можно случайно порушить структуру файла образа и упадет не винда в коробке, а сама виртуальная машина. лучше из под SoftICE поменять несколько случайных бит в памяти и посмотреть что будет.
скорректируется ECCДавно ли в домашних компах стали память с ECC ставить?
хм, а я вот подумал про SoftICE. мне кажется если менять образ на диске можно случайно порушить структуру файла образа и упадет не винда в коробке, а сама виртуальная машина. лучше из под SoftICE поменять несколько случайных бит в памяти и посмотреть что будет.будет меняться не образ диска, а образ оперативки. Подозреваю, что он не перемешан со служебной информацией виртуальной машины. Как вариант - захибернейтить реальный комп, загрузиться с live CD и подправить hiberfill.sys
Как вариант с ноутом в активную зону АЭС и рассказать об ощущениях или на ФФ поставить в какой-нить лаборатории под излучение
во-первых, при оценке вероятности попадания в работу битой памяти нужно учитывать, что хорошо написанные программы проводят где-то 80% работы в 10% кода.
при этом важно знать, что происходит с кэшем. если кэш не знает о том, что происходит с памятью, а при этом с ним ничего не происходит, то также это уменьшит вероятность падений.
при этом важно знать, что происходит с кэшем. если кэш не знает о том, что происходит с памятью, а при этом с ним ничего не происходит, то также это уменьшит вероятность падений.
при этом важно знать, что происходит с кэшем. если кэш не знает о том, что происходит с памятью, а при этом с ним ничего не происходит, то также это уменьшит вероятность падений.ага, а вокруг процессора у пенартура толстый свинцовый кожух
и отбитые пальцы ног, потому что как-то у свинцовых трусов лопнула резинка
я один не понял при чом тут гамма-излучение ?
см. соседний тред
Ну, в космосе применяют память не из кремния, а из каких-то других материалов, которые сильно дороже, но гораздо устойчивее к воздействию внешних факторов - от банального нагрева до космического излучения.
под "указателями" понимаются не конструкции "void *p".Тогда и сегфолтам неоткуда взяться.
скорректируется ECCПростой домашний комп, с простой ддр2 памятью (которая ещё не так давно стоила по 800р за два гига). Какой ECC?
В подобных ситуациях специальное железо применяется имхо и код к немуЭто-то и так понятно.
Интересно было, что произойдёт с обычным железом и софтом, на такое не рассчитанными.
нужно учитывать, что хорошо написанные программы проводят где-то 80% работы в 10% кода.Ага, и это тоже.
при этом важно знать, что происходит с кэшем. если кэш не знает о том, что происходит с памятью, а при этом с ним ничего не происходит, то также это уменьшит вероятность падений.Для простоты можно считать, что кэш процессора абсолютно жёстко связан с памятью (или что его вообще нет)
Возьми первую попавшуюся прогу и начни прям у неё в образе флипать биты. Довольно интересное приближение должно получиться.
О результатах доложи.
(когда-то кто-то рассказывал, что программы гораздо устойчивей в этом смысле, чем можно было бы подумать).
О результатах доложи.
(когда-то кто-то рассказывал, что программы гораздо устойчивей в этом смысле, чем можно было бы подумать).
от архитектуры кстати многое зависит, на x86 всё может достаточно долго непредсказуемо работать, на x86_64 сегфолт случится значительно раньше, а PowerPC ещё раньше приедет bus-error из-за не выровненных адресов.
на x86 всё может достаточно долго непредсказуемо работать, на x86_64 сегфолт случится значительно раньшеЭто почему ещё? Потому что указатели вдвое больше места занимают?
дырок в памяти, в которые легко навернуться, на порядки больше, если конечно твоя любимая виста не нашла чем засрать 16 эксабайт.
дырок в памяти, в которые легко навернуться, на порядки больше,А, понял - то есть, при порче указателя (которая сама по себе в два раза более вероятна) сильно повышается вероятность того, что этот указатель будет указывать на несуществующую память?
А почему ты решил, что при попадании на "нормальный код" не произойдёт наворачивания с высокой вероятностью?
кода сильно меньше чем данных — размеры программ растут линейно, а память экспоненциально
Человек, который введёт andex.ru адресную строкувводил "yandex.ru", но вмешалось гамма-излучение?
Короче, кому интересно поэкспериментировать - прога . Только там от трети до половины адресов не могут или прочитаться или записаться и судя по моим экспериментам, большая часть этих адресов попадает на память типа MEM_IMAGE. По сему, имхо, если бы рандом был честный, падения бы участились.
зы: хз, мб. если подгрузить дллку в память процесса, то модифицировать можно будет больше адресов, но что-то я не очень в этом уверен.
ззы: всё-таки лучше поэкспериментировать с виртуальной машиной.
зы: хз, мб. если подгрузить дллку в память процесса, то модифицировать можно будет больше адресов, но что-то я не очень в этом уверен.
ззы: всё-таки лучше поэкспериментировать с виртуальной машиной.
Ну, в космосе применяют память не из кремния, а из каких-то других материалов, которые сильно дороже, но гораздо устойчивее к воздействию внешних факторов - от банального нагрева до космического излучения.сколько же предрассудков у наших граждан, имеющих очень отдаленное отношение к космосу и радиации... хочешь, приглашу в нашу лабу и покажу ту электронику, что в космос летает, летала и будет летать?
Так опиши, интересно же.
зафотай
Ломает.
Большая часть электроники - продукция нашей фирмы http://www.fractal.com.ru/
Большая часть электроники - продукция нашей фирмы http://www.fractal.com.ru/
После прочтения соседних тредов стало интересно - если в памяти обычного домашнего компьютера с обычными домашними ОС и софтом каждый бит с вероятностью, например, 1/100000 заменится на противоположный - что произойдёт? Человек, который введёт andex.ru адресную строку, попадёт на google.com - или упадёт вся системаВесь тред не осилил, не знаю, сказа ли тут или нет.
При изменении 1 любого бита всё накроется раком — ошибка четности будет.
Каждый байт состоит физически из 9 бит: 8 несут информацию, девятый — контроль на четность. Как только контрольная сумма лажает, срабатывает пиздец общесистемный.
Пеонизд, тут говорят не про ядерные установки с охуенным контролем чётности. Тут говорят про простые десктопные компы, в которых стоит простая десктопная память без всяких там ЕСС.
>Because soft errors are extremely common in the DRAM of computers used in satellites and space probes, such memory is structured as ECC memory (also called "EDAC protected memory"). Typically every bit of memory is refreshed at least 15 times per second. During this memory refresh, the memory controller reads each word of memory and writes the (corrected) word back. Such memory controllers traditionally use a Hamming code, although some use triple modular redundancy. Even though a single cosmic ray can upset many physically neighboring bits in a DRAM, such memory systems are designed so that neighboring bits belong to different words, so such single event upsets (SEUs) cause only a single error in any particular word, and so can be corrected by a single-bit error correcting code. As long as no more than a single bit in any particular word is hit by an error between refreshes, such a memory system presents the illusion of an error-free memory
http://en.wikipedia.org/wiki/Dynamic_random_access_memory#Er...
http://en.wikipedia.org/wiki/Dynamic_random_access_memory#Er...
Ещё один писатель?
Меня не интересует, как всё работает в спецкомпьютерах для космоса и для аэс. Меня интересует, что будет, если облучить обычную память, без такой защиты.
Меня не интересует, как всё работает в спецкомпьютерах для космоса и для аэс. Меня интересует, что будет, если облучить обычную память, без такой защиты.
Меня не интересует, как всё работает в спецкомпьютерах для космоса и для аэс. Меня интересует, что будет, если облучить обычную память, без такой защиты.чо будет, чо будет...
зависит от того, где сбой будет
в занятой памяти, в незанятой, в коде, в данных
пути винды неисповедимы
это если не учитывать возможное наличие ЕСС
это если не учитывать возможное наличие ЕССЕщё раз.
В той нонейм DDR2 PC2-6400 2GB, которая стоит в моём компьютере, никакой возможности наличия ECC нет.
зависит от того, где сбой будетА говорят, ты кандидат наук...
в занятой памяти, в незанятой, в коде, в данных
Если сбой - один, то да, можно думать, куда он попадёт.
А если сбоев двадцать тысяч на всех двух гигабайтах памяти - то с очень большой степенью уверенности можно сказать, что вот в эти конкретные десять мегабайт попало около ста сбоев. И тут уже ничего от случая не зависит, и надо думать о статистике.
Если сбой - один, то да, можно думать, куда он попадёт.В микросхемах памяти на 1 Мб в страшном и ужасном Космасе (борт МКС, 350 км) сбои происходят даже не на каждом витке, даже в Аномалии. Могу привести ссылки.
А если сбоев двадцать тысяч на всех двух гигабайтах памяти - то с очень большой степенью уверенности можно сказать, что вот в эти конкретные десять мегабайт попало около ста сбоев. И тут уже ничего от случая не зависит, и надо думать о статистике.
А еще подумай о защите физической. 1 мм алюминия защитит тебя от протонов с энергией где-то на десяток МэВ, а электронов где-то до МэВа.
Для глюков, сидящих в танке.
Здесь мы рассматриваем обычный домашний компьютер с обычным домашним железом, у которого в памяти рандомно изменили 1/100000 бит.
Здесь мы рассматриваем обычный домашний компьютер с обычным домашним железом, у которого в памяти рандомно изменили 1/100000 бит.
Вот тебе расчеты частоты сбоев в секунду на орбите МКС для одной из микросхем IBM 1 Гб. Защита в г/см2 - произведение плотности вещества на ее толщину. Максимальная частота сбоев что-то типа 0.5 сбоев в секунду при самой минимальной защите 0.01 г/см2.
От ГКЛ - галактических космических лучей:
Start year (from begining of solar cycle) =1 year
Flight time=1 year(s)
Solar cycle number - even
Solar cycle - mean
Apogee = 426 km.
Perigee = 426 km.
Inclination =51.6 deg.
Argument of perigee = 0.0 deg.
GCR PARTICLE SEE RATE (orbital maximum) behind shielding
Thin sensitive volume
Bit = 1.00E+0009
cross section = 1.04E-0008cm^2
LET thresshold =2.2MeV/(mg/cm^2)
1 col. - Shielding thickness [g/cm2]
2 col. - proton SEE rate [1/s]
3 col. - ion SEE rate[1/s]
4 col. - sum SEE rate[1/s]
1.00E-0002 2.26E-0006 1.51E-0005 1.73E-0005
3.16E-0002 2.26E-0006 1.49E-0005 1.71E-0005
1.00E-0001 2.26E-0006 1.50E-0005 1.72E-0005
3.16E-0001 2.26E-0006 1.51E-0005 1.73E-0005
1.00E+0000 2.43E-0006 1.47E-0005 1.71E-0005
3.00E+0000 2.71E-0006 1.33E-0005 1.60E-0005
1.00E+0001 3.63E-0006 8.89E-0006 1.25E-0005
3.16E+0001 5.02E-0006 2.42E-0006 7.43E-0006
1.00E+0002 6.15E-0006 4.26E-0008 6.19E-0006
от протонов РПЗ - радиационных поясов Земли
Start year (from begining of solar cycle) =1 year
Flight time=1 year(s)
Activity of solar cycle - mean
Apogee = 426 km.
Perigee = 426 km.
Inclination =51.6 deg.
Argument of perigee = 0.0 deg.
RB PROTON SEE RATE (orbital maximum) behind shielding
Thin sensitive volume
Bit = 1.00E+0009
cross section = 1.04E-0008cm^2
LET thresshold =2.2MeV/(mg/cm^2)
1 col. - Shielding thickness [g/cm2]
2 col. - SEE rate [1/s]
1.00E-0002 6.19E-0005
3.16E-0002 6.11E-0005
1.00E-0001 5.92E-0005
3.16E-0001 5.55E-0005
1.00E+0000 5.15E-0005
3.00E+0000 4.11E-0005
1.00E+0001 2.36E-0005
3.16E+0001 7.26E-0006
1.00E+0002 4.67E-0007
от протонов СКЛ - солнечных космических лучей
start=1 year
Flight time=1 year(s)
Probability= 0.01
Solar cecle - mean
Apogee = 426 km.
Perigee = 426 km.
Inclination =51.6 deg.
Argument of perigee = 0.0 deg.
SEP SEE RATE (orbital maximum) behind shielding
Thin sensitive volume
Bit = 1.00E+0009
cross section = 1.04E-0008cm^2
LET thresshold =2.2MeV/(mg/cm^2)
1 col. - Shielding thickness [g/cm2]
2 col. - proton SEE rate [1/s]
3 col. - ion SEE rate[1/s]
4 col. - sum SEE rate[1/s]
1.00E-0002 1.01E-0004 5.21E-0001 5.21E-0001
3.16E-0002 9.92E-0005 1.33E-0001 1.33E-0001
1.00E-0001 9.40E-0005 2.43E-0002 2.44E-0002
3.16E-0001 8.17E-0005 3.22E-0003 3.30E-0003
1.00E+0000 6.09E-0005 3.74E-0004 4.35E-0004
3.00E+0000 3.81E-0005 4.10E-0005 7.91E-0005
1.00E+0001 1.81E-0005 2.66E-0006 2.08E-0005
3.16E+0001 6.48E-0006 8.33E-0008 6.56E-0006
1.00E+0002 1.67E-0006 5.62E-0010 1.67E-0006
От ГКЛ - галактических космических лучей:
Start year (from begining of solar cycle) =1 year
Flight time=1 year(s)
Solar cycle number - even
Solar cycle - mean
Apogee = 426 km.
Perigee = 426 km.
Inclination =51.6 deg.
Argument of perigee = 0.0 deg.
GCR PARTICLE SEE RATE (orbital maximum) behind shielding
Thin sensitive volume
Bit = 1.00E+0009
cross section = 1.04E-0008cm^2
LET thresshold =2.2MeV/(mg/cm^2)
1 col. - Shielding thickness [g/cm2]
2 col. - proton SEE rate [1/s]
3 col. - ion SEE rate[1/s]
4 col. - sum SEE rate[1/s]
1.00E-0002 2.26E-0006 1.51E-0005 1.73E-0005
3.16E-0002 2.26E-0006 1.49E-0005 1.71E-0005
1.00E-0001 2.26E-0006 1.50E-0005 1.72E-0005
3.16E-0001 2.26E-0006 1.51E-0005 1.73E-0005
1.00E+0000 2.43E-0006 1.47E-0005 1.71E-0005
3.00E+0000 2.71E-0006 1.33E-0005 1.60E-0005
1.00E+0001 3.63E-0006 8.89E-0006 1.25E-0005
3.16E+0001 5.02E-0006 2.42E-0006 7.43E-0006
1.00E+0002 6.15E-0006 4.26E-0008 6.19E-0006
от протонов РПЗ - радиационных поясов Земли
Start year (from begining of solar cycle) =1 year
Flight time=1 year(s)
Activity of solar cycle - mean
Apogee = 426 km.
Perigee = 426 km.
Inclination =51.6 deg.
Argument of perigee = 0.0 deg.
RB PROTON SEE RATE (orbital maximum) behind shielding
Thin sensitive volume
Bit = 1.00E+0009
cross section = 1.04E-0008cm^2
LET thresshold =2.2MeV/(mg/cm^2)
1 col. - Shielding thickness [g/cm2]
2 col. - SEE rate [1/s]
1.00E-0002 6.19E-0005
3.16E-0002 6.11E-0005
1.00E-0001 5.92E-0005
3.16E-0001 5.55E-0005
1.00E+0000 5.15E-0005
3.00E+0000 4.11E-0005
1.00E+0001 2.36E-0005
3.16E+0001 7.26E-0006
1.00E+0002 4.67E-0007
от протонов СКЛ - солнечных космических лучей
start=1 year
Flight time=1 year(s)
Probability= 0.01
Solar cecle - mean
Apogee = 426 km.
Perigee = 426 km.
Inclination =51.6 deg.
Argument of perigee = 0.0 deg.
SEP SEE RATE (orbital maximum) behind shielding
Thin sensitive volume
Bit = 1.00E+0009
cross section = 1.04E-0008cm^2
LET thresshold =2.2MeV/(mg/cm^2)
1 col. - Shielding thickness [g/cm2]
2 col. - proton SEE rate [1/s]
3 col. - ion SEE rate[1/s]
4 col. - sum SEE rate[1/s]
1.00E-0002 1.01E-0004 5.21E-0001 5.21E-0001
3.16E-0002 9.92E-0005 1.33E-0001 1.33E-0001
1.00E-0001 9.40E-0005 2.43E-0002 2.44E-0002
3.16E-0001 8.17E-0005 3.22E-0003 3.30E-0003
1.00E+0000 6.09E-0005 3.74E-0004 4.35E-0004
3.00E+0000 3.81E-0005 4.10E-0005 7.91E-0005
1.00E+0001 1.81E-0005 2.66E-0006 2.08E-0005
3.16E+0001 6.48E-0006 8.33E-0008 6.56E-0006
1.00E+0002 1.67E-0006 5.62E-0010 1.67E-0006
Не флуди, пожалуйста.
Здесь мы рассматриваем обычный домашний компьютер с обычным домашним железом, у которого в памяти рандомно изменили 1/100000 бит.Ну и рассматривайте. Я сферических коней в вакууме не люблю. Знаете ли, не мой конек.
Не флуди, пожалуйста.Прочитай пожалуйста мой пост с расчетами сбоев подробно, может поймешь, что твои рассуждения не могут иметь приложения.
Не флуди, пожалуйста.кстати, гамма-кванты сбоев почти не производят, слишком мала у них линейная передача энергии по сравнению с протонами и ядрами, так что не надо тут тыкать
Я сферических коней в вакууме не люблюЗаметь, это ты стал рассуждать о защищённой памяти в космосе в вакууме.
Твои рассуждения не имеют никакого отношения к теме треда.
Заметь, это ты стал рассуждать о защищённой памяти в космосе в вакууме.Пенартур — это пиздец.
Твои рассуждения не имеют никакого отношения к теме треда.
Здесь мы рассматриваем обычный домашний компьютер с обычным домашним железом, у которого в памяти рандомно изменили 1/100000 бит.Ну и рассматривай. Гамма-излучение тут при чем?
ну так пенартур-то фонит...
Гамма-излучение тут при чем?Можешь считать, что ни при чём.
Такой заголовок был выбран после прочтения соседних (на тот момент) тредов.
В таком случае ответ на твой вопрос следует искать в архиве раздела H&S, в тредах, где слезно просят помощи в усмирении глюков компов (перезагрузки, синие экраны, etc).
Никакого отношения к данному разделу тема не имеет и близко. Это всё равно, что предложить в метро перепутать случайным образом названия всех станций, после чего теоритезировать на этой почве "а как будет народ по такой схеме передвигаться".
Никакого отношения к данному разделу тема не имеет и близко. Это всё равно, что предложить в метро перепутать случайным образом названия всех станций, после чего теоритезировать на этой почве "а как будет народ по такой схеме передвигаться".
таком случае ответ на твой вопрос следует искать в архиве раздела H&S, в тредах, где слезно просят помощи в усмирении глюков компов (перезагрузки, синие экраны, etc).Как мне кажется, те случаи (когда всегда портятся биты, записанные в какую-то конкретную, довольно большую область памяти) не имеют никакого отношения к рассматриваемому (когда один раз поменяли какое-то количество случайных битов на противоположные).
Никакого отношения к данному разделу тема не имеет и близкоА норвежские биты - имеют?
Как мне кажется, те случаи (когда всегда портятся биты, записанные в какую-то конкретную, довольно большую область памяти)Многовато на себя берешь. Сбои памяти, знаешь ли, разные бывают.
когда всегда портятся биты, записанные в какую-то конкретную, довольно большую область памяти
когда один раз поменяли какое-то количество случайных битов на противоположныеэти два случая совершенно идентичны, т.к. есть, например, interleaving. Разница между ними лишь в адресах ячеек и эти адреса, очевидно, на результаты влиять не могут (плашку можно же и в другой слот вставить)
Что же касается "один/не один раз". Ты можешь сколь угодно долго писать в сбоящие области памяти и не будешь ничего замечать до тех самых пор, как первый раз попытаешься прочитать записанное. Сбой случайного характера покажет себя в том же случае - при первом чтении.
Ты можешь сколь угодно долго писать в сбоящие области памяти и не будешь ничего замечать до тех самых пор, как первый раз попытаешься прочитать записанноеНо и после этого - необязательно, что я что-нибудь замечу.
Да, равно как и в случае случайного изменения некоторых битов.
Но случайные биты один раз изменили - и всё. Если кто-то потом ещё чего-то в них запишет - данные уже будут верными.
А сбойный участок не обязан всегда данные портить, если что.
Говорю же, много на себя берешь.
Говорю же, много на себя берешь.
почитай вот тут http://www.cl.cam.ac.uk/~sps32/
в этой статье есть немного, про то, что будет если биты поменять (где-то ближе к концу про залочку микросхемы )
http://www.cl.cam.ac.uk/~sps32/optofault_rus.pdf
в этой статье есть немного, про то, что будет если биты поменять (где-то ближе к концу про залочку микросхемы )
http://www.cl.cam.ac.uk/~sps32/optofault_rus.pdf
Оставить комментарий
kruzer25
После прочтения соседних тредов стало интересно - если в памяти обычного домашнего компьютера с обычными домашними ОС и софтом каждый бит с вероятностью, например, 1/100000 заменится на противоположный - что произойдёт? Человек, который введёт andex.ru адресную строку, попадёт на google.com - или упадёт вся система?