А вот битая память, например

В ашане продают оперативу? о.О

рекомендую оперативу из пятерочки

По скидосу на сдачу с покупки пива Старый Евнух 53 р за сиську.

Может ли компьютер работать на оперативе из ашана, испозьлуя избыточное кодирование?

если сделаешь такой процессор, то может, осталось понять, накой это надо. особенно если можно сразу взять готовую память с ecc и соответствующий проц

Дополнительные баллы получит объяснивший, почему спутники и марсоходы постоянно имеют проблемы из-за сбоев флеша/рам, если всё так просто решается.

перекладывание проблем с одного чипа на другой ничего не решает, CPU тоже не на святом духе работает

почему спутники и марсоходы постоянно имеют проблемы из-за сбоев флеша/рам, если всё так просто решается.

р-а-д-и-а-ц-и-я

Может ли компьютер работать на оперативе из ашана, испозьлуя избыточное кодирование

Когда-нибудь ECC будет обязательным даже на памяти из address sanitizer'а

Может ли компьютер работать на оперативе из ашана

Если это не специфичная экзотика, чипы не били молотком, они не жарят сами себя от короткого замыкания и это действительно чипы памяти в нашем классическом понимании, то повышение напряжения и сброс таймингов даст больше шансов на положительный результат, чем весь вот этот геммор, который ты предлагаешь. Ах, да ECC ужа давно придумали.

Дополнительные баллы получит объяснивший, почему спутники и марсоходы постоянно имеют проблемы из-за сбоев флеша/рам, если всё так просто решается.

Потому что высокоэнергетическое космическое излучение и солнечный ветер (в быту, просто радиация) в тупую разрушают материалы. В частности, ЭМИ от подрыва ядерного оружия вызывает пробой в полупроводниках.

Может ли компьютер работать на оперативе из ашана, испозьлуя избыточное кодирование?

Программно - нет, не может. Процессор оперирует байтами получаемыми из оперативной памяти. Любую программу реализующую это самое избыточное кодирование - процессору все равно придется где-то хранить, и это «где-то» будет в оперативной памяти из ашана.

ECC работает прозрачно для процессора (хотя и с уведомлением) и основано на банальном контроле четности для слов, хранящемся в дополнительных банках. ЕМНИП оно даже не всегда исправляет, а скорее уведомляет о вероятной ошибке в машинном слове.

От большинства случайных одномоментных сбоев оно спасает, если сбой не затронул какую-нибудь критическую область, например ту же область кода обрабатывающего ошибки, или код ядра операционной системы. От массивных систематичных сбоев, когда кроме сбоя непосредственно данных, сбиваются и ячейки в доп. банках - нет.

Дополнительные баллы получит объяснивший, почему спутники и марсоходы постоянно имеют проблемы из-за сбоев флеша/рам, если всё так просто решается.

Ну почему - тебе должны были рассказать еще в школе. Зеленые человечки пакостят же =)

А решается оно ни разу не просто, а очень даже стандартными банальными мерами - рад. защитой, сознательным жертвованием производительности в угоду техпроцессу (чем больше площадь кристалла, тем сложнее зеленому человечку попасть из бластера в ячейку), дублированием, и его разновидностью - голосованием, а так же периодическими велосипедами наподобие такого - https://ibb.co/g4gfVvG (слабо посчитать сколько тута гигобайтов?).

В общем если вкратце, то вся сложность этих кодирований заключается в том, что кодирование тоже нужно кодировать.

рекомендую оперативу из пятерочки

Правильно пишется «аперитивы».

Господа, а мы кажется помогаем кузькину мать собирать

Может. И в целом работает. Но это увеличивает задержки обращения к памяти и не все ошибки возможно скорректировать.

Ну будет в панику валиться иногда, подумаешь - пнул его ногой по ресету и дальше поехал.

«аперитивы» - это «что». «оперативу» - «кому»

Любую программу реализующую это самое избыточное кодирование - процессору все равно придется где-то хранить

