Diskussion:Fehlerkorrekturverfahren

sehr alter beitrag

Also, ich verstehe Error-Correcting-Codes etwas allgemeiner als das Verfahren, welches auf RAM-Chips eingesetzt wird. Z.B. gehören m.E. auch reed solomon etc. zu den error correcting codes.

Bin ich der gleichen Ansicht. ECC steht AFAIK ganz allgemein für Fehlerkorrekturverfahren. Was hier beschrieben wird (kann 1 bit wiederherstellen etc.) bezieht sich IMHO auf ein spezielles Verfahren, das in RAM-Bausteinen verwendet wird. Und mit Elliptic Curve Cryptography hat das ganze (ausser, dass es die gleiche Abkürzung ist) auch nichts zu tun. Ich werde mich in den nächsten Wochen mal mit diesem Artikel befassen, falls mir niemand zuvorkommt.

Sollte man nicht ohnehin mal bei der Gelegenheit den Artikel nach Fehlerkorrekturcode (bzw. -kode) verschieben? Sind hier ja nicht in England :-) Stern 21:11, 7. Jul 2004 (CEST)

halte diese ecc-beschreibung auch fuer bloedsinn. ecc ist der englisch-sprachige begriff fuer fehlerkorriegerender code. nebenbei: um 1 fehler zu korrigieren gibts den perfekten (im sinne der raumabdeckung) hamming code. mein vorschlag ist eine liste von codes welche zur kanalcodierung eingesetzt werden, anzulegen (also z.b. erst mal die von Kanalcodierung extrahieren und auf eine eigene seite stellen). in dem gesamten bereich herrscht ja noch teilweise chaos, siehe die ueberschneidungen Kanalcodierung, Vorwärtsfehlerkorrektur, Kodierung, Codierungstheorie und was weiss ich noch alles ....

Ich habe mal aufgeschrieben, wie ich einen Artikel über das Thema Fehlerkorrektur gliedern würde (dabei habe ich bestimmt immer noch einiges vergessen). Mir ist aber dabei immer noch völlig unklar, was eine WP ist. Eher eine Liste von Artikeln (mit allen damit verbundenen Nachteilen) oder ein etwas größerer Artikel (mit dem Hauptnachteil, das nicht zu jedem Teilthema eine separate Beschreibung existiert). --Frank Klemm 15:04, 22. Nov 2004 (CET)

erstens: schoen das mal einer was macht. zweitens: kritik :-) ich selber kenne nur zwei fehlerkorrekturprinzipien als da waeren die Kanalcodierung (vorwaertsfehlerkoorektur) und die ARQ-Protokolle (rueckwaertsfehlerkorrektur). meinetwegen noch die mischung a la hybrid arq. deswegen sollte man hier nicht alles wiederholen sondern lieber diese beitraege ausbauen und hier nur etwas ueber beide prinzipien (dann mit link) verlieren. an dem bestehenden rumpf haette ich dann noch folgende kritik: a) redundanz - es werden codebits und keine datenbits angefuegt b) fehlerbursts - der deutsche begriff ist wohl eher buendelfehler c) hamming abstand existiert auch schon als eigener artikel. by the way wird die hamming distanz heute als nicht mehr so wichtig angesehen. fuer die iterative decodierung ist das distanzspektrum viel wichtiger. d) hybridverfahren aus codierung und fehlerkorrektur ? ist doch das gleiche? e) codespreizung - kann nicht zur fehlerkorrektur (topic) herangezogen werden. btw: liefert diversitaets, aber keinen keinen codiergewinn. f) fehlerverdeckung ist schoen fuer siehe auch - aber verdeckung ist eben nicht korrektur (topic) g) technische beispiele: nett aber wieso nicht historisch? deep space, cd, gsm ... Huschhusch 15:57, 22. Nov 2004 (CET)

nachtrag: auch wenns eigentlich nicht hierher gehoert - der redirect Kodierung gefaellt mir nicht. zum einen weil er wie kot mit k geschrieben ist :-) und zweitens moechte man wohl nicht bei code landen. waere es nicht sinnvoller eine uebersichtsseite zu erstellen mit links zu Leitungscode (also das manchester, nrz ... geraffel) und Kanalcodierung? Huschhusch 16:03, 22. Nov 2004 (CET)

nachtrag zum nachtrag: vielleicht doch auf code weiterleiten, dann aber auf die seite Code (Begriffsklärung). dort muesste man mal aufraeumen - unter kanalcodierung stehen morse und ascii und huffman (quellencodes!!!!). dann noch unmotiviert RS mit link auf das synonym vorwaertsfehler .... leitungscode sind gar nicht erwaehnt. dafuer endlich mal ein hinweis auf die verwendung von c statt k :-) Huschhusch 16:12, 22. Nov 2004 (CET)

