Diskussion:8b10b-Code

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Lemma[Quelltext bearbeiten]

8B10B ist falsch, es muß 8b10b heißen, da bit normalerweise mit babgekürzt wird und Byte mit B. Ich ersetze mal die großen Bs durch keoliene bs. Der englsiche Artikel heißt auch 8b/10b encoding. --MrBurns 14:24, 12. Jan. 2010 (CET)

Gleichspannungsausgleich[Quelltext bearbeiten]

Im Artikel kommt dieses Wort vor, wird aber nicht erklärt und es gibt auch keine Wikipedia-Artikel Gleichspannungsausgleich. Es sollte also im Artikel stehen, was man unter einem Gleichspannungsausgleich versteht. --MrBurns 14:29, 12. Jan. 2010 (CET)

Es stimmt auch einfach nicht. Der Text widerspricht sich sofort. 8b10b ist der erste (2*n)b(2*n+2)b Kode der nicht gleichanteilsfrei ist. Nur n=3:6b8b ist sinnvoll und gleichanteilsfrei. n=4:8b10b, n=5:10b12b, n=32:64b66b, n=64:128b130b sind tatsächlich nicht gleichanteilsfrei. Bei längeren Kodes wie 64b66b ist es einfach nicht schlimm, dass sie nicht wirklich gleichanteilsfrei sind. 8b10b ist nur deshalb interessant weil 8b=1B. https://en.wikipedia.org/wiki/6b/8b_encoding Dieser Kode hat aufgrund seiner Kürze zwar eine kleinere Informationsrate und 6 bit sind unpraktisch, dafür ist er aber gleichanteilsfrei und hat maximal drei gleiche bit in Folge. Das macht ihn schmalbandig. --Moritzgedig (Diskussion) 19:52, 21. Apr. 2018 (CEST)

Gleichspannungsausgleich bedeutet, dass der Mittelwert einer Bitfolge 1/2 ist und nur kurzfristig davon abweichen kann. Dies ist wichtig um das Signal per Vergleich mit seinem Mittelwert als absolutem Bezug zurückgewinnen zu können und es über isolierende Elemente übertragen zu können. Wenn der Kode nicht gleichanteilsfrei ist, dann wird die Übertragung in einem Medium das einen Bandpass darstellt gestört. Ob das ein Problem ist, hängt vom Verhältnis der verbleibenden Bandbreite zur Belegten ab. Die hohen Frequenzen werden immer stark gedämpft. --Moritzgedig (Diskussion) 04:14, 22. Apr. 2018 (CEST)

8b/10b ist nicht automatisch gleichanteilfrei, man kann es aber so implementieren oder eine zusätzliche Kodierung oder Scrambling einsetzen. --Zac67 (Diskussion) 17:33, 22. Apr. 2018 (CEST)

