Комментарии 12
Про ускорение — непонятно, ldpc коды требуют больших длин блока для эффективной работы => чтения данных большими кусками и многоитеративного декодирования, а это замедляет работу…
Хотелось бы услышать подробности по поводу структуры или характеристик используемых кодов. Иначе это больше похоже на сложное слово для рекламной кампании.
Если вкратце, то суть такова: это линейный код с разреженной матрицей (это важно, поскольку хранить на контроллерах плотную матрицу в мильён элементов не получится), причем даже разреженность обычно регулярная. Линейный — значит проверка осуществляется тупым перемножением проверочной матрицы на входной сигнал. Но поскольку при чтении обязательно вмешивается физика процесса (процессы намагничивания-размагничивания, межсимвольная интерференция, дрожание считывающей головки и пр), то обычно каждый бит (набор битов) — это не хард-значение 0\1, а некое действительное число (то самое софт-значение из статьи), т.н. log-likelihood ratio, LLR, логарифм отношения правдоподобия, это если по-русски. Вот с этими действительным значениями обычно и работают алгоритмы. Например, Витерби.
Но со всеми плюсами у этих кодов есть один, но неприятный минус — наличие т.н. error fllor, а именно существует такая неприятная ситуация, когда при увеличении SNR сигнала ошибка не уменьшается. Правда, это ошибка настолько мала (10 в минус 20 что ли для жестких дисков, ну или где-то такие порядки), что заметить ее или просимулировать практически невозможно. И вот здесь в бой вступает тяжелая статистическая артиллерия в виде importance sampling, предложенная Коулом.
Собственно, вся работа над этими кодами по большей части распадается на две части:
— придумывание самого кода (порождающей\проверочной матрицы);
— придумывание хороших алгоритмов для работы с софт-значениями LLR.
Зачастую еще применяют дополнительное кодирование на входе кода с нужными характеристиками, а также различный интерливинг, но это уже по вкусу :)
Вот, собственно, и вся внутренняя кухня (походите по ссылкам, если интересно), которую следует давать айтишникам, а не та рекламная простынка из поста (автор, ничего личного ;)).
Но со всеми плюсами у этих кодов есть один, но неприятный минус — наличие т.н. error fllor, а именно существует такая неприятная ситуация, когда при увеличении SNR сигнала ошибка не уменьшаетсяОна уменьшается, только не так быстро, т.е. происходит излом но наклон и этой полки круче, чем кривая канала без кодека и кривые исправляющей способности канала с кодеком и без не пересекутся.
Да… Конечно, залезли люди… К чему эти 10 в степени -15...-20? Да еще и такая чувствительность к SNR (буквально от 2 до 7 дБ и такая пропасть по BER). Не проще ли разделять каскадно коды, т.е. несколько простых (средней длины или даже коротких) кодов вместо одного сложного (длинного), по аналогии с каскадом усилителей?
Представьте, что оставшиеся ошибки после кода это ситуация, когда он спутал одно кодовое слово с соседним и выдал после себя пачку ошибок, тогда второму коду сопоставимой длины будет сложнее её исправить, чем более равномерно распределённые ошибки в канале с белым шумом. Канал после кодека имеет другое распределение ошибок и просто так утверждать что-то об эффективности сложно. Так же и каскад усилителей, у уаждого из которых есть порог своего теплового шума будет усиливать такой шум от первого каскада. А так пару кодов в пару иногда ставят, как и мшу + обычный усилитель.
Ну это на пальцах, а так там и другие проблемы есть.
Хм, естественно, что коды надо согласовывать друг с другом, а не абы как. Ведь декодер (жесткий, синдромный) можно настроить как угодно, т.к. на один синдром вешается несколько возможных векторов ошибок. Допустим, есть два кода одинаковой длины, но у одного кодовое расстояние — 3, у второго — 7; первый декодер настраиваем на исправление однократных ошибок (двукратные он по большей части переведет в трехкратные), второй — на исправление трехкратных.
Как бы то ни было, идея с одним большим кодом непрактичная, хотя теоретически да, с ростом длины кода исправляющая способность, в целом, растет, однако если мы ограничиваемся низкоплотностными кодами (по причине экономии затрат времени на декодирование), то посылка Шеннона о случайности кода, полагаю, подрывается (матрица проверок на четность хорошего кода тоже должна быть случайной — с какой стати она должна ограничиваться низкой плотностью единиц?). Вот и получается, что не там, так сям ограничение, которое и ограничивает резкое падение BER. Ресурс, мать его… За все надо платить. Почему бы чуток не подкрутить мощности? Все валить на супер-кодек — нерационально (дисбаланс, плюс резкое повышение BER при незначительном падении SNR).
Как «волшебство» кода коррекции ошибок, которому уже больше 50 лет, может ускорить флэш-память