Не-а, я такого не говорил - это Вы все мне упорно пытаетесь приписать данное утверждение

Что значит "лучше-хуже"? Давайте уж разговаривать как инженеры а не как "гумонетарии" - в цифрах. Как можно разговаривать в цифрах? А очень просто - в нашем конкретном случае цифра заключена в величине вероятности что прийдет ошибочный пакет и эта ошибка не будет распознана. Такая вероятность вычисляется как сумма произведений вероятности возникновения на данной линии ошибка данного типа (распределение ошибок) на вероятость необнаружения данной ошибки проверочным кодом (определяется самим типом кода). Чтобы подсчитать конкретную цифру надо хорошо владеть теорией линейных кодов. Я эту теорию глубоко не изучал, но как инженер, просто готов воспользоваться выводами математиков - они уверяют что CRC обеспечит одну из наименьших вероятостей (при каких условиях врать не буду- при нормальном ли распределении, или при равномерном - не знаю). Поэтому, у Вас есть два варианта - изучить теорию линейных кодов и подсчитать эти вероятности для Ваших линий самому (и поделиться с нами результатами ) для случаев арифметической суммы и для CRC, или просто поверить в готовые теоретические выводы, как это сделал я и многие другие. Возможно, у нас на форуме есть люди более глубоко владеющие математической стороной вопроса - они меня поправят или даже приведут цифры. Я, увы, за разумное (как для форумной дискусcии) время сделать этого не могу.

Ну, дык - извините! Если передавали:
1010101010101010, а приняли:
1110100010101110 в результате действия помехи при передачи всей этой информации, то это - три одиночные ошибки, а не - "множественное поражение шестнадцати бит".

PS. Вы этим термином, наверно, именуете, любую последовательность из 16 бит, в которой несколько битов приняты неверно?

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

Ну да, это три одиночные ошибки, расположенные компактно.
Или это - множественное однократное поражение длиной не более 16 бит.
Вы похоже с помехами никогда не сталкивались, если решили, что помеха аккуратненько переворачивает все 16 бит в передаваемом пакете.




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

Вероятностно ХУЖЕ во всех случаях, кроме одного единственного - одиночная ошибка. В этом случае она ЛУЧШЕ. Все, достаточно толочь воду в ступе.


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

Откуда такая уверенность?
Вроде для обнаружения многобитной одиночной ошибки CRC хуже.
Лучше оно только для обнаружения двух разнесенных по блоку однобитных ошибок.



А зачем?
Разве я где то говорил про какую то выровненность?

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

Так поясните.
Вдруг это Вы не задумывались?
И заодно предложите другой термин для многибной ошибки, локализованной в пределах n последовательных бит
( ошибки, вызванные одиночной мощной помехой ).

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

Вы забыли пройтись по первому пункту. Кто там мало подумал?

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

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

Зачем повторяться? Но если хотите, то последний раз - Вы, и продолжаете бездумствовать , даже после лобовых указаний. Ну так имеющий разум да поймет, ну хотя-бы со временем.
Я все сказал.

Притчу про повторение слова халва слышать приходилось? Можете продолжать, но мне надоело.

Не то. В данном случае речь идет просто о банальной вероятности обнаружения ошибки.

+1 Мне тоже, и уже довольно давно

полумер - это рисование абзацев в MS Word'е пробелами.
Может когда-то поймете, что таким вот __форматированием строки пробелами__ свое же время не жалеете, впрочем и чужое тоже.

Может и пойму, но это не одно и тоже, что и абзацы, это одна строка с else выравнивается под if и всё - никакого криминала я не вижу.
Будем считать что я Вашу мысль понял и Ваше мнение уважаю. Спасибо за дискуссию!