Krys 2 27 апреля, 2011 Опубликовано 27 апреля, 2011 · Жалоба Конкретика: мы "от фонаря" порешали, что заголовок пакета специфического устройства размером 32 байта закрываем 8-битовой CRC, а поле данных длиной до 2 кБ закрываем 16-битовой CRC. Теперь, прочитав эту тему, я начинаю покусывать локти, что и там, и там, мы заложили недостаточный размер CRC, т.е. могу предположить, что надо было 16 бит и 32 бита соответственно. Далее после добавления CRC весь пакет передаётся в канал, закодированный в 8B/10B. Канал связи - не радио, а проводной. Может быть либо медь, либо оптика. Медь - не более 3 метров, LVDS, по UTP. Оптика - до 2 км. По закону распределения ошибок в канале такого типа - сказать ничего не могу, т.к. мои познания в этом малы. Могу довериться вашему опыту. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
i-mir 0 27 апреля, 2011 Опубликовано 27 апреля, 2011 (изменено) · Жалоба По закону распределения ошибок в канале такого типа - сказать ничего не могу Все равно нужно от чего-то оттолкнуться если нет экспериментальных данных. Например ГОСТ 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 28 апреля, 2011 Опубликовано 28 апреля, 2011 · Жалоба Уважаемый 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 28 апреля, 2011 Опубликовано 28 апреля, 2011 · Жалоба 5. Как вообще трактовать такую вероятность? Это обратная величина от среднего количества пакетов, спустя которые ошибка в одном пакете не будет обнаружена? Например, смотрим на график для CRC8, для значения длины 256 (попугаев), вероятность 2,5e-5. Вероятность ошибки обычно считается на бит. 256 - длина блока в битах, то есть 32 байта. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Krys 2 29 апреля, 2011 Опубликовано 29 апреля, 2011 · Жалоба Ну я так и предположил, что в битах. Но для сути 5го вопроса (трактование) это неважно, в каких попугаях измерять Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
i-mir 0 29 апреля, 2011 Опубликовано 29 апреля, 2011 (изменено) · Жалоба Проблема как раз в другом, и заключается в вопросе - чего вы собственно хотите? Если у вас есть требования предъявляемые заказчиком - давайте обсудим. Ели требований нет - тогда можно взять из ГОСТа любые понравившиеся. Отсюда проблемы в трактовке и анализе уровня помехозащищенности. На рис. приведены относительные уровни - для того чтобы показать лишь принцип. Выводов может быть несколько: 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 29 апреля, 2011 Опубликовано 29 апреля, 2011 · Жалоба 6. Здесь все то что не вошло в предыдущие пять пунктов ... :)Спасибо за ответы, я для себя в общем-то всё прояснил. Заголовок будем продолжать закрывать CRC8, а а для поля данных изменим CRC16 на CRC32. Тем более, что лишние 2 байта - это ничто по сравнению с 2048 байт, так что не жалко. 1. Нет смысла дробить защиту на заголовок и тело в предложеном видеУ нас бывает, что заголовки передаются без поля данных. Тогда для унификации лучше пусть CRC8 будет в любом случае. 6. Здесь все то что не вошло в предыдущие пять пунктов ... :)А всё же, по моему списку, не могли бы Вы разъяснить ответы на вопросы 1, 3, 5? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
i-mir 0 2 мая, 2011 Опубликовано 2 мая, 2011 · Жалоба Как ни банально звучит, в чистом виде ответов ни в инете ни в книгах нет. Теорий и формул много, но на практике, с приемлемой точностью можно использовать простую комбинаторику. Здесь принимается модель последовательного канала связи с простейшим потоком ошибок (пуассонов). Для работы например с ПЛИС, следует использовать другую модель, где равновероятны любые сочетания и т.д. После этого CRC тестируется на помехозащищенность заданного блока данных используя как метод прямого перебора, так и Монте-Карло. Корректируются теоретические модели (например разные полиномы CRC8 показывают помехозащищенность отличающуюся на порядки). Относительно вероятностей - нужно понимать опять-же что вам нужно. Если задача привести ваш канал связи к уровню стандартов в системах с повышенной безопасностью (интенсивность 10е-15 1/час), то это одно, а вот просто сказать - что все ок, это другое. В последнем случае не заморачиваясь, принимайте CRC32 на базе IEEE 802.3 - это общепринято, правда для блоков до 1500 байт. Остальные вопросы заданы в общем виде и слишком объемны для рамок форума. Чтобы понять какой вам нужен уровень защищенности ответьте на вопрос: достоточна ли защита блока данных от всех ошибок нечетных кратностей (1х, 3х, 5х ...), защита от всех ошибок 2х кратности и защита от 129 ошибок из 130 кратности 4х, 6х ... ? Это уровень обеспечивается CRC8. Под ошибками понимаем инверсию битов в блоке данных. Пока не понятны ваши критерии оценки, как только они определятся, можно решить задачу о требуемом протоколе канала связи. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Krys 2 3 мая, 2011 Опубликовано 3 мая, 2011 · Жалоба Ладно, сдаюсь, применяем CRC32, и успокаиваемся. Особенно учитывая, что ещё будет снаружи 8B/10B. Остальные вопросы снимаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
i-mir 0 3 мая, 2011 Опубликовано 3 мая, 2011 · Жалоба 8B/10B больше актуален для оптики в качестве выравнивателя потока 0/1 и имеет слабую помехозащищенность, в среднем улучшение в 4 раза. Если особых требований нет, то конечно CRC32 + несложная доп. защита наиболее ответственных блоков данных (поле адреса, поле управления и т.д.) с помощью CRC8. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sisuprun 0 10 августа, 2011 Опубликовано 10 августа, 2011 · Жалоба Доброго времени суток. Дано: протокольчик связи между устройствами в одномастерной сети. Некое сообщение из, допустим, 4-х байт, защищено CRC7. Поле адреса устройства считается при подсчете CRC7, но реально не передается. Принимающая сторона при приеме сообщения учитывает свой адрес при подсчете CRC, проверяя таким образом валидность. Я понимаю, что передать сообщение в виде (адрес)-(данные)-(CRC) или (данные)-(CRC) - это две большие разницы. Кто в теме, подскажите, чем можно оценить вероятность приема ложного сообщения во втором случае. почитайте сообщение пользователя i-mir, возможно поможет :rolleyes: http://electronix.ru/forum/index.php?showt...%F1%F3%EC%EC%E0 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться