freepascal.ru

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

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

mirk писал(а):Но как выбрать нужный размер?

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

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

olegy123 писал(а):Странно, почему моего ответа нет..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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