[Krys 2]

Конкретика: мы "от фонаря" порешали, что заголовок пакета специфического устройства размером 32 байта закрываем 8-битовой CRC, а поле данных длиной до 2 кБ закрываем 16-битовой CRC. Теперь, прочитав эту тему, я начинаю покусывать локти, что и там, и там, мы заложили недостаточный размер CRC, т.е. могу предположить, что надо было 16 бит и 32 бита соответственно.

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

[i-mir 0]

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

 

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

Например ГОСТ 26.205-88 КОМПЛЕКСЫ И УСТРОЙСТВА ТЕЛЕМЕХАНИКИ, п.2.11.2.

Укажите согласно ГОСТу требования к вашему устройству на каналы связи.

Если это устройства "критического использования" - то нужно использовать

другие отраслевые документы.

 

После этого можно будет прикинуть помехозащищенность вашего протокола

и его соответствие требованием. Если уровень защиты CRC "в лоб" будет не

высоким, тогда рассматриваются другие типы кодирования.

Скажите в чем необходимость 8B/10B ? Выравнивание потока 0/1 для оптики ?

 

В качестве примера, для очень зашумленного канала (р=10е-3) вероятности

необнаруживаемого пропуска ошибок CRC8/16 привел на рис. Видно что

заголовок у вас защищен в три раза лучше чем поле данных.

Абсолютные значения вероятностей будут зависить от исходных данных

и выбранных вами требований.

_____26_205_88.pdf

Изменено 27 апреля, 2011 пользователем i-mir

[Krys 2]

Уважаемый i-mir, спасибо за конкретную помощь.

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

Например ГОСТ 26.205-88 КОМПЛЕКСЫ И УСТРОЙСТВА ТЕЛЕМЕХАНИКИ, п.2.11.2.

Укажите согласно ГОСТу требования к вашему устройству на каналы связи.

Если это устройства "критического использования" - то нужно использовать

другие отраслевые документы.

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

 

Скажите в чем необходимость 8B/10B ? Выравнивание потока 0/1 для оптики ?

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

 

В качестве примера, для очень зашумленного канала (р=10е-3) вероятности

необнаруживаемого пропуска ошибок CRC8/16 привел на рис. Видно что

заголовок у вас защищен в три раза лучше чем поле данных.

Абсолютные значения вероятностей будут зависить от исходных данных

и выбранных вами требований.

У меня здесь следующие непонятности:

1. Где Вы взяли такие графики? Их считает программа? А Вы могли бы ей поделиться?

2. Может быть, более наглядно было бы построить графики для той же вероятности, что фигурирует в ГОСТе (т.е. 1e-4)?

3. "вероятности необнаруживаемого пропуска ошибок" - этот термин какому соответствует в табл. 3 ГОСТа?

4. Как Вы рассчитали, что в 3 раза лучше заголовок защищён? Я смотрю на графики, там для CRC8 для длины 32 байта вероятность неотличима от нуля. Или это для длины в битах? Тогда для графика CRC16 нет данных для длины 2 кБ. В любом случае вижу, что защищённость поля данных никакая...

5. Как вообще трактовать такую вероятность? Это обратная величина от среднего количества пакетов, спустя которые ошибка в одном пакете не будет обнаружена? Например, смотрим на график для CRC8, для значения длины 256 (попугаев), вероятность 2,5e-5. Обратная величина это 40 000. Т.е. правильно ли я понимаю, что, 40 000 пакетов принимаются, если в них появляется ошибка, то она обнаруживается, а потом 40 001-й пакет проходит, и в нём ошибка не обнаруживается? Или как правильно трактовать?

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

[MrYuran 21]

5. Как вообще трактовать такую вероятность? Это обратная величина от среднего количества пакетов, спустя которые ошибка в одном пакете не будет обнаружена? Например, смотрим на график для CRC8, для значения длины 256 (попугаев), вероятность 2,5e-5.

Вероятность ошибки обычно считается на бит.

256 - длина блока в битах, то есть 32 байта.

[Krys 2]

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

[i-mir 0]

Проблема как раз в другом, и заключается в вопросе - чего вы собственно хотите?

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

Ели требований нет - тогда можно взять из ГОСТа любые понравившиеся.

Отсюда проблемы в трактовке и анализе уровня помехозащищенности.

На рис. приведены относительные уровни - для того чтобы показать лишь принцип.

Выводов может быть несколько:

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) в любом случае.

 

 

 

 

 

 

Изменено 29 апреля, 2011 пользователем i-mir

[Krys 2]

6. Здесь все то что не вошло в предыдущие пять пунктов ... :)

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

 

1. Нет смысла дробить защиту на заголовок и тело в предложеном виде

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

 

6. Здесь все то что не вошло в предыдущие пять пунктов ... :)

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

 

[i-mir 0]

Как ни банально звучит, в чистом виде ответов ни в инете ни в книгах нет.

Теорий и формул много, но на практике, с приемлемой точностью можно

использовать простую комбинаторику. Здесь принимается модель

последовательного канала связи с простейшим потоком ошибок (пуассонов).

Для работы например с ПЛИС, следует использовать другую модель,

где равновероятны любые сочетания и т.д.

 

После этого CRC тестируется на помехозащищенность заданного блока

данных используя как метод прямого перебора, так и Монте-Карло.

Корректируются теоретические модели (например разные полиномы

CRC8 показывают помехозащищенность отличающуюся на порядки).

 

Относительно вероятностей - нужно понимать опять-же что вам нужно.

Если задача привести ваш канал связи к уровню стандартов в системах

с повышенной безопасностью (интенсивность 10е-15 1/час), то это одно,

а вот просто сказать - что все ок, это другое. В последнем случае не

заморачиваясь, принимайте CRC32 на базе IEEE 802.3 - это общепринято,

правда для блоков до 1500 байт.

 

Остальные вопросы заданы в общем виде и слишком объемны для рамок форума.

Чтобы понять какой вам нужен уровень защищенности ответьте на вопрос:

достоточна ли защита блока данных от всех ошибок нечетных кратностей (1х, 3х, 5х ...),

защита от всех ошибок 2х кратности и защита от 129 ошибок из 130 кратности 4х, 6х ... ?

Это уровень обеспечивается CRC8. Под ошибками понимаем инверсию битов в блоке данных.

Пока не понятны ваши критерии оценки, как только они определятся, можно решить

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

 

 

 

[Krys 2]

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

[i-mir 0]

8B/10B больше актуален для оптики в качестве выравнивателя потока 0/1 и имеет слабую помехозащищенность,

в среднем улучшение в 4 раза. Если особых требований нет, то конечно CRC32 + несложная доп. защита наиболее

ответственных блоков данных (поле адреса, поле управления и т.д.) с помощью CRC8.

 

[sisuprun 0]

Доброго времени суток.

Дано: протокольчик связи между устройствами в одномастерной сети. Некое сообщение из, допустим, 4-х байт, защищено CRC7. Поле адреса устройства считается при подсчете CRC7, но реально не передается. Принимающая сторона при приеме сообщения учитывает свой адрес при подсчете CRC, проверяя таким образом валидность.

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

почитайте сообщение пользователя i-mir, возможно поможет :rolleyes:

http://electronix.ru/forum/index.php?showt...%F1%F3%EC%EC%E0