Конкретика: мы "от фонаря" порешали, что заголовок пакета специфического устройства размером 32 байта закрываем 8-битовой CRC, а поле данных длиной до 2 кБ закрываем 16-битовой CRC. Теперь, прочитав эту тему, я начинаю покусывать локти, что и там, и там, мы заложили недостаточный размер CRC, т.е. могу предположить, что надо было 16 бит и 32 бита соответственно.
Далее после добавления CRC весь пакет передаётся в канал, закодированный в 8B/10B. Канал связи - не радио, а проводной. Может быть либо медь, либо оптика. Медь - не более 3 метров, LVDS, по UTP. Оптика - до 2 км. По закону распределения ошибок в канале такого типа - сказать ничего не могу, т.к. мои познания в этом малы. Могу довериться вашему опыту.

Все равно нужно от чего-то оттолкнуться если нет экспериментальных данных.
Например ГОСТ 26.205-88 КОМПЛЕКСЫ И УСТРОЙСТВА ТЕЛЕМЕХАНИКИ, п.2.11.2.
Укажите согласно ГОСТу требования к вашему устройству на каналы связи.
Если это устройства "критического использования" - то нужно использовать
другие отраслевые документы.

После этого можно будет прикинуть помехозащищенность вашего протокола
и его соответствие требованием. Если уровень защиты CRC "в лоб" будет не
высоким, тогда рассматриваются другие типы кодирования.
Скажите в чем необходимость 8B/10B ? Выравнивание потока 0/1 для оптики ?

В качестве примера, для очень зашумленного канала (р=10е-3) вероятности
необнаруживаемого пропуска ошибок CRC8/16 привел на рис. Видно что
заголовок у вас защищен в три раза лучше чем поле данных.
Абсолютные значения вероятностей будут зависить от исходных данных
и выбранных вами требований.

Сообщение отредактировал i-mir - Apr 27 2011, 14:30

Уважаемый i-mir, спасибо за конкретную помощь.
Спасибо за ГОСТ. Думаю, категория 3я, ну максимум 2я. Не критического использования. Внутри поля данных этого пакета будут инкапсулированы пакеты других протоколов, у них будет своя защита от ошибок. К тому же ещё 8B/10B часть ошибок выловит. Он ловит все единичные ошибки в пределах одного символа.

Да, устранение постоянной составляющей, самосинхронизация битов и байтовая синхронизация.

У меня здесь следующие непонятности:
1. Где Вы взяли такие графики? Их считает программа? А Вы могли бы ей поделиться?
2. Может быть, более наглядно было бы построить графики для той же вероятности, что фигурирует в ГОСТе (т.е. 1e-4)?
3. "вероятности необнаруживаемого пропуска ошибок" - этот термин какому соответствует в табл. 3 ГОСТа?
4. Как Вы рассчитали, что в 3 раза лучше заголовок защищён? Я смотрю на графики, там для CRC8 для длины 32 байта вероятность неотличима от нуля. Или это для длины в битах? Тогда для графика CRC16 нет данных для длины 2 кБ. В любом случае вижу, что защищённость поля данных никакая...
5. Как вообще трактовать такую вероятность? Это обратная величина от среднего количества пакетов, спустя которые ошибка в одном пакете не будет обнаружена? Например, смотрим на график для CRC8, для значения длины 256 (попугаев), вероятность 2,5e-5. Обратная величина это 40 000. Т.е. правильно ли я понимаю, что, 40 000 пакетов принимаются, если в них появляется ошибка, то она обнаруживается, а потом 40 001-й пакет проходит, и в нём ошибка не обнаруживается? Или как правильно трактовать?
Извиняюсь за глупые вопросы, в этом мои знания неглубоки, а вузовский курс тервера давно благополучно забыт, к сожалению.

Вероятность ошибки обычно считается на бит.
256 - длина блока в битах, то есть 32 байта.

Ну я так и предположил, что в битах. Но для сути 5го вопроса (трактование) это неважно, в каких попугаях измерять

