CRC32 값을 16 또는 8 비트로 줄이기

메시지 프레임 구성에서 CRC 오류 감지로 패킷을 보호하려고합니다. 이러한 패킷은 TCP 연결을 통해 전송됩니다.CRC32 값을 16 또는 8 비트로 줄이기

길이가 16 바이트보다 작은 작은 패킷의 경우 CRC8을 선택합니다. 4096 바이트보다 작은 패킷의 경우 CRC16 알고리즘. 큰 패킷의 경우 CRC32 알고리즘.

가장 매력적인 CRC 구현은 현재 하드웨어 지원 (적어도 일부 Intel CPU의 경우) 때문에 CRC32C입니다. 그러나 8 비트 및 16 비트 CRC에 대한 특별 지침은 없습니다.

내 질문이 있습니다 : CRC32C 알고리즘의 32Bit 값을 기본 CRC16 또는 CRC8 알고리즘과 비교하여 오류 탐지 성능을 저하시키지 않으면 서 16 비트 또는 8 비트 값으로 줄일 수 있습니까?

예 :

char buffer[256]; 
... 
uint32_t crc32 = compute_crc32c_of_block(buffer, 256); 
uint16_t fake_crc16 = (crc32 >> 16)^crc32; 
uint8_t fake_crc8 = (fake_crc16 >> 8)^fake_crc16;

실제 CRC8 구현 등 fake_crc8 좋은가요?

미리 감사드립니다.

출처

2014-03-12 Markus Fangerau

흥미로운 질문입니다. 페이로드 크기를 3 바이트 줄이면 투자 수익이 발생합니까? 특별한 경우 처리 (다른 구조체 정의가 있다고 가정), dword 정렬 대신 바이트 정렬 등의 런타임 영향을 고려하십시오. –

예, 패킷은 바이트 단위로 정렬되지만 멤버의 내부 오프셋은 해당 데이터 형식의 요구 사항에 맞춰 정렬됩니다. 헤더 압축을 사용하면 일부 (대부분 시그널링) 패킷이 2 바이트만큼 작게 축소 될 수 있습니다. 추가로 4 바이트 검사 값을 사용하면 약간 과장된 것으로 보입니다. 프로토콜은 느린 모바일 연결, 즉 실제 페이로드에 대해 모든 대역폭을 제공해야하는 GSM에서 사용하기 위해 최소한의 프레이밍 오버 헤드를 부과해야합니다. –

32 비트 CRC의 하위 8 비트는 8 비트 CRC와 같은 양호한 오류 정정 특성을 갖지 않을 것이다. 버스트 오류를 확인하는 보증. 그러나 노이즈 소스의 특성에 따라 애플리케이션에 충분할 수 있습니다. 실제 위치에서 상관 관계가있는 비트 오류가 많으면 실제 CRC를 사용해야합니다. 드물게 비트 플립 또는 많은 심각한 오류가있는 경우 CRC의 일부는 마찬가지로 잘 작동합니다.

수행 방법을 테스트하기위한 대용품이 없습니다.

출처

2014-03-12 15:36:24

낮은 8/16 비트를 사용하는 것에 대한 제안에 감사드립니다. 이것은 XOR 접기에 의한 감소보다 더 좋거나 더 좋을 수 있습니다. 일반적으로 응용 프로그램 수준 프로토콜에 도달하기 전에 TCP/IP 또는 링크 계층 오류 감지로 오류 데이터를 처리해야하기 때문에 오류가 없어야합니다. 그러나 중요한 의학적 상황에서 데이터 무결성을 위해 TCP 스택에 의존 할 수는 없으므로 CRC는 마지막 수신 단계에서 전송 오류를 감지하는 데 유용한 도구로 보입니다. –

CRC32 값을 16 또는 8 비트로 줄이기

답변

관련 문제