Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Алгоритм CRC16
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
Страницы: 1, 2
vallav
Цитата(zltigo @ Apr 16 2010, 20:18) *
Вероятностно ХУЖЕ во всех случаях, кроме одного единственного - одиночная ошибка. В этом случае она ЛУЧШЕ. Все, достаточно толочь воду в ступе.


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

Цитата(zltigo @ Apr 16 2010, 20:18) *
А с помехой Вы как договариваетесь, о том, что-бы эти биты еще и располагались выровненно относительно размера суммируемого фрейма?


А зачем?
Разве я где то говорил про какую то выровненность?
zltigo
Цитата(vallav @ Apr 16 2010, 20:34) *
Разве я где то говорил про какую то выровненность?

Да Вы даже об этом и не задумывались, и сейчас не думаете, судя по изобретению дивного термина "многобитная одиночная ошибка" sad.gif.
vallav
Цитата(zltigo @ Apr 16 2010, 23:04) *
Да Вы даже об этом и не задумывались, и сейчас не думаете, судя по изобретению дивного термина "многобитная одиночная ошибка" sad.gif.


Так поясните.
Вдруг это Вы не задумывались?
И заодно предложите другой термин для многибной ошибки, локализованной в пределах n последовательных бит
( ошибки, вызванные одиночной мощной помехой ).
zltigo
Цитата(vallav @ Apr 17 2010, 16:59) *
И заодно предложите другой термин для многибной ошибки, локализованной в пределах n последовательных бит
( ошибки, вызванные одиночной мощной помехой ).

Другие термины для изобретенного Вам сферического коня в вакууме не требуются. Для битового потока одиночная ошибка это бит. Все остальные это множественные ошибки. Их локализация в пределах произвольного количества бит, отстоящих на произвольное количество бит от начала фрейма ничего не дает для простейшего суммирования.
vallav
Цитата(zltigo @ Apr 17 2010, 18:31) *
Другие термины для изобретенного Вам сферического коня в вакууме не требуются. Для битового потока одиночная ошибка это бит. Все остальные это множественные ошибки. Их локализация в пределах произвольного количества бит, отстоящих на произвольное количество бит от начала фрейма ничего не дает для простейшего суммирования.


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

А по поводу вида ошибок - ошибки бывают разные.
Под те, что Вы описали - как раз CRC заточено.
Это канал с постоянным но небольшим шумом.
Но есть и другие например, когда в канале возможна редкая но мощная помеха.
В этом случае сбойных битов много, но они в одном месте сосредоточены.
Вот для этого CRC мало пригодна.
mdmitry
Цитата(vallav @ Apr 17 2010, 18:45) *
Но есть и другие например, когда в канале возможна редкая но мощная помеха.
В этом случае сбойных битов много, но они в одном месте сосредоточены.
Вот для этого CRC мало пригодна.

В этом случае требуется помехоустойчивое кодирование. Битовый поток кодируют и перемежают, а потом передают по каналу связи.
zltigo
Цитата(vallav @ Apr 17 2010, 17:45) *
Вы забыли пройтись по первому пункту. Кто там мало подумал?

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

Притчу про повторение слова халва слышать приходилось? Можете продолжать, но мне надоело.
Цитата(mdmitry @ Apr 17 2010, 18:20) *
В этом случае требуется помехоустойчивое кодирование.

Не то. В данном случае речь идет просто о банальной вероятности обнаружения ошибки.
demiurg_spb
Цитата(zltigo @ Apr 17 2010, 19:26) *
Я все сказал.
... Можете продолжать, но мне надоело.
+1 Мне тоже, и уже довольно давноsad.gif
defunct
Цитата(demiurg_spb @ Apr 14 2010, 22:20) *
Я либо в строку форматирую, либо уж по полной программе со скобочками.
К полумерам не привык!

