Im zweiten Teil geht es um Kupfer-SFP-Module für bis zu 10 GBit. Diese fordern auf der 'SFP-Seite' natürlich einen SFP+-Port, der primär für optische Module und DACs mit 10 GBit konzipiert wurde. Bei solchen Modulen geht das an einem SFP+-Port anliegende serielle Signal mit brutto 10,3125 GBit wieder einfach auf eine Laser-Diode, die es in Lichtpulse umsetzt, und auf der anderen Seite wandelt eine Fotodiode die Lichtpulse wieder zurück. Und auch bei Kupfer-Modulen für 10 GBit ist es wieder so, dass sie dieses für optische Übertragung gedachte Signal entgegen nehmen und in 10GBASE-T umwandeln.
Auch bei 10 GBit ist es gang und gäbe, dass Kupfer-Module in ihrem EEPROM behaupten, sie wären ein Glasfaser-Modul. Hintergrund sind (mal wieder) die Programmierer von Treibern, die außer Fasermodulen und DACs nichts akzeptieren. Ein bekannter Fall sind z. B. Treiber für Intel-Netzwerkkarten, wie der ixgbe-Treiber unter Linux. Intel-basierte Netzwerkchips begegnen einem in der Praxis nicht nur in der Form von (PCIe-)Steckkarten, sondern auch integriert auf der Hauptplatine von x86-basierten Netzwerk-Appliances.
Neben den Gemeinsamkeiten gibt es aber auch eine Reihe wichtiger Unterschiede zu 1 GBit-Modulen, die den Betrieb in der Praxis noch eine Ecke herausfordernder machen. Da wäre zuvorderst die Leistungsaufnahme dieser Module zu nennen. Daten mit 10 GBit über eine Cat6-Leitung mit bis zu 100 Metern zu schieben, war eine technische Herausforderung, die viel Aufwand an digitaler Signalverarbeitung erfordert, und ähnlich wie bei DSL auch einiges an elektrischer Treiber-Leistung ins Kabel.
Selbst wenn viele dieser Module sich auf Kabellängen bis 30 Metern beschränken, fordern sie je nach Betriebszustand von der Stromversorgung eines SFP+-Ports mehr, als dieser nach Standard liefern muss. Das Thema ist hier ein ähnliches wie früher bei USB-Ports, wo Geräte wie externe Festplatten mehr als die von USB 2.0 definierten 2,5 Watt verlangten. Je nachdem wie genau der Entwickler den Standard
gelesen und umgesetzt hatte, ging es dann mal oder mal nicht.
Bei Kupfer-SFP-Modulen können sich Effekte einstellen, dass das Modul zuerst erkannt wird, aber sobald ein Link aufgebaut werden soll, bricht er aufgrund einer Strombegrenzung am SFP-Port gleich wieder zusammen. Ich habe schon Fälle gesehen, wo ein Link mit 2,5 oder 5 GBit auf der Kupfer-Seite stabil lief, einer mit 10 GBit aber nicht mehr. Wie bei den meisten Digital-Schaltkreisen steigt die Stromaufnahme
mit der Taktfrequenz an...
Die hohe Leistungsaufnahme ist die eine Seite der Medaille, die daraus resultierende Wärmeentwicklung eine andere. Bis auf das bisschen Energie, was auf die Leitung geht, wird alle aufgenommene Leistung letzten Endes in Wärme umgesetzt. Gerade in Switches sind die SFP-Cages oft dicht gepackt, so dass in Geräten 'Hot Spots' entstehen, wo ein oder gar mehrere Kupfer-SFP-Module gesteckt sind. Die Technik von 10GBASE-T-Bausteinen hat sich natürlich über die Jahre weiter entwickelt, neuere Bausteine verwenden feinere und sparsamere Fertigungsprozesse. Bei älteren Modulen, die häufig einen Marvell 88X3310 oder AQR113 einsetzen, liegt die Leistungsaufnahme in der Größenordnung von 2,5 Watt. Das klingt vielleicht nicht nach viel, aber wer schon einmal ein solches Modul nach einer Weile Betrieb aus dem SFP-Slot heraus gezogen hat, wird vielleicht erstaunt sein, wie heiß diese Module im Betrieb werden.
Mit der Erwähnung verschiedener Bausteine bin ich auch schon beim zweiten großen Unterschied zu GBit-Modulen, der Vielfalt der verbauten Chipsätze. Bei 1 GBit-Modulen herrscht weitgehend eine 'Monokultur': Etwa 99 von 100 Modulen verwenden einen Marvell 88E1111. Bei SFP+-Modulen habe ich selber bisher Module mit folgenden Chips in der Hand gehabt:
• Marvell 88X3310 (LANCOM SFP-CO10MG, erste Generation)
• Marvell/Aquantia AQR107 (Aquantia AQS-107)
• Marvell/Aquantia AQR113C (LANCOM SFP-CO10MG, zweite Generation)
• Broadcom BCM84881 (WTD RTXL185-510)
• Broadcom BCM84891L
Man liest im Netz aber auch von Modulen, die Realtek-Chips verbauen, und ich selber habe in der Sammlung ein Modul, von dem ich bis heute nicht weiß, was für ein Baustein darin steckt.
Das bringt mich zu einem weiteren gewichtigen Unterschied zu 1 GBit-Modulen: Alle der hier genannten Bausteine haben im Gegensatz zum Marvell 88E1111 keine I2C-Schnittstelle eingebaut, die einen Zugriff auf die Register des Bausteins zulassen würde. Wenn man das Modul nur als 'Black Box' betrachtet, die sich zum SFP hin als Fasermodul ausgibt und das auf 10GBASE-T umsetzt, kann es einem natürlich egal sein. Aber man bekommt natürlich auch keine Infos, wenn auf der Kupfer-Seite mal weniger als 10 GBit ausgehandelt wurden. 10GBASE-T Bausteine beherrschen üblicherweise mindestens alle Ethernet-Geschwindigkeiten bis herunter zu 100 MBit, manche sogar auch noch ganz altes 10BASE-T (wenn jemand ernsthaft einen 10 GBit-Port dafür nutzen will...). Um die effektive Bitrate auf der Kupfer-Seite zu erfahren, kommt man um einen Zugriff auf Ethernet-Chip im Modul nicht herum.
Eben weil eine solche Schnittstelle den 10GBit-Ethernet-Chips fehlt, sind die Hersteller von Kupfer-SFP+-Modulen gezwungen, die Funktionalität über einen Zusatzbaustein nachzurüsten. Das ist dann ein kleiner Mikrocontroller, der auf dem I2C-Bus des SFP-Ports eine Hand voll Mailbox-Register implementiert, und auf der anderen Seite das bei Ethernet-PHYs standardmäßig verwendete MDIO-Protokoll 'spricht'.
Nun hat sich aber leider bisher kein Standard dafür heraus gebildet, wie man diesen Mikrocontroller auf der I2C-Seite anspricht. Quasi jeder Hersteller kocht sein eigenes Süppchen, was die Adressen dieser Mailbox-Register angeht und wie sie belegt sind. So bin ich im LCOS zum Beispiel gezwungen, für jedes neue Kupfer-SFP+-Modul einen eigenen Treiber für den Registerzugriff zu erstellen, und man muss vorher jedes Mal beim Hersteller Dokumentation dafür einfordern.
Einen letzten, wichtigen Punkt hatte ich auch schon indirekt angesprochen, nämlich die geänderte Datenraten-Umsetzung, also was passiert, wenn die Kupfer-Seite des Moduls auf einer anderen Geschwindigkeit läuft als 10 GBit/s. Mit der Einführung von NBASE-T sind da ja noch 2,5 und 5 GBit als Zwischenstufen hinzu gekommen, und insbesondere die 2,5 GBit sind gerade dabei, sich in der Masse bei APs, Routern und
Endgeräten durchzusetzen. Dieser Erfolg war 10GBASE-T ja bisher nicht vergönnt, obwohl es eigentlich schon viel länger existiert. Auf einem SFP+-Port hat man aber üblicherweise nur 1 oder 10 GBit zur Verfügung.
Vorneweg: Ein dem SGMII vergleichbarer Modus, wo auf der SFP-Seite die 'überzähligen Bits' durch Wiederholung aufgefüllt werden, existiert bei 10 GBit nicht. Der in einem SFP-Modul steckende Ethernet-PHY macht daher eine echte Bitraten-Umsetzung, d.h. auf dem SFP-Port kommen die Daten mit 10 GBit/s netto an, und er gibt sie auf der Kupfer-Seite mit der ausgehandelten, gleichen oder niedrigeren Geschwindigkeit wieder aus.
So eine Bitraten-Wandlung geht eigentlich über den Begriff eines Medienkonverters bzw. Repeaters hinaus. Aber in der modernen Netzwerktechnik sind Begriffe wie 'Switch' und 'Router' ja auch an anderer Stelle unscharf geworden. Wo Daten mit höherer Bitrate herein kommen, als sie heraus gehen, muss es natürlich einen irgendwie gearteten Puffer geben. Bei einem 10GBASE-T Baustein, der auf der Kupferseite eine hoch komplexe Modulation rechnen muss, ist so ein FIFO von ein paar KByte Größe aber keine technische Hürde mehr.
Was man aber irgendwie lösen muss, ist in so einem Szenario die Flusskontrolle. Egal wie groß der Puffer ist, wenn auf der einen Seite mit höherer Rate geschrieben als auf der anderen gelesen wird, dann wird dieser Puffer irgendwann überlaufen. Die gängigste und eleganteste Lösung dafür ist der Einsatz vom Flow Control gemäß IEEE 802.3x, d.h. der Ethernet-PHY im SFP+-Modul schickt von sich aus ein Pause-Paket, wenn sein Sendepuffer überzulaufen droht. Das klingt auf den ersten Blick nach viel Overhead, weil im Extremfall genauso viele Pause-Frames wie Nutzpakete laufen. Es funktioniert in der Praxis aber sehr gut, weil in so einem Szenario in der anderen Richtung ja Bandbreiten-mässig noch 'Luft' ist. Man sollte sich als Anwender nur nicht darüber wundern, dass der Empfang von Massen an Pause-Frames gemeldet wird, obwohl Flow Control mit der eigentlichen Gegenstelle gar nicht ausgehandelt wurde...
Unglücklicherweise gibt es Fälle, wo diese elegante Form der Flussteuerung nicht möglich ist. LANCOMs SFP-CO10MG der ersten Generation basiert auf einer Variante des Marvell 88X3310, die keine Erzeugung von Pause-Frames unterstützt. In so einem Fall muss der den SFP-Port betreibende Ethernet-MAC die effektive Bandbreite durch Einfügen passend langer Pausen selber limitieren. Leider kann das nicht jeder Ethernet-MAC gleich gut: Die SFP+-Ports im LANCOM 2100EF und der ISG-5000 basieren auf einem Intel X553, der seine Nettorate lediglich in 10 Prozent-Schritten des Maximums beschränken kann. Bei 1 und 5 GBit passt das glatt, bei 100 MBit und 2,5 GBit leider nicht. Man erhält im Ethernet-Status-Trace dann folgende Meldung:
Code: Alles auswählen
bandwidth pacing mismatch: 2 Gbps instead of 2.5 Gbps
Das aktuell verkaufte SFP-CO10MG basiert auf einem AQR113C, der Pause-Frames erzeugen kann, so dass die zitierte Meldung nicht kommt.
Bei aktiven DACs für längere Strecken kann das wieder anders aussehen, da kommt man auch wieder eher in die Verlegenheit, dass man Potentialdifferenzen hat...