Vor Kurzem stellte uns ein neugieriger Designer eine Frage zu den sogenannten „Fabric Wars“, was zu einer spannenden Diskussion über die Entwicklung der Konnektivitätsoptionen in eingebetteten Computersystemen führte. Die Konversation, die zu diesem Blogbeitrag führte, konzentriert sich insbesondere auf diese Optionen in den Architekturen OpenVPX und SOSA™ (Sensor Open Systems Architecture).
Q. von Curious:
„Ich wäre neugierig, Ihre Meinung dazu zu hören, warum PCIe auf VPX gegenüber Ethernet gewonnen hat (also warum PCIe auf Rack-Ebene gegenüber Ethernet gewinnen wird). Liegt es daran, dass es bei PCIe keine Protokollkonvertierung gibt? Oder weil PCIe schneller ist und die Latenz geringer ist, die Leistung aber auf dem Spiel steht? PCIe hat sich der Öffentlichkeit gerade als Gewinner herausgestellt, aber ich vermute, dass der serielle Bus der Wahl irgendwo in einer Arbeitsgruppe ausgetüftelt wurde.“
Liebe Neugierige:
Tatsächlich gibt es derzeit keinen wirklichen „Gewinner“ zwischen Ethernet und PCIe, zumindest nicht in OpenVPX. Hier ist der Überblick... es besteht ein allgemeiner (aber nicht universeller) Konsens darüber, Backplane-Verbindungen in Data Planes (DP), Expansion Planes (EP) und Control Planes (CP) zu unterteilen. Jeder von ihnen hat eine bestimmte Rolle in VPX-Systemen, obwohl Entwickler in ihren Anwendungen nicht unbedingt auf diese Funktionalität beschränkt sind.
• Eine Steuerebene ist für Systemsteuerungsnachrichten vorgesehen, die häufig zentral ausgegeben werden. Ethernet ist dafür sinnvoll.
• Eine Erweiterungsebene dient im Allgemeinen dazu, zwei oder mehr Platinen fest miteinander zu verbinden, was normalerweise bei einer Root-/Leaf-Organisation der Fall ist. PCIe ist dafür sinnvoll. Ein gutes Beispiel sind ein SBC und eine GPU oder eine I/O-Karte.
o EP wird auch für FPGA-zu-FPGA-Verbindungen verwendet, daher werden häufig Aurora oder Frontpanel-Data-Port (S-FPDP) verwendet
• Mit der Datenebene verschwimmen die Linien etwas mehr:
o Oft ist das DP für Peer-to-Peer-/All-to-All-Konnektivität vorgesehen. Diese Art von Verbindung lässt sich mit Ethernet viel einfacher herstellen als mit PCIe (intransparentes Bridging und so, keine gute Softwareunterstützung und generell hässlich).
o Ethernet hat viel mehr Overhead als PCIe — sowohl im Protokoll als auch im Software-Stack. Daher werden manche Leute die Mühe in Kauf nehmen, mit PCIe zu arbeiten, um die Leistung zu erzielen.
o Ethernet und PCIe überholen sich immer wieder gegenseitig, wenn es um die Kabelgeschwindigkeit geht — manche Leute wollen einfach nur dem Neuesten/Schnellsten hinterherjagen.
SOSA hat beschlossen, sich auf Ethernet DP, Ethernet CP und EP mit mehreren Protokollen zu konzentrieren (PCIe, Aurora, einfaches LVDS für den Anfang, weitere werden in Zukunft folgen). Dies dient hauptsächlich dazu, Interoperabilität und Austauschbarkeit zwischen Plug-in-Karten (PICs) zu ermöglichen. In diesem Fall ist Ethernet systemweit das Schwergewicht, wobei PCIe (und die anderen) eher zwischen bestimmten PICs lokalisiert sind. SOSA ist jedoch nicht der gesamte Markt, und die Leute bringen immer noch neue Boards auf den Markt, die nicht dem Standard entsprechen.
Der Markt ist also immer noch sehr im Wandel. Und obwohl SOSA einem bestimmten (aber großen) Teil des Marktes Grenzen setzt, gibt es immer noch Optionen, wenn auch von geringerer Marktgröße, wie Serial RapidIO, Infiniband usw.
Q. von Curious:
Was ist mit Features und Funktionen? RapidIO führte mit jeder Version eine Reihe von Funktionen ein, die seinen Funktionsumfang und seine Attraktivität erhöhten, aber selbst diese ständig wachsenden Funktionen konnten sein Überleben nicht sichern.
Liebe Neugierige:
Ihre Kommentare zu den Funktionen sind ebenfalls solide. RapidIO hatte zwei nette Funktionen, die für HPEC-Systeme wirklich nützlich sind. Die meisten Implementierungen enthielten DMA-Engines (Direct Memory Access), um Datenbewegungen vom Prozessor auszulagern, und es beinhaltete eine atomare Test- und Set-Funktion. DMA wird erst jetzt mit RoCE (Remote DMA over Converged Ethernet) verfügbar, und ich glaube nicht, dass Ethernet noch über eine atomare Test-and-Set-Funktionalität verfügt (zumindest nativ — es gibt übergeordnete Protokolle, die dies bereitstellen). Dennoch ist RapidIO aus unserem Raum verschwunden. RoCE ist noch nicht allgegenwärtig, daher haben die Leute es in VPX-Systemen nicht intensiv genutzt, aber es ist nur eine Frage der Zeit. Dann wird es wahrscheinlich ein „Muss“ -Feature sein.
Q. von Curious:
Das ist ein guter Überblick für einen Vergleich zwischen PCIe und Ethernet, aber was die Durchführbarkeit angeht, sind beide Protokolle praktikabel. Systemarchitekten müssen Protokolle auswählen, die es gibt und die erfolgreich sein werden. Um es allgemeiner auszudrücken: Warum setzt sich ein Protokoll gegen andere durch? Was ist der Grund für seinen Erfolg?
Vielleicht liegt es an der Wirtschaftlichkeit und der Stärke des Kundenstamms. Wenn das Protokoll große Umsätze erzielt, hat es überlebt, aber FORE Systems allein verkaufte Geldautomaten (Asynchronous Transfer Mode) im Wert von 700 Millionen $ pro Jahr, und ATM wurde an die großen Telekommunikationsunternehmen (ein wohlhabender Kundenstamm) verkauft, aber Geldautomaten waren veraltet.
Sie haben RapidIO (verkauft sich an den Embedded-Markt, ich denke, ziemlich rentabel) und InfiniBand (verkauft an die Supercomputerindustrie, ziemlich groß und rentabel) erwähnt, aber beide sind so gut wie tot.
Ich denke, die beste Antwort auf die Sicherstellung der Verbreitung ist die „Allgegenwärtigkeit“ des Protokolls. Wie breit ist die Basis von Entwicklern, die mit dem Protokoll vertraut sind, wie breit ist der Bekanntheitsgrad der Branche? InfiniBand ist in der Supercomputer-Branche geblieben, was zu seinem Niedergang geführt hat, obwohl der Supercomputer-Markt in absoluten Zahlen ziemlich groß war.
Es ist kaum zu glauben, dass der Ethernet-LAN-Markt in absoluten Zahlen größer war als der ATM-Telekommarkt, aber es gab mehr Ethernet-Entwickler und mehr Bewusstsein für Ethernet als für ATM. Es scheint so zu sein, dass es die Anzahl der Entwickler ist, die die Verbreitung des Protokolls vorantreiben, und nicht so sehr seine Leistung, seine Funktionen oder seine Wirtschaftlichkeit. ATM hatte 155 Mbit/s, Ethernet 10 Mbit/s. Wenn es also um Leistung ging, wie konnte ATM dann seinen Vorsprung verlieren und dann bei der Leistung ins Hintertreffen geraten? Ethernet hatte mehr Entwickler, die damit vertraut waren. Fibre Channel hat sich nie aus dem Speicher herausgeschlichen. Das ist ein großer Erfolg im Bereich Speicher, aber nicht genug Leute sind sich dessen bewusst und treiben es voran. Also geht es weg.
Also, warum hat Ethernet zum Beispiel ATM besiegt? Es scheint, dass ATM von der WAN-Vertikale in die LAN-Vertikale gedrängt wurde (zumindest bei FORE-Systemen). Ethernet hat es nicht nur wieder aus dem LAN zurückgedrängt, sondern Ethernet kam auch in den MAN und das WAN und verdrängte ATM aus beiden. Wie passiert das?
Liebe Neugierige:
Ihre Analyse ist alles ziemlich fundiert, und ich denke, es ist wirklich eine Kombination der von Ihnen beschriebenen Faktoren, die den Markt auf die eine oder andere Weise in Schwung bringt.
Zunächst einmal sind eingebettete Systeme weitgehend von Platz-, Gewichts- und Energieproblemen (SWaP) sowie von der Betriebsumgebung abhängig, in der diese Systeme eingesetzt werden. ATM war zwar Marktführer im Bereich Leistung, bot sich jedoch aufgrund des Energiebedarfs und der erzeugten Wärme nicht für eingebettete Systeme an. Es stellte sich auch die Frage nach Teilen, die für die ausgedehnten Temperaturen ausgelegt waren, unter denen unsere Systeme betrieben werden. Auch Infiniband litt darunter, wenn auch in geringerem Maße, weil es weniger Strom- und Wärmeentwicklung hatte und es tatsächlich einige Bauteile für längere Temperaturen gab. RapidIO war eine Zeit lang erfolgreich, weil es diese Herausforderungen bewältigen konnte.
Ich denke, es gibt zwei weitere Dinge, die gegen ATM, RapidIO und Infiniband, funktioniert haben, und das wären ein allgegenwärtiger Software-Stack und ein allgegenwärtiger Preis. RapidIO und Infiniband benötigten so etwas wie MPI, das die Leute entweder liebten oder hassten und das im Grunde von einer relativ kleinen, spezialisierten Community verwaltet wurde. Die Linux/Ethernet-Software wird von einer absoluten Armee von Entwicklern in der Open-Source-Community verwaltet, und es gibt eine Menge Pakete, die fast jedes beliebige Datenbewegungsmodell unterstützen. Darüber hinaus ist es einfach, Talente zu finden, die wissen, wie man es einsetzt. Es ist ein wirklich universelles Fabric, aber der einzige Nachteil ist der Leistungseinbruch des Software-Stacks. Preislich gesehen ist Ethernet einfach günstiger als alle drei, und die Kosten einer Lösung sind immer ein wichtiger Entscheidungstreiber. Da sowohl der Preis als auch der allgegenwärtige Software-Stack für Ethernet sprachen, hatten die anderen wirklich keine Chance.
Q von Curious:
Was ist, wenn wir das aus der entgegengesetzten Richtung betrachten und fragen, welches Protokoll als nächstes sterben wird oder in welcher Reihenfolge Protokolle sterben werden, anstatt zu fragen, welche Protokolle überleben werden?
Ich denke, wenn wir die Anzahl der Entwickler pro Protokoll kennen, können wir den zukünftigen Rückgang oder Anstieg des Protokolls vorhersagen.
Liebe Neugierige:
Ich denke, wir haben die primären Protokolloptionen fast auf das Minimum beschränkt, das im eingebetteten Hochleistungsbereich festgelegt ist. Ethernet und PCIe sind ziemlich klare Gewinner. Ich denke, dass es im Bereich Streaming-Daten Platz für Konkurrenten gibt. Aurora ist beliebt, aber es ist nur bei Xilinx erhältlich. Es ist die Rede davon, dass serielles FPDP von einem drahtbasierten Sensor-zu-Knoten-Protokoll in ein Backplane-basiertes Knoten-zu-Knoten-Protokoll umgewandelt wird. Es wird jedoch einige Zeit dauern, bis festgestellt ist, ob der Markt dies wirklich annimmt. Ich denke, es könnte also Raum für ein neues Hochleistungs-Streaming-Protokoll mit geringem Overhead geben, das CPUs und FPGAs verschiedener Anbieter unterstützt. Nur die Zeit wird es zeigen.
Was ich definitiv sehe, sind neue Funktionen, die in Ethernet erforderlich sind. Die beiden wichtigsten sind derzeit Remote DMA (in Form von RoCE) und Time Sensitive Networking (TSN). Anbieter von Switch- und Steckkarten, die RoCE und TSN unterstützen, werden in den nächsten Jahren sehr gefragt sein.