полумер - это рисование абзацев в MS Word'е пробелами.
Может когда-то поймете, что таким вот __форматированием строки пробелами__ свое же время не жалеете, впрочем и чужое тоже.
demiurg_spb
Цитата(defunct @ Apr 18 2010, 01:02) *
полумер - это рисование абзацев в MS Word'е пробелами.
Может когда-то поймете, что таким вот __форматированием строки пробелами__ свое же время не жалеете, впрочем и чужое тоже.
Может и пойму, но это не одно и тоже, что и абзацы, это одна строка с else выравнивается под if и всё - никакого криминала я не вижу.
Будем считать что я Вашу мысль понял и Ваше мнение уважаю. Спасибо за дискуссию!
vallav
Цитата(zltigo @ Apr 17 2010, 19:26) *
Зачем повторяться? Но если хотите, то последний раз - Вы, и продолжаете бездумствовать sad.gif, даже после лобовых указаний. Ну так имеющий разум да поймет, ну хотя-бы со временем.
Я все сказал.

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

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


Хорошо, вот Вам конкретика.
По зашумленному каналу передаются данные.
Передача идет пакетами по 256 байт.
Примерно каждый десятый пакет сбойный - одиночная ошибка.
Многократные ошибки соответственно реже.
Обнаруженные сбойные пакеты пересылаются повторно.
Естественно включен побайтовый контроль четности.
Вопрос - какой метод лучше для обнаружения сбойных пакетов, пропущенных
побайтовым контролем четности?
Прямая 16 битная сумма пропустит сбойный пакет, у которого в одном байте две ошибки и в другом, отстоящем от первого
на четное число байт две ошибки в тех же разрядах. В среднем одну из 4х таких ошибок.
То есть, четверную ошибку достаточно специального вида.
Что пропустит CRC?
Хуже в такой достаточно типичной ситуации CRC или лучше.

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

Как Вам такая конкретика?
Жду Вашего обоснованого выбора.



Цитата(mdmitry @ Apr 17 2010, 19:20) *
В этом случае требуется помехоустойчивое кодирование. Битовый поток кодируют и перемежают, а потом передают по каналу связи.


Помехоустойчивое кодирование требуется в случае, если или 90% пакетов сбойные или повторная посылка сбойного
пакета затруднена.
Если сбойных пакетов ~10% и нет проблем повторить посылку пакета - зачем нам паровоз?
А вот между велосипедом и самокатом повыбирать стоит...
Палыч
Цитата(vallav @ Apr 18 2010, 16:32) *
Если сбойных пакетов ~10% ...
Это - результат Вашего неправильного проектирования...
vallav
Цитата(Палыч @ Apr 18 2010, 18:37) *
Это - результат Вашего неправильного проектирования...


Полагаете, работать не будет?
А как должно быть правильно?
И каков ответ - что лучше?
Палыч
Цитата(vallav @ Apr 18 2010, 17:47) *
Полагаете, работать не будет?
А как должно быть правильно?
Работать - будет. Но - плохо... Если каждый десятый пакет - сбойный, это - просто отвратительно... Скорее всего, при проектировании канала передачи информации приняты неправильные технические решения.
VslavX
Цитата(vallav @ Apr 18 2010, 16:32) *
Что пропустит CRC?

Ничего не пропустит - все обнаружит. Описанная ошибка это некоторое K разрядностью менее длины проверочного слова умноженное на X^n + 1, где n - число бит между ошибками. А X^n + 1 гарантировано без останка не делится для выбранного полинома для достаточно большого n (которое не может превышать общую длину блока, для которого кодовое расстояние 2+). А раз не делится - значит CRC при такой ошибке гарантировано изменится и такую ошибку обнаружит - то есть любое инвертирование бит (менее длины проверочного кода) подряд дважды в любом месте блока будет обнаружено.
vallav
Цитата(Палыч @ Apr 18 2010, 19:18) *
Работать - будет. Но - плохо... Если каждый десятый пакет - сбойный, это - просто отвратительно... Скорее всего, при проектировании канала передачи информации приняты неправильные технические решения.


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



Цитата(VslavX @ Apr 19 2010, 00:28) *
Ничего не пропустит - все обнаружит. Описанная ошибка это некоторое K разрядностью менее длины проверочного слова умноженное на X^n + 1, где n - число бит между ошибками. А X^n + 1 гарантировано без останка не делится для выбранного полинома для достаточно большого n (которое не может превышать общую длину блока, для которого кодовое расстояние 2+). А раз не делится - значит CRC при такой ошибке гарантировано изменится и такую ошибку обнаружит - то есть любое инвертирование бит (менее длины проверочного кода) подряд дважды в любом месте блока будет обнаружено.


Да, двойные ошибки будут все обнаружены.
Но интересует обнаружение четверных ошибок, пропущенных байтовым контролем по четности ( то есть, два сбойных байта в блоке,
в каждом байте двухбитовая ошибка ).

Кстати, чтобы CRC обнаруживало все двойные ошибки, нужно чтобы в конце была выполнена холостая прокрутка.
Иначе двойная ошибка - бит в последнем слове и бит в слове CRC может быть пропущена.
VslavX
Цитата(vallav @ Apr 19 2010, 07:37) *
Да, двойные ошибки будут все обнаружены.
Но интересует обнаружение четверных ошибок, пропущенных байтовым контролем по четности ( то есть, два сбойных байта в блоке,
в каждом байте двухбитовая ошибка ).

Вы не поняли что я написал. Будет обнаружена двойная ошибка для ЛЮБОЙ последовательности в 'к' бит, если 'к' меньше длины проверочного кода. Длина байта - 8 бит, длина CRC-16 - 16 бит. Причем между сбойными последовательностями может быть произвольное количество битов, не обязательно выравнено на байт. То есть, если одинаково сбоят, например биты 1 и 5 в любых даух байтах - это обнаруживается. Даже если одинаково сбоят биты 0..14 в любых 15 битах - то есть правильная последовательность в двух местах по-XOR-ена с одной и той же 15-битовой комбинацией - то такое тоже 100% обнаруживается.
Если же ошибки в байтах разные, то может уже и пропустить.
vallav
Вы хоть в курсе - что это такое - CRC и как именно это делается?
Похоже, что нет.
У Вас - просто наоборот, чем получается при простом XOR без сдвига.
Но это не CRC, это что то другое...
VslavX
Цитата(vallav @ Apr 19 2010, 09:07) *
Вы хоть в курсе - что это такое - CRC и как именно это делается?
Похоже, что нет.
У Вас - просто наоборот, чем получается при простом XOR без сдвига.
Но это не CRC, это что то другое...

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

"Пакет" = "Передаваемые данные" + "Ошибка"

В этом тождестве все переменные - полиномы, а операция сложения выполняется полиномиально - именно "простым XOR-ом". CRC- это остаток от полиномиального деления:

CRCp = "Пакет" % "проверочный полином"

Для правильный данных:

CRCd = "Передаваемые данные" % "проверочный полином"

CRCp будет равно CRCd (пакет ошибочно считается правильным) тогда и только тогда, когда

CRCe = "Ошибка" % "проверочный полином" = 0 (равно нулю, то есть делится без остатка на проверочный полином)

Для Вашего примера ошибка представляется так:

"Ошибка" = (00..00100..n-bit...00100..00) x K, битовая длина произвольного K меньше длины проверочного полинома

CRCe будет нулевым если K или (00..100..n-bit..00100..00) делится на полином без остатка
К - не делится, так как его длина меньше чем длина полинома
(00..1..1..00) - не делится для любой возможной комбинации в пакете, так как полином и разрядность CRC всегда выбирается такой чтобы мин кодовое расстояние было не менее 2.
Поэтому ошибка того типа про которую Вы толкуете ловится CRC "влет". Компрене?

Upd: Для CRC-16 длина проверочного полинома на самом деле 17 бит, поэтому длина К может быть до 16 бит включительно.
vallav
Ну что Вам сказать.
Вы настолько в этм всем уверены, что ...

На самом деле, CRC заточена на отлавливание двух битовых ошибок произвольно расположенных в передаваемогм пакете
( двухкратная ошибка ).
Но это не дается даром.
CRC довольно плох при отлавливания многобитовых ошибок.
В часности, в данном случае нужно ловить четырехкратную ошибку.
VslavX
Цитата(vallav @ Apr 19 2010, 10:18) *
Ну что Вам сказать.
Вы настолько в этм всем уверены, что ...

Ясно, значит будем сомневаться в арифметике. Более просто и строго я объяснить не в силах.

Цитата(vallav @ Apr 19 2010, 10:18) *
На самом деле, CRC заточена на отлавливание двух битовых ошибок произвольно расположенных в передаваемогм пакете
( двухкратная ошибка ).

Да, btw, выше показано что не только двухкратная однобитовая но и двухкратная многобитовая, не говоря уже об однократных многобитовых.

Цитата(vallav @ Apr 19 2010, 10:18) *
Но это не дается даром.

Чем надо платить? smile.gif
На самом деле, CRC в "железе" реализуется намного проще чем упомянутая Вами обычная арифметическая сумма. Программная реализация CRC тоже не особо сложна - если понять принцип. Я Вам даже открою "секрет" - в криптографии, там где очень длинные числа, полиномиальное деление и сложение как правило работают быстрее обычных - так как нет этого дурацкого распространяемого между словами переноса. Медленее работает умножение - и то исключительно потому что у большинства процессоров нет инструкции полиномиального умножения.

Цитата(vallav @ Apr 19 2010, 10:18) *
CRC довольно плох при отлавливания многобитовых ошибок.

Любую однократную в "k бит подряд" CRC отлавливает. Ну а умеючи-то - все что хошь сломать можно smile.gif

Цитата(vallav @ Apr 19 2010, 10:18) *
В часности, в данном случае нужно ловить четырехкратную ошибку.

Мне тоже уже надоело. Импульс в нужную сторону - полиномиальная арифметика в частности, и теория линейных кодов в общем - Вам придали, а дальше - "имеющий уши да услышит". За сим разрешите откланяться.
vallav
Цитата(VslavX @ Apr 19 2010, 11:41) *
Мне тоже уже надоело. Импульс в нужную сторону - полиномиальная арифметика в частности, и теория линейных кодов в общем - Вам придали, а дальше - "имеющий уши да услышит". За сим разрешите откланяться.


Значит Ваша версия - в приведенном примере лучше использовать CRC.
Так как Вы уверены, что она отлавливает все четверные ошибки.
Так?

И даже отлавливает все ошибки большей кратности, вплоть до 16.
И зыждется эта уверенность на том, что "полиномиальная арифметика в частности, и теория линейных кодов в общем".
Если не секрет, CRC с каким полиномом обладает таким замечательным свойством?
Для пакета длиной в 256 байт и контрольном слове длиной 16 бит.
Можно попробовать проверить это замечательное свойство прямым вычислением
( если полином приведете ).

Кстати, на поясните Ваше - "Да, btw, выше показано что не только двухкратная однобитовая но и двухкратная многобитовая, не говоря уже об однократных многобитовых".
Чем именно двухкратная многобитовая ошибка отличается от однократной многобитовой?
VslavX
Цитата(vallav @ Apr 19 2010, 13:50) *
Так как Вы уверены, что она отлавливает все четверные ошибки.

Про _все_ я не говорил, имелся в виду Ваш пример, где искажены два байта, по два бита в каждом, на одних и тех же позициях.

Цитата(vallav @ Apr 19 2010, 13:50) *
И даже отлавливает все ошибки большей кратности, вплоть до 16.

Да, если эти 16 бит расположены подряд.

Цитата(vallav @ Apr 19 2010, 13:50) *
Если не секрет, CRC с каким полиномом обладает таким замечательным свойством?
Для пакета длиной в 256 байт и контрольном слове длиной 16 бит.
Можно попробовать проверить это замечательное свойство прямым вычислением
( если полином приведете ).