Seite Code (Begriffsklärung) und Code sind nicht korrigierbar, da sitzt jemand auf seinem Lieblingscode drauf und reinstalliert immer wieder seine Meinung. Ansonsten kannst Du in diesem Artikel Ideen erst mal direkt reinschreiben. Kaputtmachen kann man da nicht viel.--Frank Klemm 20:55, 23. Nov 2004 (CET)

--- > ich selber kenne nur zwei fehlerkorrekturprinzipien als da waeren die Kanalcodierung (vorwaertsfehlerkoorektur)

Ja, das ist Methode 1

> und die ARQ-Protokolle (rueckwaertsfehlerkorrektur).

Die gibt es in 2 Versionen. Opt-In und Opt-Out. Empfänger muß sich bei Fehler rühren oder Empfänger quitiert ordnungsgemäße Pakete mit einer positiven (und defekte mit einer neativen Antwort).

>>o.k. aber das sind doch nur protokollaspekte, ob das nun durch time-out oder explizite signalisierung geschieht ist doch erst mal sekundaer

> meinetwegen noch die mischung a la hybrid arq.

?

Vorwärtsfehlerkorrektur + Rückwärtsfehlerkorrektur sind orthogonal, können beliebig kombiniert werden. Auch möglich ist adaptive Vorwärtsfehlerkorrektur, das je nach Fehlerrate die Robustheit und Latenzzeit des Signals moduliert.

>>auch o.k. die sogenannte link adaptation (LA) wechselt zwischen verschiedenen modulation and coding (MCS) schemes. aber durch eine robustere modulation werden keine fehler korrigiert sondern vermieden

> deswegen sollte man hier nicht alles wiederholen sondern lieber diese beitraege ausbauen und hier nur etwas ueber beide prinzipien (dann mit link) verlieren.

Ich müßte erst mal wissen, was es an ähnlichen Artikeln schon gibt. Einiges habe ich schon gefunden. Steht am Ende.

> an dem bestehenden rumpf haette ich dann noch folgende kritik: > a) redundanz - es werden codebits und keine datenbits angefuegt > Die Datenmenge wird erhöht. Im strengen mathematischen Sinn macht es keinen Sinn, zwischen Daten- und Korrekturbits zu unterscheiden. Es gibt keinen Unterschied zwischen beiden, es gibt nur isomorphe Abbildungen, in der gewisse Bits des zu übertragenden Vektors mit den Datenbits übereinstimmen.

>>stimmt zwar aber wenn der begriff redundanz verwendet wird ist damit eben nur die "ueberschuessige" information gemeint, egal ob eine unterscheidung sinn macht

> b) fehlerbursts - der deutsche begriff ist wohl eher buendelfehler Huch, frag' mich nicht, wie das im Deutschen heißt. Die meisten reden von Burstfehlern.

>>naja, hier regen sich schon einige auf wenn man codieren mit c schreibt. by the way ist copmact dis-k jetzt schon die kroenung des ganzen (siehe artikel :-)

> c) hamming abstand existiert auch schon als eigener artikel. Gefunden. Link im Text drauf ist am sinnvollsten.

> by the way wird die hamming distanz heute als nicht mehr so wichtig angesehen. fuer die iterative decodierung ist das distanzspektrum viel wichtiger. Würde mich sinnvolle Literatur interessieren. Eine gewisse Mindesthammingdistanz sollte auch bei ausgefeilten distanzspektrum-Codes sinnvoll sein.

>>ups, wollte eigentlich mindest (hamming) distanz schreiben. ist mir wohl ein fehler passiert. fakt ist, das der error floor bei iterativer decodierung von der anzahl der mindestgewichtigen codeworte abhaengt. also, wenn es ein paar unguenstige konstellationen gibt, aber der anteil nur 10 hoch -15 ist, dann ist das normalerweise ausreichend - alles ist eben relativ ....

> d) hybridverfahren aus codierung und fehlerkorrektur? ist doch das gleiche? Hybridverfahren aus Modulation und Fehlerkorrektur.

>>das hoert sich schon besser an

Die Modulation liefert Informationen über die Qualität des Signals.

>>sagen wir die demodulation; und sie liefert nicht nur information ueber die qualitaet sondern sie liefert die information schlechthin

• Trelliskodierung (Modem)

>>bitte - trelliscodierung, dann meinetwegen TCM, BICM, MLC ...

