Diskussion:Zyklische Redundanzprüfung

Zum Archiv

Automatische Archivierung

Auf dieser Seite werden Abschnitte halbjährlich automatisch archiviert, deren jüngster Beitrag mehr als 175 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 3 Abschnitte.

Polynomtabelle

Die Zerlegung der Polynome in Produkte von Polynomen ist falsch. Erwiesen falsch ist die Zerlegung vom Bluetooth und vom CAN. Es liegt nahe, dass weitere Fehler vorliegen. (nicht signierter Beitrag von 141.76.96.114 (Diskussion) 09:34, 28. Jul 2015 (CEST))

Kommentar: Die Zerlegung der Polynome wird mit "Bitlogik" gehandhabt. So wird ein x^4 + x^4 zu 0 - Ich sehe das Problem also nicht

Nicht belegte Aussage

Die Aussage "Im Idealfall kann das Verfahren sogar die empfangenen Daten selbständig korrigieren, um eine erneute Übertragung zu vermeiden." ist durch keine Quelle belegt und meines Erachtens falsch (ich lasse mich gerne eines Besseren belehren).

Ich stimme dem zu, denn um einen Fehler in einer Übertragung zu korrigieren müsste die Nachricht nicht länger als die CRC sein und gleichzeitig müsste man wissen was bei der Übermittlung verfälscht wurde. CRC, Nachricht oder gar beides. (nicht signierter Beitrag von 2003:CC:9F14:2700:A0B4:5903:60D4:A021 (Diskussion) 19:36, 15. Feb. 2024 (CET))

Beim Lesen bin ich auch an der Aussage hängen geblieben, jedoch sie ist vermutlich richtig. Aber sie ist irreführend da ich vermute, dass es nirgends gemacht wird. Wenn die Nachricht nur kurz genug ist, wird es zwangsläufig solche Fehler geben, die nach einem ausreichend schwachen Kriterium korrigierbar sind. Das allgemeine Problem bei der Korrektur ist, dass man nie weiß ob wirklich nur ein Bit falsch war. --Moritzgedig (Diskussion) 20:27, 7. Mär. 2024 (CET)

Umsetzung

Der Pseudocode ist meiner Meinung nach falsch. Ich habe gerade einen CRC7 für sd-Karten geschrieben und getestet und der sieht etwas anders aus. Abgesehen davon ist die verwendete Formulierung unverständlich wenn man den Algorithmus nicht schon kennt. Bitte um Überarbeitung des Pseudocodes.

CRC-CCITT

16-Bit CRC-CCITT fehlt im Artikel, wobei CCITT für Comité Consultatif International Télégraphique et Téléphonique steht, weil es davon für zahrleiche Applikationen, darunter Datenaustauschprotokolle (engl. data-transfer protocols), Computer-Interface-Fehlererkennung (engl. computer-interface error detection), vorgeschlagen wurde.^gb Das CCITT, heute als International Telecommunication Union bzw. ITU bekannt, ist also Namensgeber von CRC-CCITT.

Warum ist das vielleicht wichtig? Weil im Artikel zwar CRC-CCITT vorkommt, es aber nicht erklärt wird. Auch interessant: CRC-CCITT ist das CRC-Verfahren auf Disketten,^gb genauer gesagt bei einem Sektor, der auf dem Speichermedium selbst aus mehr Daten als dem Datenblock ("Sektor" aus Software-Sicht) besteht: Der Disketten-Controller (für Diskettenlaufwerke) und auch der Festplatten-Controller (für Festplattenlaufwerke) speichert nicht nur einen 512-Byte-Datenblock als "Sektor" ab (bei modernen 4k-Sektoren einen 4096-Byte-Datenblock), sondern zusätzliche Informationen, darunter z.B. ein Adressfeld (welcher Sektor ist es, der gerade gelesen wird) und im Datenfeld ein DAM (data address mark), danach die Daten, die im Sektor gespeichert werden sollen, gefolgt von Prüfbytes (CRC/ECC).^gb Als CRC (nicht ECC), ob nun im Adressfeld oder im Datenfeld, wird hier laut dem Google-Buch Mikrorechner-Systeme: Mikroprozessoren, Speicher, Peripherie, von Helmut Bähring, eben CRC-CCITT verwendet – laut oben verlinktem Google-Buch "Error-Control Coding for Data Networks" ist CRC-CCITT "an error-detecting signature with 16 cyclic-redundancy check bits."