Э-э... Стесняюсь cпросить, у Вас гугль недоступен? Первая ссылка
OK, сейчас я занят, но вечером потрачу 15 минут и накатаю тестик CRC-16 на блоке 256 байт.
vallav
Цитата(VslavX @ Apr 19 2010, 15:42) *
Про _все_ я не говорил, имелся в виду Ваш пример, где искажены два байта, по два бита в каждом, на одних и тех же позициях.


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



Цитата(VslavX @ Apr 19 2010, 15:42) *
Э-э... Стесняюсь cпросить, у Вас гугль недоступен? Первая ссылка
OK, сейчас я занят, но вечером потрачу 15 минут и накатаю тестик CRC-16 на блоке 256 байт.


Вы про
http://rsdn.ru/article/files/classes/SelfCheck/crcguide.pdf

И что именно Вы там обнаружили?
Или Вы туда даже не заглядывали...
defunct
Цитата(vallav @ Apr 19 2010, 10:18) *
CRC довольно плох при отлавливания многобитовых ошибок.

biggrin.gif - несомненно ваша арифметическая сумма гораздо лучше.

Вероятность того, что CRC32 пропустит серьезную ошибку - например весь пакет искажен нафиг - равна 1 / 2^32.
Вероятность же, что такую ошибку пропустит ваша сумма равна - 1/2. --> если пакет будет занулен - пропустит, если "заединичен" - непропустит.
Вот собсно и вся надежность децкой суммы - 50/50.


Цитата
А CRC может пропустить не эти, а другие, удовлетворяющие исходному условию.

Чтобы Вам не быть голословным, можете привести конкретный пример, - когда CRC16 пропускает искажение любых 4-х битов сообщения?
А мы потом пообсуждаем.
Палыч
Цитата(vallav @ Apr 19 2010, 15:52) *
...Это то, что пропустил контроль побайтовой четности.
А где в блоке байты и где в байтах ошибки - не важно.
Конкретно - искажены два байта, по два бита в каждом, на одних и тех же позициях - это то, что прямая сумма пропускает.
А CRC может пропустить не эти, а другие, удовлетворяющие исходному условию.
Ну, что Вы так разошлись? Вашу бы энергию - да в мирных целях...
Контроль чётности в Вашем примере - слабое утешение, раз помеха у Вас столь продолжительная, что действует в течении времени передачи двух байтов (помеха и на биты четности может повлиять). Поэтому суммирование может пропустить и блок, в котором информация искажена всего в двух битах.
Конечно же, CRC - не панацея, и по её анализу тоже может принято неверное решение о целостности пакета, но на "малых" длинах пакетов, имхо, CRC всяко лучше простой суммы.
vallav
Цитата(defunct @ Apr 19 2010, 18:43) *
Чтобы Вам не быть голословным, можете привести конкретный пример, - когда CRC16 пропускает искажение любых 4-х битов сообщения?
А мы потом пообсуждаем.


Дык нужно знать, какое имено CRC вы считаете непрорускающим четырехкратные ошибки.
Чтобы потом Вы не заявляли, мол - полином неудачный...
defunct
Цитата(vallav @ Apr 19 2010, 18:19) *
Дык нужно знать, какое имено CRC вы считаете непрорускающим четырехкратные ошибки.
Чтобы потом Вы не заявляли, мол - полином неудачный...

Давайте возьмем стандартный CRC16 (он же CRC-16-ANSI, который используется в modbus) полином - x16 + x15 + x2 + 1
VslavX
Цитата(vallav @ Apr 19 2010, 15:52) *
http://rsdn.ru/article/files/classes/SelfCheck/crcguide.pdf
И что именно Вы там обнаружили?
Или Вы туда даже не заглядывали...

