dsPIC에서 PC로 일부 데이터 전송을 수행하고 있으며 오류가 없는지 확인하기 위해 512 바이트의 모든 블록에 대해 8 비트 CRC를 수행하고 있습니다. 내 CRC 코드를 사용하면 약 33KB / s를 얻지 않고 67KB / s를 얻습니다.

더 빠른 대안 오류 감지 알고리즘은 무엇입니까?

CRC보다 빠른 옵션이있을 수 있지만,이를 사용하면 어느 정도의 오류 감지 기능이 손상 될 수 있습니다. 오류 감지 요구 사항에 따라 응용 프로그램에 최적화 된 CRC 코드를 대신 사용할 수도 있습니다.

CRC와 다른 옵션을 비교하려면 Martin Thompson 의 탁월한 답변을 참조하십시오 .

이것을 돕는 하나의 옵션은 pycrc 입니다. pycrc 는 (파이썬 ^1로 작성 ) 수십 가지의 crc 모델 과 알고리즘 조합을위한 C 소스 코드 를 생성 할 수 있습니다 . 이를 통해 다양한 조합을 선택하고 벤치마킹하여 자신의 애플리케이션에 맞게 속도와 크기를 최적화 할 수 있습니다. ^{1 : Python 2.6 이상이 필요합니다.}

그것은 지원 crc-8 모델을 뿐만 아니라, 지원 crc-5, crc-16그리고 crc-32다른 사람의 사이에. 에 관해서는 알고리즘 , 그것은 지원 bit-by-bit, bit-by-bit-fast및 table-driven.

예를 들어 (아카이브 다운로드) :

$ wget --quiet http://sourceforge.net/projects/pycrc/files/pycrc/pycrc-0.8/pycrc-0.8.tar.gz/download
$ tar -xf pycrc-0.8.tar.gz
$ cd pycrc-0.8
$ ./pycrc.py --model=crc-8 --algorithm=bit-by-bit      --generate c -o crc8-byb.c
$ ./pycrc.py --model=crc-8 --algorithm=bit-by-bit-fast --generate c -o crc8-bybf.c
$ ./pycrc.py --model=crc-8 --algorithm=table-driven    --generate c -o crc8-table.c
$ ./pycrc.py --model=crc-16 --algorithm=table-driven   --generate c -o crc16-table.c
$ wc *.c
   72   256  1790 crc8-byb.c
   54   190  1392 crc8-bybf.c
   66   433  2966 crc8-table.c
  101   515  4094 crc16-table.c
  293  1394 10242 total

256 바이트 룩업 테이블을 사용하여 단일 바이트 룩업 대신 듀얼 니블 룩업 (16 바이트 룩업 테이블 사용)을 사용하여 지정하는 것과 같은 펑키 한 작업을 수행 할 수도 있습니다.

예를 들어 (git 저장소 복제) :

$ git clone http://github.com/tpircher/pycrc.git
$ cd pycrc
$ git branch
* master
$ git describe
v0.8-3-g7a041cd
$ ./pycrc.py --model=crc-8 --algorithm=table-driven --table-idx-width=4 --generate c -o crc8-table4.c
$ wc crc8-table4.c
  53  211 1562 crc8-table4.c

메모리와 속도 제한이 주어지면이 옵션은 속도와 코드 크기 사이에서 최상의 절충안 일 수 있습니다. 확실한 유일한 방법은 벤치마킹하는 것입니다.

pycrc의 자식 저장소에 github에 의 한, 이슈 트래커 , 그러나 또한에서 다운로드 할 수 있습니다 소스 포지 .

간단한 1 비트 패리티 (기본적으로 데이터 자체를 반복해서 XOR)는 얻을 수있는 속도만큼 빠릅니다. 그래도 CRC의 많은 오류 검사가 손실됩니다.

의사 코드에서 :

char checksum = 0;
for each (char c in buffer)
{
    checksum ^= c;
    SendToPC(c);
}
SendToPc(checksum);

임베디드 컨텍스트에서 다양한 체크섬과 CRC의 성능을 비교하는 정말 좋은 논문 :

임베디드 네트워크에 대한 체크섬의 효과

발견되지 않은 오류 확률에 대한 연구를 기반으로 결론에서 인용 한 내용은 다음과 같습니다.

버스트 오류가 우세한 경우

XOR, 2의 보수 추가 및 CRC 체크섬은 보수 추가, Fletcher 및 Adler 체크섬보다 더 나은 오류 감지 성능을 제공합니다.

다른 응용 프로그램에서

가능하면“좋은”CRC 다항식을 오류 탐지 목적으로 사용해야합니다.

계산 비용이 매우 제한된 경우

