1,000 バイトごとのデータ ユニットを送信するという仮定の状況があります。失敗率はまれですが、エラーが発生した場合、単一ビット エラーである可能性は低く、連続した数ビットのエラーである可能性が高くなります。
最初はチェックサムを使おうと思ったのですが、1ビット以上のビットエラーを見逃す可能性があるようです。パリティ チェックも機能しないため、CRC が最適なオプションである可能性があります。
1000 バイトの巡回冗長検査は効率的ですか? または、よりうまく機能する他の方法はありますか?
1,000 バイトごとのデータ ユニットを送信するという仮定の状況があります。失敗率はまれですが、エラーが発生した場合、単一ビット エラーである可能性は低く、連続した数ビットのエラーである可能性が高くなります。
最初はチェックサムを使おうと思ったのですが、1ビット以上のビットエラーを見逃す可能性があるようです。パリティ チェックも機能しないため、CRC が最適なオプションである可能性があります。
1000 バイトの巡回冗長検査は効率的ですか? または、よりうまく機能する他の方法はありますか?
巡回冗長検査(CRC)は、複数のビットエラーを保証された精度で検出する効率のために特に人気があります。
CRC多項式を生成するためのさまざまな設計がありますが、トレードオフは精度と計算の複雑さです。あなたの場合、精度の要件を満たす「最速」のものを選択できます。
巡回冗長検査に関するこのウィキペディアの記事から始めることをお勧めします。
CRC については、こちらの別の質問で説明され
ています。
ランダムエラーの検出に適しており、実装が容易です。
CRC を使用するのが普通です。「効率」が何を意味するのかはわかりませんが、CRCがハードウェア(イーサネットカードなど)に実装されている場合があると思います。そうしないと、「最適化された」実装が見つかる場合があります (ルックアップ テーブルを使用)。
ディスクセクターの大きさは? おそらく少なくとも 512 バイトです。また、CRC は、ハードウェア レベルのディスク ECC の伝統的なスキームです。
標準の CRC 多項式アルゴリズムは、少数のビット エラーに対して非常に効果的です。正確な精度は数学的に計算可能です。CRC は、比較的少数のゲートとシフト レジスタでオンザフライでジョブを管理できるハードウェアで実行することも非常に効率的です。