Признаюсь, я много куда не заглядывал. Если понимать общие принципы то это часто можно себе позволить - никуда не заглядывать. Например, сейчас "не заглядывая" за полчаса была накалякана приаттаченная программка для проверки обнаружения двойных ошибок CRC-16-CCITT в 2048-битном блоке. После запуска на i7-860 пришлось ее пооптимизировать - перейти на табличный метод, а то думала слишком уж долго - и тоже никуда не заглядывая. Программка не шедевр, я бы даже сказал что немного чувствую себя идиотом - вроде как проверил 2x2=4 smile.gif. Но таки практически убедился - любое число из одной/двух единиц (полиномы вида X^n + X^m и X^n) в пределах 2048-битного блока на порождающий полином CCITT вида 0x1021 таки не делится. Более того - запустил и на 4096-битном блоке (199 секунд перебирала), также все OK - не делится!
Вот сама программка - не очень оптимальная, но написанная по-быстрому и честно "никуда не заглядывая ":), поэтому ногами сильно уж не пинайте smile.gif
CODE

#include <windows.h>
#include <stdio.h>

#define CRC_POLY 0x1021
#define CRC_WLEN 256 // number of 16bit words within block

USHORT pack[CRC_WLEN];
USHORT ctab[256];

__inline USHORT crc_update_simple(USHORT crc, USHORT data)
{
ULONG i;

crc = crc ^ (data << 8);
for (i=0; i<8; i++)
{
if (crc & 0x8000)
{
crc = (crc << 1)^CRC_POLY;
}
else
{
crc <<= 1;
}
}

crc = crc ^ (data & 0xFF00);
for (i=0; i<8; i++)
{
if (crc & 0x8000)
{
crc = (crc << 1)^CRC_POLY;
}
else
{
crc <<= 1;
}
}
return crc;
}

__inline USHORT crc_update_tab(USHORT crc, USHORT data)
{
crc = crc ^ (data << 8);
crc = ctab[crc >> 8] ^ (crc << 8);
crc = crc ^ (data & 0xFF00);
crc = ctab[crc >> 8] ^ (crc << 8);
return crc;
}

void crc_init(void)
{
ULONG i, j;

for(i=0; i<256; i++)
{
USHORT t;

t = (USHORT)(i << 8);
for (j=0; j<8; j++)
{
if (t & 0x8000)
{
t = (t << 1)^CRC_POLY;
}
else
{
t <<= 1;
}
}
ctab[i] = t;
}
}


__inline USHORT crc_calc_simple(USHORT *buf, ULONG len)
{
USHORT crc;

crc = 0;
if (len)
{
do
{
crc = crc_update_simple(crc, *buf++);
}
while(--len);
}
return crc;
}

__inline USHORT crc_calc_tab(USHORT *buf, ULONG len)
{
USHORT crc;

crc = 0;
if (len)
{
do
{
crc = crc_update_tab(crc, *buf++);
}
while(--len);
}
return crc;
}