• EFM

> e) codespreizung - kann nicht zur fehlerkorrektur (topic) herangezogen werden. Ohne Codespreizung würde in der Praxis keine Fehlerkorrektur funktionieren. Eine ausgeklügelte Codespreizung ist teilweise wichtiger als eine ausgeklügelte Fehlerkorrektur.

>>ich sage nicht das cdma nicht gut ist (obwohl ... :-)

> btw: liefert diversitaets, aber keinen keinen codiergewinn. Liefert keinen Codiergewinn auf Systemen mit rein statistischen Störungen. Sobald andere Störungen hinzukommen (was in der Theorie meist nicht betrachtet wird, weil man das analytisch schlecht berechnen kann), erhält man einen Gewinn.

>>ich bleib dabei, wenn du mit einer pn-sequenz oder hadamard oder was auch immer spreizt (wiederholungscode) bekommst du keinen codiergewinn. egal fuer welchen (mal vorsichtshalber gedaechtnislosen) kanal. lediglich ein diversitaetsgewinn - welcher ja auch nicht schlecht sein muss - laesst sich erzielen

> f) fehlerverdeckung ist schoen fuer siehe auch - aber verdeckung ist eben nicht korrektur (topic) Ich weiß. Die meisten Systeme sind aber so ausgelegt, daß auch Fehlerverdeckung zu brauchbaren Ergebnissen und nicht zum "Supergau" führt.

>>die meisten? sagen wir manche ... trotzdem: verdeckung != korrektur und nochmal trotzdem: einen verweis find ich ja auch ganz nett ...

> g) technische beispiele: nett aber wieso nicht historisch? deep space, cd, gsm ... Trag' es doch einfach ein. Das ganze ist ein Gerüst oder Gerippe zum Ideensammeln. Ich gehöre eher zu denen, die solche Gerippe langsam "füttern". Also nicht gelich was fertiges erwarten.

>>genau das ist ja mein problem. wieso soll ich hier ideen zur kanalcodierung bzw. zu den arq-protokollen sammeln. das kann ich doch dort bei den artikeln machen. ich vermisse die struktur die dem topic gerecht wird. nicht nur in diesem artikel. ich versteh auch nicht wieso wir zusaetzlich zum artiklel kanalcodierung noch einen artikel Vorwärtsfehlerkorrektur brauchen. es gibt doch auch keine dopplung bei kfz, auto, ... (oder doch? :-) Huschhusch 11:57, 24. Nov 2004 (CET) (wie auch die anderen inline kommentare)

RAM

Was ist/war das für eine unfassbare Ruine? Und wer hat da bitteschön, da er schon gemerkt hat das die ALLERERSTE VERSION DES GESAMTEN ARTICKELS(! penlich genug) viel besser und informativer (und vorallem weniger satzruinös) ist, und dann diese Version als Kommentar eingefügt hat? } --213.168.121.5 00:22, 6. Okt 2005 (CEST)

Benutzer 213.168.121.5 spricht in Rätseln. Wo ist dieser Kommentar? Welche ist denn die besagte "allererste Version"? Die vom 11.01.2004 kann es ja wohl nicht gewesen sein, da fast bloßes Gerüst resp. Stub... --Yanestra 06:53, 27. Okt 2005 (CEST)

vergleiche diese apssage (aus der allerersten version)

Version vom 16:42, 11. Jan 2004 Das ECC-Verfahren (Error Correction Code) beschreibt einen Fehlerkorrektur-Algorithmus der im Gegensatz zur Paritätsprüfung in der Lage ist einen 1-Bit-Fehler zu korrigieren und einen 2-Bit-Fehler zu erkennen. Das ECC-Verfahren benötigt auf 32 Bit 7 Check-Bits und auf 64 Bit 8 Check-Bits. Das ECC-Verfahren wird häufig in Speicherbausteinen für Serversysteme eingesetzt, die eine besonders hohe Datenintegrität benötigen. siehe auch: Hamming-Code, CRC, MD5, Parität, Prüfsumme

mit dieser, vor dem edit von 213.168.121.5

Version vom 11:32, 28. Sep 2005; RAMs gelten zwar als sehr zuverlässige Datenspeicher, allerdings kann es in Anwendungen mit hoher Zuverlässigkeit ... Weiterhin werden die Bausteine durch die Miniaturierung und Erhöhung der Taktrate immer empfindlicher auf ... Der klassische PC/XT und PC/AT nutzt eine Fehlererkennung zum Erkennen von Einzelbitfehlern im RAM. Zum Speichern von 8 bits werden insgesamt 9 Speicherzellen genutzt, die ... In modernen PCs werden die 64 Datenbits und die 8 Paritätsbits für einen H=4 ... In einigen Servern (Sun) werden die 128 Datenbits und die 16 Paritätsbits für einen H=5 ...