ECC работает прозрачно для процессора (хотя и с уведомлением) и основано на

Не находишь что эти два соседних предложения противоречат друг другу? Какие принципиальные препятствия аппаратно реализовать в контроллере памяти коррекцию ошибок?

Не находишь что эти два соседних предложения противоречат друг другу? Какие принципиальные препятствия аппаратно реализовать в контроллере памяти коррекцию ошибок?

Давай сперва определимся, какую коррекцию ошибок мы хотим видеть. Ту коррекцию, без которой у тебя съедут пять пикселей на фотке котика? Или ту коррекцию, без которой у тебя над городом жахнет пару мегатонн?

У тебя в памяти есть массив блоков по 64 ячейки. ECC устроена так, что к каждому блоку добавляется одна ячейка, бит хранящий признак четности этого блока. Если у тебя по какой-то причине ячейка меняет состояние и четность перестает совпадать - алгоритм может определить корректное состояние этих 64 ячеек и его вернуть. Если же состояние меняет более одной ячейки - двоичный алгоритм уже не может восстановить исходное состояние, и может лишь сказать что блок содержит ошибку.

Упрощенно говоря, в данном случае идет булевое (в итоге) сравнение содержимого 64 ячеек с 1 контрольной ячейкой и при несовпадении - алерт алерт.

Вот только такое же несовпадение произойдет и в том случае, если высокоэнергетический квант выбъет контрольную ячейку. В данном случае блок тоже пометится как ошибочный. Это плохо, но терпимо.

А вот нетерпимее будет, когда прилетят два высокоэнергетических кванта в разные банки, и так совпадет что один из них перебьет состояние какой-нибудь ячейки в блоке данных (наших 64 ячейках), а второй из них в это же время перебьет наш контрольный бит с четного на нечетный, или наоборот. К чему это приведет - зависит от того, в каком блоке программы это сбойнет, и за что она отвечает. Если это вывод jpeg то на твоем котике кусок рыжей шерстинки превратится в черный, образно говоря. Если это программа предупреждения о ядерном нападении типа if (red_alert==true) {send_rockets_to_ussr();} и вместо false вернется true - то нутыпонел.

И тут ты сейчас такой думаешь, а не ввести ли нам еще контрольные ячейки? Ведь это очевидно.

Ввести можно. Можно даже ввести 1 к 1, т.е. 64 контрольных бита на 64 бита данных. Но к сожалению, помимо необходимости добавлять еще банки памяти и их адресацию, каждое обращение к одной ячейке требует один такт контроллера, а обработка такой ошибки потребует ресурсов в геометрической прогрессии, ведь как я уже писал, пострадать могут не только ячейки данных, но и ячейки контрольные.

Посему производители железа и те кто использует железо, посчитали нецелесообразным увеличивать качество коррекции ошибок ценой снижения скорости, ведь память - не единственное что может пострадать от внешних излучений, и в таком случае проще дублировать весь комплекс, чем припаивать память к памяти.

Какие принципиальные препятствия аппаратно реализовать в контроллере памяти коррекцию ошибок?

Поэтому тезисно:

а) Уязвимость не только блока данных, но и блока коррекции данных;

б) Увеличение требований к вычислительным ресурсам либо снижение производительности;

в) Как следствие увеличение энергопотребления и цены;

г) Архитектурные ограничения. Существующий алгоритм коррекции способен восстанавливать целостность БИНАРНЫХ данных, при том с ограничением не более одного бита на шестьдесят четыре. Другие решения потребуют не математический алгоритм, а программный, который как я писал раньше - придется где-то хранить.

Такие дела.

Всё ещё не вижу ни одного комментария, заслуживающего ответа, но всё же. Речь идёт не об обнаружении сбоя и не об убогой ECC, а о полноценной коррекции с многократным оверхедом. И, опять же, речь идёт о чисто софтовой процедуре, на уровне ОС, выполняющей преобразования обращений к памяти и расположенной исключительно на внутренних буферах процессора, без использования внешней памяти для собственных нужд. Обрабатывать ситуацию сбоя внутри процессора в контексте задачи избыточно, нельзя уберечься ото всего.