void main(void)
{
ULONG start;
USHORT crc, *p1, *p2;
ULONG i1, i2;

crc_init();
printf("\r\nChecking %d-bit block", CRC_WLEN*16);

start = GetTickCount();
memset(pack, 0, sizeof(pack));
for(p1 = pack; p1 < &pack[CRC_WLEN]wink.gif
{
printf("\r\n%d", p1-pack);
for(i1=0; i1<16; i1++)
{
for(p2 = pack; p2 < &pack[CRC_WLEN]; p2++)
{
for(i2=0; i2<16; i2++)
{
*p1 = (1<<i1);
*p2 |= (1<<i2);
//
// crc = crc_calc_simple(pack, CRC_WLEN);
//
crc = crc_calc_tab(pack, CRC_WLEN);
if (crc == 0)
{
printf("\r\nCRC fail: %d, %d", (p1-pack)*16 + i1, (p2-pack)*16 + i2);
}
*p2 &= ~(1<<i2);
}
}
}
*p1++ = 0;
}
start = GetTickCount() - start;
printf("\r\n%d ms elapsed\r\n", start);
}


Upd: если верить статье на вики, то CRC-16 CCITT обеспечивает обнаружение всех одиночных, двойных, тройных и нечетных (я так понял что нечетное число битов искажается) в блоке до 4095 БАЙТ (32 с лишним тысяч бит). Увы, счетверенные ошибки обнаруживатся не все.
Upd2: Упомянутое Вами руководство Вильямса - хорошее, признаюсь - реально я когда-то давно (лет 10 назад, еще и русского перевода не было) изучал по нему программные реализации CRC.
vallav
Цитата(VslavX @ Apr 19 2010, 22:03) *
Признаюсь, я много куда не заглядывал.


То есть, других Вы посылаете читать по ссылкам, даже не заглядывая, куда именно
посылаете?

Цитата(VslavX @ Apr 19 2010, 22:03) *
Upd: если верить статье на вики, то CRC-16 CCITT обеспечивает обнаружение всех одиночных, двойных, тройных и нечетных (я так понял что нечетное число битов искажается) в блоке до 4095 БАЙТ (32 с лишним тысяч бит). Увы, счетверенные ошибки обнаруживатся не все.
Upd2: Упомянутое Вами руководство Вильямса - хорошее, признаюсь - реально я когда-то давно (лет 10 назад, еще и русского перевода не было) изучал по нему программные реализации CRC.


Дык это понятно, что одиночные, двойные и все нечетные ошибки CRC ловит.
Но это все поймает проверка байтов на четность.
Сравнивать с прямой суммой CRC нужно на предмет обнаружения четверных ошибок по две в байте.
То, что проверка байтов на четность пропускает.
Я за 10 минут программы писать не умею, так что займет у меня это несколько дней.
Имеется в виду китайский метод - перебором посчитать сколько четверных ошибок указанного типа пропустит CRC
в блоке 256 байт.
И сколько прямая сумма.
vallav
Посчитал.
Надеюсь, если и ошибся, то не сильно.
Получилось - в болке из 258 байт, четверных ошибок, пропущенных
побайтным контролем на четность в случае контроля по CRC с полиномом x^16+x^15+x^2+x^0
будет 6292 штук.
Прямая сумма хуже, она пропустит 43344 штуки.
Программа, по которой считалось, приложена.
Вместе они не пропустят ни одной четверной ошибки.
Но если делать контрольное слово 32 бита, то лучше две разных
прямых суммы - они тоже не пропустят ни одной четверной ошибки.
Так что высказывания - прямая сумма отстой по сравнению с CRC -
мало чем обоснованы.
Нажмите для просмотра прикрепленного файла
поменяйте расширение на .cpp
ASN
vallav
Прямая сумма хуже CRC16 в Вашем случае более чем в 6 раз. Что и требовалось доказать.
Если сумма 32-х битная (или две по 16), то это уже CRC32. Реализация контроля по CRC32 табличным методом на 8-ми битной ЭВМ проще. Что и требовалось доказать.
vallav
Цитата(ASN @ Apr 25 2010, 15:46) *
vallav
Прямая сумма хуже CRC16 в Вашем случае более чем в 6 раз. Что и требовалось доказать.
Если сумма 32-х битная (или две по 16), то это уже CRC32. Реализация контроля по CRC32 табличным методом на 8-ми битной ЭВМ проще. Что и требовалось доказать.


Ну да, прямая сумма пропустит такие ошибки в 6 раз вероятнее.
Но такие ошибки ( четверные по две в байте ) сами по себе для приведенного примера довольно редкие.
Вероятность где то ~ 10^-9 ( одна на миллиард пакетов ).
Намного вероятнее пачка ошибок от короткой мощной импульсной помехи.
А в этом случае прямая сумма вроде лучше ( если пачка короче 17 бит, прямая сумма ловит все ).
CRC из за перепутывания бит часть пропустит.

А вот откуда сведения, что на 8-ми битной ЭВМ реализация 32 битной СRC проще?
Код существенно длиннее, время выполнения несколько больше.
И Вы уверены, что есть 32 битные CRC не пропусакающие ни одной такой ошибки?
Две разные прямые суммы - точно не пропустят.

Я не про то, что CRC никуда не годится, я про то, что прямая сумма вполне годится а может быть
в некоторых случаях лучше CRC.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.