Выбор CRC

[mirk]

Есть куча возможных размеров CRC - 8, 10, 16, 24, 32 и наверное еще куча других.
Но как выбрать нужный размер?
Может есть табличка для какого размера блока данных какой размер CRC?

[olegy123]

Странно, почему моего ответа нет..

Но как выбрать нужный размер?

если для себя, то чем больше размер члена CRC тем естественно луче.. меньше коллизий, меньше нарваться на дубликат CRC.

А если нужно работать с чужими механизмами то там этот размер строго оговаривается..

[mirk]

Странно, почему моего ответа нет..

Был удален, ибо флуд

если для себя, то чем больше размер члена CRC тем естественно луче.. меньше коллизий, меньше нарваться на дубликат CRC.

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

Вот возьмем пример IP - там CRC 2 байта и только для заголовка.
В UDP тоже есть CRC 2 байта, но уже для заголовка с данными - а это может быть уже до 1.5 кб в обычном режиме и как минимум до 8к в режиме Jumbo Frame.
Вот хватит ли этих 2 байт для 1.5кб? А хватит ли для 8кб?
Может надо 4? А может 8? А может еще больше? Так сколько же надо?

[Снег Север]

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

[iskander]

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

[mirk]

Хотелось бы верить, что проблема выбора размера CRC лежит все-таки в сфере связи, а не программирования.

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

[serbod]

кроме числа битов ещё имеет значение полином и методика подсчета. В целом, 8 бит очень слабая CRC, даже для коротких посылок до 12 байтов даёт коллизии. 16 бит уже вполне норм для пакетов в несколько кбайт, но там десятки вариантов, нужно проверять их на совместимость. А CRC32 самая распространенная и вполне стандартная, реализована в железе.

[mirk]

8 отбрасывем, остается 16 и 32.
Для мелких посылок (до 1.5 кб) можно легко пользоваться как я понимаю 16 битами.
А вот с 1.5 до 8-9 кб хватит 16 бит или уже надо 32?

[Vadim]

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

[vada]

Стоит обратиться к информации 90-х годов. Период расцвета FidoNET
https://bourabai.ru/telecom/9.htm

Связь по медной телефонной паре была не ахти какая. Помехи, качество линий, наводки,... Но это все работало.

Ну и про гидру
https://docplayer.ru/90046438-Hydralink ... gidra.html

[mirk]

Если сильно хочется сэкономить, то можно использовать банальный бит чётности.

Это не позволит надежно определять наличие ошибки.

Связь по медной телефонной паре была не ахти какая. Помехи, качество линий, наводки,... Но это все работало.

Там размер пакета в большинстве случаев 128 байт, и максимум 1к.
С этим все уже понятно - 16 бит достаточно, а вот хватит ли 16 для больших объемов?

[serbod]

Для пакета в 100 байтов, CRC32 это всего лишь 4% оверхеда. А для 1000 байтов 0.4%
Но при этом CRC32 практически полностью исключает вероятность коллизии.

[ev]

еще можно добавить, что CRC32C аппаратно может ускоряться на современных процессорах

[Vadim]

еще можно добавить, что CRC32C аппаратно может ускоряться на современных процессорах

На всех? Или каких-то специальных, типа как в телевизоры вставляют?

[iskander]

Если правильно путаю, инструкция CRC32 появилась в SSE4.2