Вопрос в основном касается использования широко доступных компонентов в жёстких условиях, примером тому может быть марсианский вертолётик. Разрабатывать специализированный SoC под него не посчитали нужным, но модификация ОС не выглядит чем-то невыполнимым, учитывая невысокие требования к вычислительной мощности.

Боже мой, да сделай тройную или пятерную избыточность и мажорирование ответа от каждого чипа памяти и будет у тебя за тот же такт все отрабатывать

о полноценной коррекции с многократным оверхедом

Ранговый код © гарантирует коррекцию, если ранг ошибки не выше заданного, но с многократным оверхедом.

Боже мой, да сделай тройную или пятерную избыточность и мажорирование ответа от каждого чипа памяти и будет у тебя за тот же такт все отрабатывать

ОМГ, так мы еще и не знаем как устроена оперативная память. Марш в гугол !

И, опять же, речь идёт о чисто софтовой процедуре, на уровне ОС, выполняющей преобразования обращений к памяти и расположенной исключительно на внутренних буферах процессора, без использования внешней памяти для собственных нужд.

В случае с x86_64 это не возможно, поскольку даже если каким-то образом ты заставишь ОС хранить данные в TLB, хотя ни ее размер ни ее организация для этого не предназначены - исполняемые процессором команды все равно придется транслировать через ОЗУ, потому что регистры.

Если такое и делать - то на других архитектурах, поддерживающих размещение кода вне оперативной памяти.

Если такое и делать - то на других архитектурах, поддерживающих размещение кода вне оперативной памяти.

Ага ,в прошлом веке я так делал «мини управлятор» на КР1816ВЕ51 ©: 2 банка ПЗУ с аппаратным переключением оных ихним битом контроля чётности. Работало безотказно.

Некоторые чипы памяти хотят sweet spot по напряжению, стабильность уХудшается при дальнейшем его повышении.

Ага ,в прошлом веке я так делал «мини управлятор» на КР1816ВЕ51 ©: 2 банка ПЗУ с аппаратным переключением оных ихним битом контроля чётности. Работало безотказно.

Отож. Сделать хитрожопую коррекцию памяти с заменой банок, резервированием ячеек и прочими финтами сделать несложно. Вообще.

Но здесь идет речь о портировании на ЭТО уже существующей не самой простой операционной системы.

Вопрос в основном касается использования широко доступных компонентов в жёстких условиях,

А в чем вопрос? Можно ли использовать? Можно. Существует овердохрена алгоритмических методов выживания вычислений в жестких условиях. И это не только коды «Ридоса-Ломона», а чаще всякие виды дублирований (слово «дублирование» не очень походит, скорее триплирование, квадрирование и так далее) с разносом вычислительных действий во времени и пространстве. Главное - обеспечить на конструктивно-аппаратном уровне долговечность железа и интенсивность ошибок не выше заданной. А дальже мажорируйте как умеете

Но здесь идет речь о портировании на ЭТО уже существующей не самой простой операционной системы.

откуда это требование появилось? сам придумал?

тебе лично кто-то или что-то мешает сделать для новой памяти общепринятый интерфейс и затем бесшовно и тупо подключить ее в уже существующие девайсы?

ведь всей остальное системе не требуется ничего знать о том, что память будет изнутри устроена как-то иначе.

откуда это требование появилось? сам придумал?

Может ли компьютер работать на оперативе из ашана, испозьлуя избыточное кодирование?

тебе лично кто-то или что-то мешает сделать для новой памяти общепринятый интерфейс и затем бесшовно и тупо подключить ее в уже существующие девайсы?

man JEDEC.

man FSB/DMI/HT

Хотя конечно идея переходника с USB флешки в DDR5 DIMM - забавная :))

ECC работает прозрачно для процессора (хотя и с уведомлением)

Эта функция практически везде отключена.

Никогда не замечал, что количество чипов на модуле кратно 8? Условно говоря и сильно упрощая, каждый чип отдаёт по биту в байт. И как ты собрался мажорировать ответы от чипов?

Стандартная для 70-х годов схема : компьютер загружается из ПЗУ, тестирует оперативу, работает с рабочей областью, если может. Ничего более инновационного придумано не было.

Есть даже реальный пример, какие-то студенты собрали рабочую систему из поврежденных компонентов. Это было давно, ссылку я уже не найду, потому что точно помню, что читала на бумаге. Может даже в «Компьютерре».

Полагаю товарищ коряво выразился. Мажорирют не ответы от одного чипа. Мажорируют блоки памяти. Мажорируют вычисления в блоках.

И вообще вы тут все зря уперлись в память. «Там» сбоит все и везде, а не только память. Сбоят процессоры - и в кэшах, и в алу. Сбоит силовая часть - питание и управление. Причем сбои в силовой части самые опасные.

Силовую часть контролирует супервизор, который просто рубит питание при неудачном защёлкивании. Мотивацию я уже фыр - в большинстве сообщений о сбоях фигурирует память.

Владимир Ильич не тормозите! Воочую видел модули с 4 чипами, с 9 чипами, это что касается димов для ПК. Но речь то про память на некоем специальном вычислителе. На видеокартах, например, бывает 6 чипов. А на какой нить ембедщине и вовсе один

Или ноль :3

4 чипа на модуле - это так называемая двухбитовая память. Один чип маскируется под два. Очень дешманское решение, сути это не меняет. 9 чипов - это ЕСС, это другое. Там 8 битов + 1 чётности. Работает также, просто есть контроль на аппаратном уровне. DRAM везде работает работает одинаково, она в принципе одинаковая. И на видеокартах это таже DRAM. На встраиваемых - там скорее всего хитрый контроллер памяти, который имитирует DRAM как SRAM. Он _очень тормозит доступ к оперативе и ничего не решает, кроме цены.

Вряд-ли он это имел ввиду.

Проблема силовой части не в неудачном защелкивании. Проблема в катастрофическом выходе из строя - силовая часть работает при других токах и напряжениях и пробои приводят к совсем иным эффектам, чем в логической части

Мотивацию я уже фыр - в большинстве сообщений о сбоях фигурирует память.

Не постигайте технику посредством журналистов и официальных релизов. Память - это доступно и понятно простому человеку. А для инженера/программиста проблемы с памятью - самые управляемые и легкокомпенсируемые

Давайте сначала думать о людях хорошо

Может ли компьютер работать на оперативе из ашана, испозьлуя избыточное кодирование?

Он может и без этого работать, но программы будут иногда некорректно выполнятся, а также с некоторой вероятностью может падать операционная система.

А, так автор хочет использовать не только память из ашана, но и программы и операционки тоже из ашана?

тебе лично кто-то или что-то мешает сделать для новой памяти общепринятый интерфейс и затем бесшовно и тупо подключить ее в уже существующие девайсы?

Rambus делали. Латентность увеличивается. В результате - прирост производительности был не всегда и не везде.

Всё имеет свою цену.

еще раз, для напористых сельских дурачков:

тебе никто не мешает сделать набор хоть из 8 планок, хоть из скольки, которые будут работать параллельно (т.е. «многоканальная» архитектура) типа как «хаб». но для системы это будет выглядеть как 1 планка.

а потом развести отдельную плату под это дело, где кроме самих планок надо будет еще FPGA набросать «скетч», который посути будет проксировать обращение к модулю памяти и рассылать одновременно на все те модули параллельно. а потом будет забирать результаты (также параллельно) и отдавать наружу (быстренько собрав из всей кучи наиболее достоверный).

интерфейс подключения модулей и работы с ними тот же самый останется.

все дополнительные задержки и все чем тут местные аналитики пугают, будут только на проксирование комманд посути (потому что в остальном, модули те же самые будут) и формирование ответа.

(возможно придется немного пободаться с рефрешем, но это все решаемо)