beides der abschnitt über Rams, der irgendwann auskommentiert wurde. Urdar 18:48, 28. Okt 2005 (CEST)

Überarbeiten

Der Artikel hat zwar eine ausgearbeitete Gliederung, aber in vielen Absätzen stehen nur Stichworte. Fink 10:54, 29. Mär 2006 (CEST)

2.2 Bündelfehler (auch Blockfehler, oder engl. Error Bursts)

2.3 Synchronisationsfehler

3 Fehlererkennung

3.1 Hamming-Distanz und Berechnung

3.2 Beispiele

auszulagern als (bisher BKL) "Fehlererkennung" und hier aufzurufen - die letzten Kapitel

4 Fehlerkorrektur

4.1 Vorwärtsfehlerkorrektur

4.1.1 Fehlerkorrekturcodes

4.1.2 Vor- und Nachteile

4.1.3 Hybridverfahren aus Modulation und Fehlererkennung/-korrektur

4.1.4 Grenzen

4.2 Codespreizung

4.3 Fehlererkennende und -korrigierende Codes

5 Fehlerverdeckung

5.1 Robuste Datenstrukturen

5.2 RAM - ECC- und Paritätsprüfung

5.3 Compact Disc (CD)

5.4 ADSL

verbleiben dann in diesem Artikel, der anstelle der ersten drei Kapitel die Fehlererkennung aufruft --SonniWPDisk. 08:32, 14. Sep. 2007 (CEST)

Dabei müßte auch der Artikel RAID überarbeitet werden, weil dessen Behandlung von Fehlerursachen und ähnlichem die hier auszugliederden Kapitel nutzen kann. Ich überseh noch nicht, wie die Teile mit dem vorgeschlagenen Konzept eingegliedert werden können. --SonniWPDisk. 08:40, 14. Sep. 2007 (CEST)

kein klares Konzept

Auch die Kat "Digitaltechnik" passt hier zwar her, schließt aber die Richtigkeit der interwikis aus, eigentlich sollte es einen Artikel "fehlerkorrigierende codes" geben, der ein großer teilbereich der allg. kodierungstheorie ist. Viele Links diesbzgl. führen hierher - was aber gar keinen Sinn macht... wenn sich mal jemand erbarmen könnte, wie oben angedeutet gibt es hier sehr viel zu tun.... Grüße --WissensDürster 11:06, 25. Jun. 2009 (CEST)

einfachere Erklärung

Ich finde, bevor es in komplizierte Details geht, sollte ein Text in die Problematik einführen, der für Normale Leser verständlich ist.--Hans Eo 05:40, 21. Jun. 2010 (CEST)

Fehlererkennung in der Automatisierungstechnik vs. Informatik

Man wird bei der Suche nach "Fehlererkennung" auf diesen Artikel weitergeleitet. Fehler gibt es aber nicht nur in der Informationstechnik sondern auch in der Produktion/QS/beliebige Abläufe. Da muss eine Begrifferklärung dazwischen und ordentlich verlinkt werden. (nicht signierter Beitrag von 217.237.186.107 (Diskussion) 10:10, 27. Jul 2010 (CEST))

http://pi1.informatik.uni-mannheim.de/filepool/publications/fehlererkennung-und-fehlerdiagnose-f-r-verl-ssliche-systeme-automatisierungstechnik-vs-verteilte-systeme.pdf führt in die Überschneidung aus Sicht der Informatik ein --79.240.219.111

fachliche Fehler

5.1 ECC- und Paritätsprüfung

Eine allgemeine Angabe von Fehlerkorrektureigenschaften ist einfach nicht möglich. Hier wird falsche Information verbreitet

5.3 CD

Ein Codierungsverfahren explizit an dieser Stelle auszuführen erscheint mir komisch - Eigentlich gehört dieser Absatz in den mit dem Artikel CIRC zusammengeführt.

-- Ziykuna 11:45, 29. Jan. 2012 (CET)

fachliche Fehler beim Hamming Fehlerkorrekturverfahren

Das Beispiel-Kapitel zu Hamming Codes stimmt irgendwie nicht. Das Beispiel funktioniert für Bit 5, aber nicht für Bit 1 (das erste Korrekturbit).

zu übertragende Daten: !1 !2  3 !4  5  6  7 !8  9 10 11 12
                        0  1  0  1  1  0  0  0  1  1  0  0