(von #Lemma verschoben)

"Es ist ein vollständiger Gleichspannungsausgleich gewährleistet"
Dieser Code arbeitet mit "Running disparity", das einzelne Code-Wort ist somit nicht ausgeglichen. U.U. kann sich ein Offset über viele Wörter halten. "vollständig ... gewährleisten" ist für mich etwas anderes.
"und eine einfache Taktrückgewinnung aus dem Datensignal möglich."
Ohne die Bewertung halte ich den Hinweis für an dieser Stelle angemessen.
"Das Datenvolumen erhöht sich um 25 Prozent."
Hm, Prozentrechnung für Anfänger.
"Ein völlig anderer, deutlich effizienterer Code ist der 64b66b-Code mit 3 Prozent Overhead, welcher 64 Bits auf 66 Symbole abbildet und der 128b130b-Code mit 1,5 Prozent Overhead."
Noch ein völlig anderer Code gefällig?
--Moritzgedig (Diskussion) 22:35, 27. Apr. 2018 (CEST)
Die running disparity ist max. 2 in einem laufenden Symbol und am Ende des Symbols max. 1; dies wir mit dem folgenden Symbol ausgeglichen - siehe [1]. Ich nenne das gleichanteilfrei.
Wo exakt sind die Probleme mit der Taktrückgewinnung, den 25% Netto-Overhead und dem Hinweis auf 64b/66b? Formulierungen kann man verbessern. Löschen verbessert gar nichts. --Zac67 (Diskussion) 22:51, 27. Apr. 2018 (CEST)

"Formulierungen kann man verbessern. Löschen verbessert gar nichts." Formulierung hatte ich verbessert, das haben SIE gelöscht. Mich stört z.B. das Wort "Signalrate" schon mal was von Informationsrate gehört? "Ein völlig anderer, deutlich effizienterer Code" wäre ein 65b68b Code, warum erwähnen Sie den nicht auch noch und alle anderen? Gleich im Lemma. --Moritzgedig (Diskussion) 17:05, 28. Apr. 2018 (CEST)

Was ich gelöscht hatte, steht ziemlich genauso im Abschnitt Gleichspannungsausgleich – effektiv fand ich die Einleitung vorher einfach besser. Wenn dein Herz daran hängt kann das auch in die Einleitung. Informationsrate statt Signalrate ist auch gut – präziser, weniger Denglisch, aber evtl. dem Leser nicht so geläufig. Andere, gängige Codes zu erwähnen, wäre vielleicht unten sinnvoller als in der Einleitung. Obskure Codes helfen wohl nicht wirklich weiter. --Zac67 (Diskussion) 18:13, 28. Apr. 2018 (CEST)
Informationsrate wäre nicht gut. Durch die Leitungskodierung wird ja Redundanz hinzugefügt, aber keine neue Information. Insofern erhöht sich die Informationsrate eben nicht um 25 %. Außerdem gibt es den Artikel Informationsrate, der einfach etwas anderes beschreibt, als das was hier in der Einleitung mit Signalrate gemeint ist. -- Pemu (Diskussion) 10:38, 2. Mai 2018 (CEST)

"Die Signalrate erhöht sich um 25 Prozent" ist aber auch nicht das was ausgesagt werden soll. Anstelle von Symbolen und Signalen sollten wir einfach von Bit reden, verallgemeinern lässt sich schließlich nicht. Also: "Es sind 20% mehr Bit zu übertragen als Informationsbit in den Encoder hinein gehen." Ist eher das was wir sagen wollen. --Moritzgedig (Diskussion) 18:51, 4. Mai 2018 (CEST)

10 Gigabit Ethernet[Quelltext bearbeiten]

Wdwd hat 10 Gigabit Ethernet entfernt mit dem Kommentar: "Anwendungen, entfernt, weil: Bei Gigabit-Ethernet wird 64b66b verwendet". Aber 10 Gigabit Ethernet ≠ Gigagbit Ethernet. --MrBurns 15:48, 6. Mär. 2010 (CET)

Hi MrBurns, 10 Gigabit Ethernet habe ich deswegen entfernt, weil es offensichtlich 64b66b verwendet: siehe bitte: [2] oder siehe auch (Einleitung) dieser Application Note: [3]. Was auch immer (mögliche) Unterschiede von 10 Gigabit Ethernet zu Gigabit Ethernet sein mögen.--wdwd 16:42, 6. Mär. 2010 (CET)
Der Vollständigkeit halber: 10GE gibt es auch in -X-Varianten mit 8b10b-PCS (10GBASE-LX4, -CX4, -KX4). --Zac67 (Diskussion) 18:16, 28. Apr. 2018 (CEST)

Overhead[Quelltext bearbeiten]

Die Originalformulierung lautet:

"Der erzeugte Datenstrom hat einen Overhead von 20 % gegenüber dem originalen."

Die originale Datengröße hat 8 Bits und ist somit als 100% anzusetzen. Durch die 8b10b-Encodierung werden 10 Bits benötigt, also sind das 2 Bits mehr. 2 Bits von 8 Bits sind ein Viertel, also 25% und nicht, wie im Artikel 20%.

Prozent = Anteil : ([100%-Wert]:100)

Prozent = 2      : (    8      :100) =
        = 2      :      0,08         =
        = 25 (Prozent)

Das war in der Version Version vom 16. Januar 2012, 19:23 Uhr korrekt, wurde aber von Klaus_Zipfel Version vom 2. Juni 2012, 09:34 Uhr falsch korrigiert.

Man könnte es anders formulieren: "Das 10-Bit-Symbol enthält einen Verschnitt von 20%, also nur 80% Nutzdaten". Denn von "10" sind 20% "2"

Quelle: http://www.knowledgetransfer.net/dictionary/Storage/en/8b10b_encoding.htm

JuZe --217.145.101.242 16:08, 13. Jun. 2012 (CEST)

Link zu Originaldokumentation von IBM (Al Widmer und Peter Franaszek)[Quelltext bearbeiten]

Der eigentliche Link "Veröffentlichung von Al Widmer und Peter Franaszek" zu der IBM-Site funktioniert nur teilweise. Das Dokument selbst erhält man darüber nicht. Es wird allerdings auf die kostenpflichtige "Digital Library" der IEEE verweisen (31,-- €):

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=5390392&contentType=Journals+%26+Magazines&sortType%3Dasc_p_Sequence%26filter%3DAND%28p_Publication_Number%3A5288520%2Cp_Start_Page%3A440%2Cp_Issue%3A5%2Cp_Volume%3A27%29

Das Dokument ist auch sonst im Internet zu finden. Allerdings ist fraglich, ob es sich dabei um legale Veröffentlichungen handelt.

JuZe --217.145.101.242 16:59, 13. Jun. 2012 (CEST) (17:34, 13. Jun. 2012 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Anwendung der 8b/10b-Encodierung[Quelltext bearbeiten]

Ich bin der Meinung, dass DVI nicht die 8b10b-Encodierung in der grundlegenden Idee aus der Veröffentlichung von Al Widmer und Peter Franaszek (IBM) verwendet.

Es wird ja (wie angegeben) die TDMS-Encodierung verwendet. Diese hat ähnliche Ziele (Gleichspannungsausgleich, Erkennung von Übertragungsfehlern, Taktrückgewinnung) und findet dabei ebenfalls eine Vergrößerung des Symbols von 8 Bit auf 10 Bit statt -- wodurch die falsche Assoziation zu "8b10b-Code" wahrscheinlich entsteht. Allerdings ist das Encodierungsverfahren selbst komplett anders aufgebaut.

Bei 8b10b werden zuerst 5 Bits des Ausgangs-Symbols verwendet, dann ein zusätzliches Bit (i) eingebaut, dann kommen die drei verbliebenen Bits des Ausgangs-Symbols dran und letztlich wird das 10. Bit (j) zusätzlich eingebaut, abhängig von der Disparity des vorausgegangenen und des aktuellen Symbols. Gleichzeitig wird erreicht, dass niemals mehr als 5 gleiche Bits hintereinder kommen. Die 8b10b-Encodierung ist aufteilbar in eine 5b6b-Encodierung und eine 3b4b-Encodierung.

Bei der TDMS-Methode werden alle 8 Bits des Original-Symbols genommen und dann überprüft, ob durch einen Transfer der Bits an eine andere Stelle die Anzahl der Transitionen (Wechsel von 0 auf 1 oder von 1 auf 0) reduziert werden kann. Ob eine Transition stattfindet wird im 9 Bit angezeigt. Ob dann auch noch zwecks Gleichspannungsausgleich die ersten 8 Bits negiert wurden, wird im 10. Bit festgelegt. Die Anzahl der hintereinanderfolgenden identischen Bits ist hier scheinbar völlig egal. Die Encodierung ist nicht in kleinere Encodierungen aufteilbar.

Vereinfachte Darstellung:

8b10b-Encodierungsmechanismus

Ausgangsbyte:   HGFEDCBA    (H=MSB, A=LSB)
Teilung:        HGF  EDCBA
Zusätzl. Bits: jhgf iedcba

TDMS-Encodierungsmechanismus

Ausgangsbyte:    HGFEDCBA    (H=MSB, A=LSB)
keine Teilung:   HGFEDCBA
Zusätzl. Bits: jihgfedcba
Wobei aber die jeweils folgenden Bits des Ausgangsbytes entweder mit XOR oder XNOR mit
dem gerade vorausgegangenen berechneten Bit errechnet werden. (Reduktion der Transitionen)
Das 9. Bit (i) signalisert XOR oder XNOR. 
Zusätzlich können die 8 Bits "hgfedcba" invertiert werden, wenn das 10.te Bit gesetzt wird. 
Hierbei soll ein DC-Ausgeich erreicht werden. 

Mit der "echten" 8b10-Encodierung erhält man mittels "Running Disparity" bereits nach 20-Bit einen Gleichspannungsausgleich. Siehe Wikipedia (EN): 8b10b-Encoding. Wann beim TDMS-Verfahren dieser Gleichspannungsausgleich erreicht wird ist nicht klar, da niemals auf das vorausgegangene verschickte 10-Bit-Symbol zurückgegriffen wird. Anzunehmen ist, dass aufgrund einer statistischen Verteilung der möglichen 10-Bit-Symbole dies nach einer gewissen Anzahl von Symbolen erreicht wird. Dafür ist die Dekodierung hier ganz simpel.

Quellen:

Unter den Stichworten Altera Stratix GX 8b/10b Code" findet man das "Data & Control Codes, Stratix GX Device Handbook, Volume 2", welches 8b10b beschreibt. Im Vergleich dazu wird TDMS von der "Digital Display Working Group" unter http://www.ddwg.org/lib/dvi_10.pdf beschrieben. In diesem Werk wird die "8b10b-Encodierung" nirgends erwähnt.

Im allgemeinen versteht man unter 8b10b-Encodierung das Verfahren nach IBM und nicht grundsätzlich jede Konvertierung von 8 auf 10 Bit. Nachdem nur der Weblink auf die IBM-Ressorurce vorhanden war, nehme ich an, dass der initierende Autor das so im Sinn hatte. Ich würde deshalb vorschlagen, den Verweis unter Anwendungen zu entfernen und bestenfalls einen neuen Abschnitt "Andere Encodierungsverfahren" zu erstellen und dort den Verweis auf ähnliche Verfahren/Quellen anzugeben. Die anderen Anwendungen wären daraufhin natürlich auch zu überprüfen. Veilleicht kann man einen allgemeineren Artikel von grundsätzlichen Encodierungesverfahren erstellen, wo die anderen Verfahren gelistet und verglichen werden.

JuZe --217.145.101.242 19:25, 13. Jun. 2012 (CEST)

Die englische Wikipedia sieht es anders, dort wird im Artikel en:8b/10b encoding offensichtlich nicht nur das IBM-Verfahren behandelt, sondern nur als ein Beispiel genannt, weiter unten wird kurz noch Fibre Channel, das anscheinend ein anderes Verfahren benutzt, beschrieben und ganz unten steht:

Note that 8b/10b is the encoding scheme, not a specific code. While many applications do use the same code, there exist some incompatible implementations; for example, Transition Minimized Differential Signaling, which also expands 8 bits to 10 bits, but it uses a completely different method to do so.

Dazu passend aus en:Transition-minimized differential signaling:

The method is a form of 8b/10b encoding but using a code-set that differs from the original IBM form.

Wenn in unserem Artikel ausschließlich auf die IBM-Varainte verlinkt wirdn, muss nicht viel heißen, das kann auch daran liegen, dass diese Variante einfach die am weitesten verbreitete ist.
--MrBurns (Diskussion) 23:34, 13. Jun. 2012 (CEST)

Wird bei SAS 4.0 nicht auch 128b/130b eingesetzt?[Quelltext bearbeiten]

im Artikel steht 128b/150b (nicht signierter Beitrag von 217.84.193.12 (Diskussion) 09:51, 21. Jul 2016 (CEST))

SAS-4 gibt's ja noch nicht, wird aber 128b/150b verwenden: http://www.t10.org/cgi-bin/ac.pl?t=f&f=spl4r08b.pdf 5.5 SPL packet - dabei geht's nicht unbedingt um bessere Effizienz sondern um FEC. --Zac67 (Diskussion) 13:21, 21. Jul. 2016 (CEST)