(귀하의 경우와 같이) (효과 순서대로) 사용하십시오.

• 플레쳐의 체크섬
• 보체 추가
• 2의 보수 추가

다른 인용문 :

플레처 체크섬은 애들러 체크섬보다 계산 비용이 낮으며, 일반적인 견해와 달리 대부분의 상황에서 더 효과적입니다.

과

일반적으로 XOR 체크섬을 새로운 디자인에 사용하는 일반적인 관행을 계속할 이유는 없습니다. 왜냐하면 추가 기반 체크섬과 소프트웨어 계산 비용이 같지만 오류를 탐지하는 데 절반에 불과하기 때문입니다.

애들러 체크섬은 송신 왜곡을 확인하기에 충분해야한다. Zlib 압축 라이브러리에서 사용되며 Java 3D 모바일 그래픽 표준에서 채택되어 빠르고 효과적인 데이터 무결성 검사를 제공합니다.

로부터 위키 피 디아 페이지 :

Adler-32 체크섬은 2 개의 16 비트 체크섬 A와 B를 계산하고 비트를 32 비트 정수로 연결하여 얻습니다. A는 문자열의 모든 바이트의 합에 1을 더한 값이고, B는 각 단계에서 A의 개별 값의 합입니다.

Adler-32 실행이 시작될 때 A는 1로, B는 0으로 초기화됩니다. 합계는 모듈로 65521 (2 ^ 16 또는 65536보다 작은 소수)입니다. 바이트는 네트워크 순서 (빅 엔디안)로 저장되며 B는 가장 중요한 두 바이트를 차지합니다.

함수는 다음과 같이 표현 될 수 있습니다

 A = 1 + D1 + D2 + ... + Dn (mod 65521)
 B = (1 + D1) + (1 + D1 + D2) + ... + (1 + D1 + D2 + ... + Dn) (mod 65521)
   = n×D1 + (n-1)×D2 + (n-2)×D3 + ... + Dn + n (mod 65521)

 Adler-32(D) = B × 65536 + A

여기서 D는 체크섬을 계산할 바이트 문자열이고 n은 D의 길이입니다.

CRC만큼 오류 감지에 효과적이며 더 빠르다는 것을 알지 못합니다.있는 경우 사람들이 대신 CRC를 사용합니다.

간단한 체크섬을 시도해 볼 수는 있지만 오류를 감지 할 가능성은 훨씬 낮습니다.

체크섬 논리 자체가 좋고 사람들이 더 빠른 알고리즘을 도울 수 있습니다.

구성 요소의 속도를 향상 시키려면 전체 구성 요소를 변경하여 전송 구성 요소를 유효성 검사 구성 요소와 분리해야합니다.

이들을 두 개의 독립된 항목 (다른 스레드에 있음)으로 사용하는 경우 최대 전송 속도를 얻을 수 있으며 실패한 패킷 만 재전송 할 수 있습니다.

알고리즘은 다음과 같습니다.

• 서버는 알려진 패킷 크기 (1K 청크)로 분류됩니다. "보낼"대기열에 넣습니다.
• 각 패킷은 16 또는 32 비트 ID와 체크섬으로 전송됩니다.
• 클라이언트는 각 패킷을 받아서 처리 할 대기열에 넣습니다.
• 별도의 스레드에서 클라이언트는 한 번에 패킷을 가져와 유효성 검사를 수행합니다.
  • 성공하면 최종 패킷 모음 (ID 순서)에 추가됩니다.
  • 실패하면 실패한 ID를 서버에 다시보고하고, 해당 패킷을 다시 보내도록 재전송합니다.
• 패킷을 수신하고 유효성을 검사하고 올바른 순서 (1부터 시작)의 ID를 갖게되면 디스크에 기록을 시작하거나 필요한 작업을 수행 할 수 있습니다.

이렇게하면 가능한 최고 속도로 전송이 가능하며 패킷 크기로 플레이하면 옵티 엄 실패율 대 유효성 검사 / 재전송 속도를 계산할 수 있습니다.

체크섬은 전통적입니다

(# '+ 스트림 감소)

위에 주어진 XOR도 잘 작동합니다.

(# 'XOR 스트림 감소)

직렬 연결에 대한 표준 패리티 검사는 좀 더 정교하고 느린 구성표입니다.

이 수준에서는 속도에 대한 정확성을 거래하고 있습니다. 이들은 때때로 실패합니다.

다음으로 가장 정교한 수준에서는 crc / hash 유형 항목을 사용할 수 있습니다.

다른 설계는 스트림에 사용되는 블록의 크기를 늘리는 것입니다.

블록 크기에 대한 알고리즘 선택 및 매개 변수를 조정하려면 실제 오류율을 추정해야합니다.