und jetzt mit Fehler:  !1 !2  3 !4  5  6  7 !8  9 10 11 12
                        1  1  0  1  1  0  0  0  1  1  0  0

Berechnung der K-Bits wie gehabt

    0101   Position 5
    1001   Position 9
XOR 1010   Position 10
---------
 =  0110

übertragene K-Bits 1110
berechnete K-Bits  0110
XOR                1000 = 8!!!!

Demnach wäre Bit 8 falsch und nicht Bit 1. Was läuft hier falsch? 178.201.49.117 20:44, 17. Feb. 2014 (CET)

fachlicher Fehler korrigiert

Habe gerade eine Korrektur eingereicht. Es liegt daran, dass die Bits falsch herum sortiert sind. Hier ist es von links nach rechts aufsteigend: 1 2 3 4 5...8. Es müsste jedoch von rechts nach links aufsteigend sein (ist bei fast jedem Zahlensystem so ob nun Binär, Hex, Oktal, Dezimal...)

Also:

Mit Fehlern:
12 11 10 9 !8  7  6  5 !4  3 !2 !1
0  0  1  1  0  0  0  1  1  0  1  1

Berechnung der K-Bits

    0101   Position 5
    1001   Position 9
XOR 1010   Position 10
-----------
= 0110

übertragene K-Bits 0111
berechnete K-Bits  0110
XOR                0001 = 1 

.... Stelle 1 ist fehlerhaft! Und damit das Protokoll nun korrekt. (nicht signierter Beitrag von JonathanJansen (Diskussion | Beiträge) 20:17, 27. Feb. 2014 (CET))

Technischer Fehler im Text

Unter "ECC und Partitätsprüfung steht bisher nur sehr wenig und der zweite Satz ist auch noch falsch: "Das ECC-Verfahren wird häufig in Speicherbausteinen für Serversysteme eingesetzt, die eine besonders hohe Datenintegrität benötigen.". Das stimmt aber so nicht.

Das ECC Verfahren wird üblicherweise durch den innerhalb der Prozessoren/Chipsets befindlichen Memory Controller ausgeführt. Der Speicher muss dazu nur entsprechende Datenbreite bieten, um die zu den Daten gehörenden ECC-Parity-Bits abzulegen. Also zum Beispiel statt 64 Bit Breite wird bei ECC 72 Bit Breite beim Speicher benötigt. Aber der ECC Algorithmus, also die Generierung der ECC Prüfbits sowie die Detektierung und Korrektur der Bit-Fehler ist üblicherweise Aufgabe des Memory Controllers (in der CPU bzw im Chipset).

Es gibt aber tatsächlich auch eine neue Lösung, bei der die ECC Korrektur vollständig selbsttätig in den Speicherchips ausgeführt wird. Diese Teile nennen sich ECC DRAMs und sind vom Hersteller Intelligent Memory seit Anfang 2015 auf dem Markt. (Referenz: www.intelligentmemory.com/ECC-DRAM/). Diese ECC DRAM sind völlig kompatibel zu konventionellen Speicherchips, führen aber selbstständig den ECC Algorithmus aus (erstellen selbst die Prüfbits, legen diese selbst in einem extra Bereich ab, prüfen und korrigieren vor der Ausgabe der Daten). Durch diese völlig Kompatibilität zu gewöhnlichen DRAMs ist es damit erstmals möglich, jedes Gerät, welches DRAM-Speicher einsetzt, einfach durch Austausch der Chips mit einer Fehlerkorrektur auszustatten, ohne dass spezielle ECC-fähige CPUs oder Chipsets benötigt werden. Man könnte damit zum Beispiel auch WLAN-Router, den Cache/Buffer auf Festplatten und SSDs, kleinformatige Industriecomputer und jedes andere Gerät mit ECC ausstatten, da man nicht mehr "72 Bit breiten Speicher" (= viele Chips bzw große Module und teure Prozessoren) benötigt.

Aus diesen ECC DRAMs stellt Intelligent Memory auch eine neue Serie Speichermodule her, genannt intECC-Speichermodule. Diese intECC Module sind Standard-DIMM oder SO-DIMM Module mit 64 Bit Breite und passen somit in jeden handelsüblichen PC oder Laptop, wobei aber die Chips darauf selbsttätig eine Fehlerkorrektur durchführen.

Jetzt soll das Ganze natürlich keine Werbung werden, aber zumindest sollte der oben genannte Fehler korrigiert und die neue Technologie erwähnt werden. Twmemphis (Diskussion) 13:13, 26. Mär. 2015 (CET)