Хотя конечно идея переходника с USB флешки в DDR5 DIMM - забавная :))

откуда ты этот словесный понос берешь? и какая связь с тем что мы тут обсуждаем?

все дополнительные задержки и все чем тут местные аналитики пугают, будут только на проксирование комманд

В космосе мало кого волнуют дополнительные задержки - там овердохрена времени на все. Там до сих пор работают процессоры с далеко допентиумной производительностью. Почти любой расчет вы можете произвести хоть десять раз, а в промежутках между разами еще и протестировать память.

а потом развести отдельную плату под это дело, где кроме самих планок надо будет еще FPGA набросать «скетч», который посути будет проксировать обращение к модулю памяти и рассылать одновременно на все те модули параллельно. а потом будет забирать результаты (также параллельно) и отдавать наружу (быстренько собрав из всей кучи наиболее достоверный).

Ну и херни ты наговорил. Лень объяснять. Лучше поинтересуйся у гугола или чатГПТ, почему твой компьютер поддерживает только DDR4, а не скажем DDR5 и одновременно DDR2.

интерфейс подключения модулей и работы с ними тот же самый останется.

И шо, я таки смогу вставить это в ноутбук?)

все дополнительные задержки и все чем тут местные аналитики пугают, будут только на проксирование комманд посути (потому что в остальном, модули те же самые будут) и формирование ответа.

Мсье всего лишь путает интерфейс с шиной, отсюда каскад последующих глупых идей.

Чтобы тебе «проксировать команды», на твоей плате должен будеть находиться микроконтроллер, работающий на частоте шины + частоте твоей собственной шины которую ты собираешься транслировать+10% на собственные нужды. Если у тебя на компьютере используется DDR3 и внутри твоего колхоза тоже DDR3 - суммарная вычислительная мощность твоего МК (как одноядерного, так и несколькоядерного) должна быть 1200+1200+240 = +\- 2600 МГц. Чё, забыл что мы говорим о бинарном коде, а значит дискретизация преследует нас повсюду?)

При первом же обращении к памяти, которая не сможет ответить в течение тактового импульса - твой контроллер памяти (вшитый в процессор естественно) попросту запишет в себя FAIL и твой спикер начнет систематично пищать долгим сигналом.

(возможно придется немного пободаться с рефрешем, но это все решаемо)

Напуркуа тебе рефреш, если ты выше говорил за интерфейс и проксирование? Рефреш остается на твоей совести, если он вообще нужен, а то мало ли, вдруг ты будешь использовать SRAM а не классическую DRAM.

откуда ты этот словесный понос берешь? и какая связь с тем что мы тут обсуждаем?

Перечитай сабж. Здесь человек спрашивает об обычной планке из говномаркета в обычном компьютере оттуда же, а значит все последующие условия определяются этими двумя.

SRAM как сущность давно умерла. Она существует только в виде ассоциативной памяти в виде кеша на процессоре. Если попытаться впиндюрить классический модуль SRAM в современную ЭВМ, она только начнет показывать производительность на уровне 20 лет назад. Рефреш тоже давно в прошлом. Вся DRAM уже 30 лет регенеруется сама.

чёто пахнет 4.2

На refresh нужно лишний цикл. Лишний Цикл - это не дохрена ли ? Ты ведь понимаешь, что сейчас принято большинство команд делать быстрее, чем за такт? А тут получается минимум два. Товарищ, этот лишний цикл рефреша всем мозолил глаза давно. SRAM - таже история. Классичеcкая SRAM отвечает за цикл, что сейчас много. Ядер ведь сейчас тоже много.

https://www.phoronix.com/forums/forum/hardware/general-hardware/1185675-linux-5-8-to-support-emulating-mlc-nand-flash-memory-as-slc

не про оперативку, но тем не менее про память.

«Что-то с памятью моей стало,128 мб уже мало!» - народное со времён Aston.

это точно имеет смысл? Мне казалось, все контроллеры уже лет 200 как считают контрольные суммы, и «поплывшие» данные просто не считываются.