Wenn sich CRC-CCITT also auf jeder Diskette und Festplatte befindet (bei modernen Festplatten weiß es keiner mehr – Industriegeheimnis), sollte das vielleicht in den Artikel.

Hinzu kommt, dass Schlagwörter wie die im Linux-Kernel implementierten CRC-Verfahren fehlen:

CONFIG_CRYPTO_CRC32C:
CRC32c CRC algorithm with the iSCSI polynomial (RFC 3385 and RFC 3720)

A 32-bit CRC (cyclic redundancy check) with a polynomial defined
by G. Castagnoli, S. Braeuer and M. Herrman in "Optimization of Cyclic
Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE Transactions
on Communications, Vol. 41, No. 6, June 1993, selected for use with
iSCSI. Castagnoli, et al Cyclic Redundancy-Check Algorithm.  Used
by iSCSI for header and data digests and by others.

Used by btrfs, ext4, jbd2, NVMeoF/TCP, and iSCSI.

CONFIG_CRYPTO_CRC32:
CRC32 CRC algorithm (IEEE 802.3)

Used by RoCEv2 and f2fs.

CONFIG_CRYPTO_CRCT10DIF:
CRC16 CRC algorithm used for the T10 (SCSI) Data Integrity Field (DIF)

CRC algorithm used by the SCSI Block Commands standard.

CONFIG_CRYPTO_CRC64_ROCKSOFT:
CRC64 CRC algorithm based on the Rocksoft Model CRC Algorithm

Used by the NVMe implementation of T10 DIF (BLK_DEV_INTEGRITY)

See https://zlib.net/crc_v3.txt

Hinzu kommen einige spezieller CRC-Bibliotheken des Linux-Kernels, die von Treibern (Kernel-Modulen) verwendet werden können. Darunter:

CONFIG_CRC_CCITT:
This option is provided for the case where no in-kernel-tree
modules require CRC-CCITT functions, but a module built outside
the kernel tree does. Such modules that use library CRC-CCITT
functions require M here.

Aber auch CRC4, CRC7, CRC8 und etwas das "CRC ITU-T V.41" genannt wird:

CONFIG_CRC_ITU_T:
This option is provided for the case where no in-kernel-tree
modules require CRC ITU-T V.41 functions, but a module built outside
the kernel tree does. Such modules that use library CRC ITU-T V.41
functions require M here.

Nun kenne ich mich leider mit Zyklischer Redundanzprüfung und den diversen unterschiedlichen Verfahren leider nicht wirklich aus. Ich weiß nur, dass das mit der Allgemeinverständlichkeit wohl etwas schwer herzustellen sein wird, wenn die Thematik selbst so schwer ist (höhere Mathematik). Aber zumindest sollten die "Buzzwords" enthalten sein: neben CRC32 also auch CRC32c bzw. Castagnoli, und eben auch CRC-CCITT.

‣Andreas•⚖ 21:50, 5. Nov. 2023 (CET)

Alles richtig was du schreibst. Der Artikel über CRC lässt leider unerwähnt, dass manche CRC die Bits eines Bytes des Datenstroms umdrehen (RefIn). Dann gibt es noch Varianten die die Bits des errechneten CRC Wert umdrehen (RefOut). Eine ausführliche Tabelle gibt es hier: https://reveng.sourceforge.io/crc-catalogue/all.htm Vollständig ist diese Liste wahrscheinlich auch nicht... Die Namen der CRCs sind auch nicht standardisiert und werden gerne durcheinandergewürfelt (insb. wegen RefIn und RefOut). --2003:CC:9F14:2700:A0B4:5903:60D4:A021 19:44, 15. Feb. 2024 (CET)