Проблема как раз в другом, и заключается в вопросе - чего вы собственно хотите?
Если у вас есть требования предъявляемые заказчиком - давайте обсудим.
Ели требований нет - тогда можно взять из ГОСТа любые понравившиеся.
Отсюда проблемы в трактовке и анализе уровня помехозащищенности.
На рис. приведены относительные уровни - для того чтобы показать лишь принцип.
Выводов может быть несколько:
1. Нет смысла дробить защиту на заголовок и тело в предложеном виде
2. Если уровня защиты хватит - можно остановиться лишь на общем CRC16
3. Для случая "обычного канала связи" где p=10е-4, P=7.4е-8 (для 2304 бит)
и вы попадаете в 3-ю колонку изделий по ГОСТ 26.205-88 , табл.3
4. Если уровня защиты не хватит - это предмет для обсуждения, но тогда
укажите подробнее о задаче.
5. Если у вас есть желание привести цифры к интенсивностям отказов (1/час)
и т.д. - тема отдельного разговора
6. Здесь все то что не вошло в предыдущие пять пунктов ...

PS. Прошу прощения - не увидел что речь идет именно о 2048 байтах данных,
это уж слишком большой блок для CRC16 по определению....
Вам нужно обратиться к стандарту Ethernet IEEE 802.3 (CRC32) в любом случае.







Сообщение отредактировал i-mir - Apr 29 2011, 06:15

Спасибо за ответы, я для себя в общем-то всё прояснил. Заголовок будем продолжать закрывать CRC8, а а для поля данных изменим CRC16 на CRC32. Тем более, что лишние 2 байта - это ничто по сравнению с 2048 байт, так что не жалко.

У нас бывает, что заголовки передаются без поля данных. Тогда для унификации лучше пусть CRC8 будет в любом случае.

А всё же, по моему списку, не могли бы Вы разъяснить ответы на вопросы 1, 3, 5?

Как ни банально звучит, в чистом виде ответов ни в инете ни в книгах нет.
Теорий и формул много, но на практике, с приемлемой точностью можно
использовать простую комбинаторику. Здесь принимается модель
последовательного канала связи с простейшим потоком ошибок (пуассонов).
Для работы например с ПЛИС, следует использовать другую модель,
где равновероятны любые сочетания и т.д.

После этого CRC тестируется на помехозащищенность заданного блока
данных используя как метод прямого перебора, так и Монте-Карло.
Корректируются теоретические модели (например разные полиномы
CRC8 показывают помехозащищенность отличающуюся на порядки).

Относительно вероятностей - нужно понимать опять-же что вам нужно.
Если задача привести ваш канал связи к уровню стандартов в системах
с повышенной безопасностью (интенсивность 10е-15 1/час), то это одно,
а вот просто сказать - что все ок, это другое. В последнем случае не
заморачиваясь, принимайте CRC32 на базе IEEE 802.3 - это общепринято,
правда для блоков до 1500 байт.

Остальные вопросы заданы в общем виде и слишком объемны для рамок форума.
Чтобы понять какой вам нужен уровень защищенности ответьте на вопрос:
достоточна ли защита блока данных от всех ошибок нечетных кратностей (1х, 3х, 5х ...),
защита от всех ошибок 2х кратности и защита от 129 ошибок из 130 кратности 4х, 6х ... ?
Это уровень обеспечивается CRC8. Под ошибками понимаем инверсию битов в блоке данных.
Пока не понятны ваши критерии оценки, как только они определятся, можно решить
задачу о требуемом протоколе канала связи.

Ладно, сдаюсь, применяем CRC32, и успокаиваемся. Особенно учитывая, что ещё будет снаружи 8B/10B. Остальные вопросы снимаю.

8B/10B больше актуален для оптики в качестве выравнивателя потока 0/1 и имеет слабую помехозащищенность,
в среднем улучшение в 4 раза. Если особых требований нет, то конечно CRC32 + несложная доп. защита наиболее
ответственных блоков данных (поле адреса, поле управления и т.д.) с помощью CRC8.

почитайте сообщение пользователя i-mir, возможно поможет
http://electronix.ru/forum/index.php?showt...%F1%F3%EC%EC%E0