DE112016005917T5 - Exascale-fabric-zeitsynchronisierung - Google Patents

Exascale-fabric-zeitsynchronisierung Download PDF

Info

Publication number
DE112016005917T5
DE112016005917T5 DE112016005917.5T DE112016005917T DE112016005917T5 DE 112016005917 T5 DE112016005917 T5 DE 112016005917T5 DE 112016005917 T DE112016005917 T DE 112016005917T DE 112016005917 T5 DE112016005917 T5 DE 112016005917T5
Authority
DE
Germany
Prior art keywords
clock
port
flit
fabric
master clock
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE112016005917.5T
Other languages
English (en)
Inventor
Thomas D. Lovett
Michael A. Parker
Mark S. Birrittella
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE112016005917T5 publication Critical patent/DE112016005917T5/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • G06F13/40Bus structure
    • G06F13/4004Coupling between buses
    • G06F13/4022Coupling between buses using switching circuits, e.g. switching matrix, connection or expansion network
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/04Generating or distributing clock signals or signals derived directly therefrom
    • G06F1/12Synchronisation of different clock signals provided by a plurality of clock generators
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/36Handling requests for interconnection or transfer for access to common bus or bus system
    • G06F13/362Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
    • G06F13/364Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control using independent requests or grants, e.g. using separated request and grant lines
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • G06F13/42Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4282Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Synchronisation In Digital Transmission Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Verfahren und Vorrichtung zum Implementieren von Zeitsynchronisation über Exascale-Fabrics. Ein Master-Taktgeber-Knoten ist mit einer Vielzahl von Slave-Knoten über ein Fabric gekoppelt, das eine Vielzahl von Fabric-Schaltern und eine Vielzahl von Fabric-Links umfasst, wobei jeder Slave-Knoten mit dem Master-Taktgeber-Knoten über einen jeweiligen Taktgeberbaumpfad, der mindestens einen Fabric-Schalter quert, verbunden ist. Die Fabric-Schalter sind konfiguriert, selektiv Master-Taktgeberzeitdaten intern entlang Pfaden mit festen Latenzen, die die Puffer der Schalter und Schalterschaltungsanordnung umgehen, weiterzuleiten, was es den gesamten Taktgeberbaumpfaden ermöglicht, ebenfalls über feste Latenzen zu verfügen. Die feste Latenz des Taktgeberbaumpfads wird für jeden Slave-Knoten festgestellt. Die lokalen Taktgeber der Slave-Knoten werden dann mit dem Master-Taktgeber unter Verwendung von Master-Taktgeberzeitdaten, die von jedem Slave-Knoten empfangen werden, und der festen Latenz des Taktgeberbaumpfads von dem Master-Taktgeberknoten bis zu dem Slave-Knoten, die festgestellt wird, zu synchronisieren. Es werden auch Techniken zum Feststellen einer Taktgeberratenfehlanpassung zwischen dem Master-Taktgeber und einem lokalen Taktgeber bereitgestellt.

Description

  • HINTERGRUNDINFORMATIONEN
  • High-Performance-Computing (HPC) hat in den letzten Jahren einen erheblichen Anstieg an Nutzung und Interesse erfahren. Historisch wurde HPC im Allgemeinen mit sogenannten „Supercomputern“ in Verbindung gebracht. Supercomputer wurden in den 1960er Jahren eingeführt und anfangs und jahrzehntelang primär von Seymour Cray von Control Data Corporation (CDC), Cray Research und nachfolgenden Unternehmen, die den Namen oder das Monogramm Crays trugen, hergestellt. Während die Supercomputer der 1970er Jahre nur wenige Prozessoren verwendeten, begannen in den 1990er Jahren Maschinen mit Tausenden von Prozessoren zu erscheinen und in jüngerer Zeit wurden massiv parallele Supercomputer mit Hunderttausenden von „handelsüblichen“ Prozessoren implementiert.
  • Es gibt viele Arten von HPC-Architekturen, sowohl auf implementierte, wie auch auf forschungsorientierte Weise, sowie unterschiedliche Größen- und Leistungsebenen. Ein übliches Thema ist jedoch die Verbindung einer hohen Zahl von Recheneinheiten, wie etwa Prozessoren und/oder Prozessorkernen, untereinander, so dass sie kooperativ Aufgaben auf parallele Weise durchführen. Gemäß jüngerer System-on-a-Chip(SoC)-Entwürfe und Vorschläge werden Dutzende von Prozessorkernen oder dergleichen auf einem einzelnen SoC unter Verwendung einer zweidimensionalen (2D) Array-, Torus-, Ring- oder anderen Konfiguration implementiert. Zusätzlich haben Forscher 3D-SoCs vorgeschlagen, unter denen Hunderte oder sogar Tausende von Prozessorkernen in einem 3D-Array untereinander verbunden sind. Separate Multicore-Prozessoren und SoCs können auch eng beabstandet auf Serverplatinen angeordnet sein, die wiederum in Kommunikation über eine Rückwandplatine oder dergleichen untereinander verbunden sind. Ein anderer üblicher Ansatz ist es, Recheneinheiten in Servergestellen (z. B. Blade-Server und Module), die typischerweise in einem 2D-Array als ein Cluster von Rechenknoten konfiguriert sind, untereinander zu verbinden.
  • Es gibt verschiedene Arten von Verarbeitungsaufgaben, die eine präzise Synchronisation der unterschiedlichen Serversätze und/oder Rechenknoten erforderlich machen. Bei einem Einsatz in einem Cluster senden die Rechenknoten zum Beispiel typischerweise Nachrichten untereinander und die Reihenfolge, in der die Nachrichten empfangen werden, ist sehr wichtig. Aus diesem Grund gibt es verschiedene Ordnungsmodelle, die eingesetzt werden können, um sicherzustellen, dass Nachrichten in der ordnungsgemäßen Reihenfolge verarbeitet werden, einschließlich FIFO- (First-in, First-out), Total- und Kausal-Ordnung. Jedes dieser Ordnungssysteme macht einen zusätzlichen Aufwand erforderlich, der in verringerter Leistung resultiert. Die FIFO-Ordnung macht zum Beispiel typischerweise die Verwendung von FIFO-Routern erforderlich, Total-Ordnung macht es erforderlich, dass Nachrichten über eine zentrale Entität gesendet werden und Kausal-Ordnung wird typischerweise unter Verwendung von Vektortakten implementiert.
  • Idealerweise würde das effektivste Ordnungssystem einfach ein Zeitstempeln jeder Nachricht mit einer absoluten Zeit umfassen. Dies würde eine Absolut-Ordnung unterstützen, was für viele HPC- und andere Prozesse das bevorzugte Ordnungssystem ist. Dies lässt sich jedoch von Natur aus schwer implementieren, weil es so etwas wie eine absolute Zeit, die in einer gesamten HPC-Umgebung geteilt wird, nicht gibt. Genauer gesagt ist es nicht so sehr die Zeit, die absolut sein muss, sondern vielmehr müssen die Zeituhren, die auf jedem Server laufen, synchronisiert werden.
  • Ein System zum Synchronisieren von Taktgebern wird von den IEEE 1588 Standards definiert. IEEE 1588 stellt ein Standardprotokoll für das Synchronisieren von Taktgebern, die über ein multicastfähiges Netzwerk, wie etwa Ethernet, verbunden sind, bereit. IEEE 1588 wurde entworfen, um fehlertolerante Synchronisation unter heterogenen vernetzten Taktgebern, die nur wenig Netzwerkbandbreitenaufwand, Verarbeitungsleistung und administrative Einrichtung erforderlich machen, bereitzustellen. IEEE 1588 stellt dies durch Definieren eines Protokolls, das als Precision Time Protocol bzw. PTP bekannt ist, bereit. Ein heterogenes Netzwerk von Taktgebern ist ein Netzwerk, das Taktgeber unterschiedlicher Charakteristiken enthält, wie etwa den Ursprung der Zeitquelle eines Taktgebers und die Stabilität der Frequenz des Taktgebers. Das PTP-Protokoll stellt ein fehlertolerantes Verfahren zum Synchronisieren aller beteiligten Taktgeber mit dem Taktgeber der höchsten Qualität in dem Netzwerk bereit. IEEE 1588 definiert einen Standardsatz von Taktgebereigenschaften und definiert Wertbereiche für jeden. Durch Ausführen eines verteilten Algorithmus, der als Best Master Clock Algorithmus (BMC) bezeichnet wird, identifiziert jeder Taktgeber in dem Netzwerk den Taktgeber mit der höchsten Qualität; das heißt, den Taktgeber mit dem besten Satz von Eigenschaften.
  • Der am höchsten bewertete Taktgeber wird als der „Grandmaster“-Taktgeber bezeichnet und synchronisiert alle anderen „Slave“-Taktgeber. Wird der „Grandmaster“-Taktgeber aus dem Netzwerk entfernt oder falls sich seine Eigenschaften auf eine Weise verändern, dass er nicht mehr der „beste“ Taktgeber ist, stellt der BMC-Algorithmus eine Möglichkeit bereit, über die die teilnehmenden Taktgeber automatisch den aktuellen „besten“ Taktgeber ermitteln, der dann der neue Grandmaster wird. Der beste Master-Taktgeber-Algorithmus stellt eine fehlertolerante und administrativ freie Möglichkeit zum Ermitteln des Taktgebers, der als als die Zeitquelle für das gesamte Netzwerk verwendet wird, bereit.
  • Slave-Taktgeber synchronisieren mit dem 1588-Grandmaster unter Verwendung bidirektionaler Multicastkommunikation. Der Grandmaster-Taktgeber gibt periodisch ein Paket aus, das als ein „Sync“-Paket bezeichnet wird und einen Zeitstempel der Zeit, zu der das Paket den Grandmaster-Taktgeber verlassen hat, enthält. Der Grandmaster, kann optional auch ein „Follow-up“-Paket ausgeben, das den Zeitstempel für das „Sync“-Paket enthält. Die Verwendung eines separaten „Follow-up“-Pakets erlaubt es dem Grandmaster, das „Sync“-Paket in Netzwerken, in denen die Abgangszeit eines Pakets im Voraus nicht genau bekannt sein kann, mit einem genauen Zeitstempel zu versehen. Der Kollisionserkennungs- und Zufalls-Back-Off-Mechanismus der Ethernet-Kommunikation verhindert zum Beispiel, dass die exakte Übertragungszeit eines Pakets bekannt ist, bis das Paket vollständig ohne eine erkannte Kollision versandt wurde. Zu diesem Zeitpunkt ist es unmöglich, den Inhalt des Pakets zu verändern.
  • Während IEEE 1588 und das PTP ein adäquates Niveau der Taktgebersynchronisation für manche Anwendungen bereitstellen (in der Größenordnung von Zehntel Mikrosekunden), ist dies nicht präzise genug, um die Anforderungen vieler HPC-Umgebungen zu erfüllen. Dementsprechend wäre es vorteilhaft, einen Mechanismus zu implementieren, der eine Taktgebersynchronisierung aufrechterhält, die mehrere Größenordnungen besser als IEEE 1588 ist.
  • Figurenliste
  • Die vorstehenden Aspekte und viele der begleitenden Vorteile dieser Erfindung lassen sich leichter erschließen, wenn sie sich unter Bezugnahme auf die folgende ausführliche Beschreibung, wenn sie in Verbindung mit den beigefügten Zeichnungen, worin gleiche Bezugszeichen sich auf gleiche Teile in den verschiedenen Ansichten beziehen, sofern nicht anderweitig angegeben, erwogen werden, besser verstehen lässt:
    • 1 ist ein schematisches Diagramm, das eine High-Level-Ansicht eines Systems veranschaulicht, das verschiedene Komponenten und Verbindungen der Fabric-Architektur gemäß einer Ausführungsform veranschaulicht;
    • 2 ist ein schematisches Diagramm, das die Ebenen der Architektur zum Übertragen von Daten über die Fabric-Links gemäß einer Ausführungsform veranschaulicht;
    • 3 ist ein schematisches Diagramm, das eine Vielzahl von in einem Bündel gruppierten Flits veranschaulicht;
    • 4 ist ein schematisches Diagramm, das die Struktur eines Fabric-Pakets gemäß einer Ausführungsform veranschaulicht;
    • 5 ist ein Diagramm, das die Datenstruktur einer Standarderfassungs-LTP gemäß einer Ausführungsform veranschaulicht;
    • 6 ist ein Diagramm, das die Datenstruktur eines 14-Bit CRC LTP gemäß einer Ausführungsform veranschaulicht;
    • 7 ist ein Diagramm, das die Datenstruktur einer erweiterten Erfassungs-LTP gemäß einer Ausführungsform veranschaulicht;
    • 8 ist ein Diagramm, das die Datenstruktur einer Standarderfassungs-Null-LTP gemäß einer Ausführungsform veranschaulicht;
    • 9 ist ein schematisches Diagramm, das ein Beispiel bidirektionaler Datenübertragung zwischen zwei Linkports, die vier Spuren einsetzen, gemäß einer Ausführungsform veranschaulicht;
    • 10a ist ein schematisches Diagramm, das einen beispielhaften Taktgeberbaum in einem Fabric veranschaulicht, in dem Zeitsynchronisation implementiert ist, gemäß einer Ausführungsform;
    • 10b ist ein schematisches Diagramm, das eine Ergänzung zu 10a zeigt, unter der ein Backup-Master-Taktgeber-Knoten einen ursprünglichen Master-Taktgeber-Knoten ersetzt hat;
    • 11a ist ein schematisches Diagramm eines Schalters, der konfiguriert ist, Taktgeberdaten zwischen vorgeschalteten und nachgeschalteten Taktgeberports unter Verwendung eines Paares von Ringbussen nahe der Peripherie des Schalters zu übertragen;
    • 11b ist ein schematisches Diagramm, das weitere Einzelheiten von Taktgeberports gemäß einer Ausführungsform zeigt;
    • 12 ist ein Diagramm, das das Format des MasterTimeHigh SPC Flit gemäß einer Ausführungsform veranschaulicht;
    • 13 ist ein Diagramm, das das Format des MasterTimeLow SPC Flit gemäß einer Ausführungsform veranschaulicht;
    • 14 ist ein Flussdiagramm, das Operationen und Logik zum Ermitteln einer Taktgeberabweichung zwischen einem Master-Knoten-Taktgeber und einem lokalen Taktgeber an einem Slave-Knoten gemäß einer Ausführungsform veranschaulicht;
    • 15 ist ein Flussdiagramm, das Operationen und Logik zum Berechnen von Taktgeberbaumpfadlatenzen gemäß einer Ausführungsform veranschaulicht; und
    • 16 ist ein Flussdiagramm, das Operationen zum Durchführen einer Taktgebersynchronisierung zwischen einem Master-Taktgeber und einem lokalen Taktgeber veranschaulicht und ferner eine Aktualisierung der synchronisierten Taktgeber unter Verwendung der Taktgeberabweichung, die über das Flussdiagramm 14 festgestellt wurde, veranschaulicht.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Hierin werden Ausführungsformen von Verfahren und eine Vorrichtung zum Implementieren von Zeitsynchronisation über Exascale-Fabrics beschrieben. In der folgenden Beschreibung werden zahlreiche spezifische Einzelheiten dargestellt, um ein genaues Verständnis von Ausführungsformen der Erfindung bereitzustellen. Der Fachmann wird jedoch erkennen, dass die Erfindung ohne eine oder mehrere der spezifischen Einzelheiten oder mit anderen Verfahren, Komponenten, Materialien usw. realisiert werden kann. In anderen Fällen werden weithin bekannte Strukturen, Materialien oder Operationen nicht gezeigt oder ausführlich beschrieben, um ein Verundeutlichen von Aspekten der Erfindung zu vermeiden. Bezugnahmen in dieser Spezifikation auf „eine Ausführungsform“ bedeuten, dass ein/e bestimmte/s Merkmal, Struktur oder Eigenschaft, die in Verbindung mit der Ausführungsform beschrieben wird, in mindestens einer Ausführungsform der vorliegenden Erfindung enthalten ist. Somit bezieht sich das Auftreten der Formulierungen „in einer Ausführungsform“ an unterschiedlichen Stellen in dieser Spezifikation nicht immer zwangsläufig auf die gleiche Ausführungsform. Des Weiteren können die bestimmten Merkmale, Strukturen oder Eigenschaften auf jedwede geeignete Weise in einer oder mehreren Ausführungsformen kombiniert werden.
  • Zur Klarstellung: Auf individuelle Komponenten in den Figuren hierin lässt sich auch über ihre Kennzeichnungen in den Figuren Bezug nehmen, anstatt über ein bestimmtes Bezugszeichen. Zusätzlich können Bezugszeichen, die sich auf einen bestimmten Komponententyp beziehen (im Gegensatz zu einer bestimmten Komponente) mit einem Referenzzeichen gefolgt von „(typ)“, was „typisch“ bedeutet, gezeigt werden. Es versteht sich, dass die Konfiguration dieser Komponenten typisch für ähnliche Komponenten ist, die existieren können, aber in den Zeichnungen der Figuren der Einfachheit und Klarheit halber, oder dass anderweitig ähnliche Komponenten, die nicht mit separaten Referenzzeichen gekennzeichnet sind, nicht gezeigt werden. Umgekehrt darf „(typ)“ nicht derart ausgelegt werden, als würde die Komponente, das Element usw. typischerweise für deren/dessen offenbarte Funktion, Implementierung, Zweck usw. verwendet werden.
  • Gemäß Aspekten der hierin beschriebenen Ausführungsformen wird ein Mechanismus bereitgestellt, der eine extrem genaue Zeitsynchronisierung in einem Exascale-Fabric ermöglicht. In beispielhaften Ausführungsformen unterstützt das Fabric die inhärente Zuverlässigkeit auf der Linkschicht (Schicht 2) ohne das Erfordernis von End-to-End-Bestätigungen auf einer höheren Schicht, wie dies etwa von TCP über Ethernet-Netzwerke verwendet wird. Um ein besseres Verständnis dafür zu gewinnen, wie der Mechanismus implementiert werden kann, wird zuerst eine Diskussion des Exascale-Fabric geführt, gefolgt von einer ausführlichen Beschreibung des Zeitsynchronisierungsmechanismus.
  • Gemäß Aspekten des Exascale-Fabric wird eine Architektur bereitgestellt, die ein Nachrichtenweiterleitungs-, Vermittlungs-, Serververbindungsnetzwerk definiert. Die Architektur umfasst die Schichten 1 und 2 des OSI Netzwerkmodells, nutzt IETF Internet Protocol für Schicht 3 und beinhaltet eine Kombination aus neuen und genutzten Spezifikationen für Schicht 4 der Architektur.
  • Die Architektur kann derart implementiert werden, dass CPUs und andere Untersysteme, die eine logische Nachrichtenweiterleitungskonfiguration umfassen, entweder durch formale Definition, wie etwa ein Supercomputer, oder einfach durch Zuordnung, verbunden werden, wobei solch eine Gruppe oder ein Cluster von Servern auf gewisse Weise auf koordinierte Weise aufgrund der Nachrichtenweiterleitungsanwendungen, die sie ausführen, funktionieren, wie dies häufig beim Cloud Computing der Fall ist. Die untereinander verbundenen Komponenten werden als Knoten bezeichnet. Die Architektur kann auch implementiert werden, um Prozessorknoten mit einem SoC, Multichipmodul oder dergleichen zu verbinden. Eine Art von Knoten, die als Host bezeichnet wird, ist die Art, auf der Benutzermodussoftware ausgeführt wird. In einer Ausführungsform umfasst ein Host eine einzelne Cache-kohärente Speicherdomäne, ungeachtet der Anzahl der Kerne oder CPUs in der kohärenten Domäne, und er kann verschiedene lokale I/O und Speicheruntersysteme enthalten. Die Art von Software, die ein Host ausführt, kann eine spezialisiertere Funktion definieren, wie etwa einen Benutzeranwendungsknoten oder einen Speicher- oder Dateiserver, und dient zum Beschreiben einer detaillierteren Systemarchitektur.
  • Auf oberster Ebene definiert die Architektur die folgenden Komponenten:
    • • Host-Fabric-Schnittstellen (Host Fabric Interfaces; HFIs);
    • • Links;
    • • Schalter;
    • • Gateways; und
    • • ein umfassendes Managementmodell.
  • Host-Fabric-Schnittstellen (HFIs) bestehen mindestens aus der Logik zum Implementieren der physikalischen und Link-Schichten der Architektur, so dass ein Knoten sich an ein Fabric anhängen und Pakete an andere Server oder Vorrichtungen senden und von diesen empfangen kann. HFIs beinhalten angemessene Hardwareschnittstellen und Treiber für Betriebssystem- und VMM (Virtual Machine Manager) Unterstützung. Eine HFI kann auch spezialisierte Logik zum Ausführen oder Beschleunigen von oberen Schichtprotokollen und/oder Entladen von Transportprotokollen beinhalten. Eine HFI enthält auch Logik zum Reagieren auf Nachrichten von Netzwerkmanagementkomponenten. Jeder Host ist mit der Architektur-Fabric über eine HFI verbunden.
  • Links sind voll-duplex, Punkt-zu-Punkt-Verbindungen, die HFIs mit Schaltern, Schalter mit anderen Schaltern oder Schalter mit Gateways verbinden. Links können unterschiedliche physikalische Konfigurationen aufweisen, in Leiterbahnen, Kupferkabeln oder optischen Kabeln. In einer Ausführungsform folgen die Implementierungen des physikalischen Schicht (Physical Layer; PHY) Kabels und der Verbindungsstrategie jenen für Ethernet, insbesondere 100GbE (100 Gigabits pro Sekunde Ethernet, wie etwa die in dem IEEE 802.3bj-2014 Standard definierten Ethernet Links). Die Architektur ist flexibel und unterstützt die Verwendung von zukünftigem Ethernet oder anderen Verbindungstechnologien, die 100GbE Bandbreite übersteigen können. Highend-Supercomputerprodukte können Spezial-PHYs (viel höhere Bandbreite) verwenden und für diese Konfigurationen ist die Interoperabilität mit Architekturprodukten auf Schaltern mit Ports mit unterschiedlichen PHYs basiert.
  • 1 zeigt eine High-Level-Ansicht eines Systems 100, das verschiedene Komponenten und Verbindungen der Architektur gemäß einer Ausführungsform veranschaulicht. Ein zentrales Merkmal der Architektur ist das Fabric 102, das eine Ansammlung von HFIs und Gateways beinhaltet, die über Links und Schalter der Architektur untereinander verbunden sind. Wie in 1 gezeigt, beinhalten die Fabric 102 Komponenten mehrere HFIs 104 (es wird eine gezeigt), die jeweils von einer entsprechenden diskreten einzelnen Knotenplattform 106 gehostet wird, eine HFI 108, die von einer virtuellen Plattform 110 gehostet wird, HFIs 1121 und 112n , die von entsprechenden Knoten 1141 und 114n einer Multi-Knoten-Plattform 116 gehostet werden, und HIFs 1181 und 118n einer integrierten einzelnen Knotenplattform 120, einen High-Radix-Schalter 122, Schalter 124 und 126, einen oder mehrere Fabric-Manager 128, einen Gateway 130, Links 132, 134, 1361 , 136n , 138, 1401 , 140n , 142, 144, 148 und zusätzliche Links und Schalter, die kollektiv als eine Cloud 150 gezeigt werden.
  • Wie vorstehend diskutiert, sind die Schalter Schicht 2-Vorrichtungen und agieren als Paketweiterleitungsmechanismen innerhalb eines Fabric. Schalter werden zentral bereitgestellt und von der Fabric-Managementsoftware verwaltet und jeder Schalter beinhaltet einen Managementagenten zum Reagieren auf Managementtransaktionen. Zentrale Bereitstellung bedeutet, dass die Weiterleitungstabellen von der Fabric-Managementsoftware programmiert sind, spezifische Fabric-Topologien und Weiterleitungsfähigkeiten, wie alternative Routen für adaptives Routing, zu implementieren. Schalter sind für das Ausführen von QoS-Funktionen, wie etwa adaptives Routing und Load-Balancing, verantwortlich und implementieren außerdem Stauungsverwaltungsfunktionen.
  • 2 zeigt Schichten der Architektur zum Übertragen von Daten über die Fabric-Links. Die Schichten beinhalten eine physikalische (PHY) Schicht, eine Link-Transfer-Unterschicht, eine Link-Fabric-Unterschicht und eine Transportschicht. Links in der 2 befindet sich das Mapping der Schichten zu dem OSI-Referenzmodell, unter dem die PHY-Schicht zu Schicht 1 (PHY-Schicht) abbildet; die Link-Transfer-Unterschicht und die Link-Fabric-Unterschicht bilden kollektiv zu Schicht 2 (Link-Schicht) ab und die Transport-Schicht bildet zu Schicht 4 (Transport-Schicht) ab.
  • In der Architektur werden Signale in der physikalischen Schicht in Ports zusammen gruppiert, die sich wie eine monolithische Entität verhalten und gesteuert und gemeldet werden können. Ein Port umfasst eine oder mehrere physikalische Spuren, wobei jede Spur aus zwei unterschiedlichen Paaren oder Fasern, die in dem physikalischen Übertragungsmedium implementiert sind, eine für jede Kommunikationsrichtung, besteht. Die Anzahl der Spuren, die ein Port umfasst, ist implementierungsabhängig; die Architektur der Link-Transfer-Unterschicht unterstützt jedoch einen endlichen Satz von Portbreiten. Spezifische Portbreiten werden als fundamentale Portbreiten unterstützt, um gemeinsame Ziele für Kabel- und Chipentwürfe zu ermöglichen. Die Portbreiten beinhalten 1x, 4x, 8x, 12x und 16x, wobei „x“ die Anzahl der physikalischen Spuren identifiziert. Unter manchen Umständen, wie etwa die Erkennung einer defekten Spur, können Links mit reduzierten Spurbreiten betrieben werden.
  • Die Link-Transfer-Unterschicht dient als die Schnittstelle zwischen der physikalischen Schicht und der Link-Fabric-Unterschicht. Die Link-Fabric-Pakete (an der Link-Fabric-Unterschicht) sind in 64-Bit Flow Control Digits (FLITs, Flits oder flits, eine ungefähre Verkürzung von Flow Control Digits) segmentiert. 3 veranschaulicht ein Beispiel einer Vielzahl von Flits 300, die in einem Bündel 302 gruppiert sind. Jeder Flit 300 enthält 64 Daten-Bits, die 8 Bytes Daten umfassen.
  • Die Link-Transfer-Unterschicht formt mehrere Spuren in Teams, die dazu fähig sind, Flits und deren zugeordnete Credit-Return-Informationen über den Link auf zuverlässige Weise zu übertragen. Dies wird unter Verwendung von 1056-Bit Bündeln, die als Link-Transfer-Pakete (LTPs) bezeichnet werden und der Link-Fabric-Unterschicht zugeordnet sind, erreicht. 3 zeigt auch den Datenteil eines LTP, der 16 Flits Daten enthält. Zusätzlich enthalten LTPs Flit-Typ-Informationen, CRC-Daten und optionale Daten (in 3 nicht gezeigt). Beispiele für LTPs werden in diversen Figuren (z. B. 5-8) veranschaulicht und nachfolgend detaillierter beschrieben.
  • Fabric-Pakete bestehen aus 64-Bit Flits und einem Flit-Typ-Bit für jeden Flit. Der erste Daten-Flit eines Fabric-Pakets wird als Head Flit bezeichnet. Der letzte Daten-Flit eines Fabric-Pakets wird als Tail Flit bezeichnet. Alle anderen Daten-Flits in einem Fabric-Paket werden als Body Flit bezeichnet. Ein Beispiel eines Fabric-Pakets 400 ist in 4 veranschaulicht.
  • Das Flit-Typ-Bit wird mit jedem Flit bereitgestellt, um Body Flits von anderen Flit-Typen zu unterscheiden. In einer Ausführungsform sind Body Flits mit dem Flit-Typ-Bit auf 1 gesetzt kodiert und enthalten 64 Bits Daten. Alle anderen Flits sind mit dem Typ-Bit auf 0 gesetzt markiert. Head Flits sind mit flit[63] auf 1 gesetzt kodiert. Alle anderen (nicht Body) Flits sind mit Flit[63] nicht auf 0 gesetzt kodiert. Tail Flits sind mit flit[62] auf 1 gesetzt kodiert. Alle anderen (nicht Body/Head) Flits sind mit flit[62] auf 0 gesetzt kodiert. Die Flit-Kodierung wird in der TABELLE 1 unten zusammengefasst. TABELLE 1
    Flit-Typ-Bit Flit[63] Flit[62] Beschreibung
    1 X X Body-Daten-Flit
    0 0 0 unbesetzt (idle), schlechtes Paket und Kontroll-Flits
    0 0 1 Tail-Daten-Flit
    0 1 X Head-Daten-Flit
  • Die Kontroll-Flits werden in TABELLE 2 zusammengefasst. Die sieben Kontroll-Flits, die ausschließlich von der Link-Transfer-Schicht (LT-Kontroll-Flits) verwendet werden, werden in Null-LTPs gesendet. Die übrigen Kontroll-Flits sind in zwei Gruppen unterteilt. Fabric-Paket (FP) Flits enthalten HeadBadPkt, BodyBadPkt und TailBadPkt Kontroll-Flits sowie die normalen Paket Head, Body und Tail Flits. Link-Fabric (LF) Befehl-Flits enthalten Idle, VLMrkr und CrdtRet Flits. FP-Flits und LF-Befehl-Flits können innerhalb zuverlässiger LTPs zum Übertragen über den Link untereinander vermischt sein. TABELLE 2
    Bezeichnung Generieren In LTP gesendet Flit-Typ Beschreibung
    Idle beides Zuverlässig LF-Befehl Idle.
    VLMrkr Link-Fabric Zuverlässig LF-Befehl VL Interleave Marker.
    CrdtRet Link-Fabric Zuverlässig LF-Befehl VL Credit Return.
    SPC Link-Fabric Zuverlässig LF-Befehl Spezialvorschlag Befehl-Flit
    TailBadPkt beides Zuverlässig Fabric-Paket Tail schlechtes Paket.
    BodyBadPkt beides Zuverlässig Fabric-Paket Body Flit in einem Fabric-Paket hatte einen nicht wiederherstellbaren
    HeadBadPkt beides Zuverlässig Fabric-Paket Head Flit in einem Fabric-Paket hatte einen nicht wiederherstellbaren
    Null Link Transfer Einzelnes Null-LTP LT-Kontrolle Null.
    RetryReq Link Transfer Null LTP-Paar LT-Kontrolle NeuübertragungsAnforderung
    RetryMrkr0 Link Transfer Einzelnes Null-LTP LT-Kontrolle Erste Neuübertragung Marker im Paar.
    RetryMrkr1 Link Transfer Einzelnes Null-LTP LT-Kontrolle Zweite Neuübertragung Marker im Paar.
    RndTripMrkr Link Transfer Null LTP-Paar LT-Kontrolle Roundtrip Marker
    Retra in RetryReq Link Transfer Null LTP-Paar LT-Kontrolle Retrain NeuübertragungsAnforderung.
    LinkWidthReq0 Link Transfer Null LTP-Paar LT-Kontrolle Erste Linkbreitenanforderung im Paar. Für Leistu ngsma nagement.
    LinkWidthReq1 Link Transfer Null LTP-Paar LT-Kontrolle Zweite Linkbreitenanforderung im Paar. Für Leistu ngsma nagement.
  • Ein Idle Befehls-Flit wird von der Link-Fabric-Schicht verwendet, wenn es keine Fabric-Paket-Flits gibt, die sich in den Datenstrom einfügen lassen. Falls die volle Breite des Datenpfads Idles enthält, entfernt die Link-Transfer-Schicht sie aus dem Flit-Strom, der in den Eingabepuffer eingefügt wird. Falls der Datenpfad sowohl Idles als auch Nicht-Idle-Flits enthält, werden die Idles nicht entfernt. Dies wird implementiert, damit die Link-Transfer-Schicht die identische Datenpfadkomposition an die Link-Fabric-Schicht auf der entfernten Seite des Links präsentiert. Falls die Link-Transfer-Schicht über keine ausstehenden Flits von der Link-Fabric-Schicht verfügt, fügt sie Idles als Original-Flits ein, die über den Link gesendet werden. Original-Flits sind, im Gegensatz zu jenen, die von einem Replaypuffer gesendet werden und neu übertragene oder neu aufgelegte („replayed“) Flits umfassen, Flits, die zum ersten Mal über den Link gesendet werden.
  • Ein Link-Transfer-Paket enthält sechzehn Flits zur Übertragung über den Link. Zuverlässige LTPs werden in einem Replaypuffer für einen Zeitraum gehalten, der lang genug ist, um zu garantieren, dass ein Fehlen einer Neuübertragungsanforderung angibt, dass er erfolgreich von dem Link-Gegenstück empfangen wurde. Es werden für jedes LTP Replaypuffer-Positionszeiger an dem Sender (NxtTxLTP) und Empfänger (NxtTxLTP) aufrechterhalten, aber nicht als Teil des LTP ausgetauscht. Wenn von dem Empfänger ein Übertragungsfehler erkannt wird, sendet er ein RetryReqLTP an den Sender, der den NextRxLTP Replaypuffer-Positionszeiger enthält. In Reaktion auf das Empfangen eines RetryReqLTP werden die LTPs in dem Replaypuffer in der ursprünglichen Reihenfolge, beginnend mit dem RetryReqLTP (Gegenstück NxtRxLTP) und endend mit der letzten Replay-Puffperposition ausgedrückt als (NxtWrLTP - 1), neu übertragen. Null-LTPs werden nicht in dem Replaypuffer gehalten und nicht neu übertragen.
  • Link-Fabric-Befehl-Flits können mit FP-Flits in einem LTP gemischt werden. LF-Befehl-Flits sind jedoch nicht Teil eines Fabric-Pakets. Sie tragen Kontrollinformationen von der Link-Fabric-Unterschicht an einem Ende eines Links zu der Link-Fabric-Unterschicht an dem anderen Ende des Links.
  • In einer Ausführungsform gibt es drei LTP-Formate, einschließlich eines Standard-Erkennungs-LTP, eines 14-Bit CRC LTP und eines erweiterten Erkennungs-LTP. Eine Ausführungsform eines Standard-Erkennungs-LTP wird in 5 gezeigt. Zusätzlich zu den sechzehn Flits verfügt jede Standard-Erkennungs-LTP über einen 16-Bit CRC, der die LTP-Inhalte abdeckt. Zu veranschaulichenden Zwecken werden die Flits in 5 als 65 Bits gezeigt, wobei Bit 64 das Flit-Typ-Bit ist.
  • Eine Ausführungsform eines 14-Bit CRC LTP wird in 6 gezeigt. Zusätzlich zu den sechzehn Flits verfügt jedes 14-Bit CRC LTP über einen Zwei-Bit Credit-Seitenbandkanal und ein 14-Bit CRC, das die LTP-Inhalte abdeckt. Flusskontrollcredits werden innerhalb von LTPs entweder in speziellen LF-Befehl-Flits oder in einem LTP-Credit-Seitenbandkanal übertragen.
  • Zusätzlich zu dem Standard-Erkennungs-LTP kann der Link auch eine optionale erweiterte Erkennungs-LTP enthalten, die sechzehn Flits hält und über vier zwölf-Bit CRC-Felder verfügt. 7 zeigt das Format einer Ausführungsform des erweiterten Erkennungs-LTP. Jedes der vier CRC-Felder deckt alle sechzehn Flits ab. Falls einer der vier CRC fehlerhaft sein sollte, wird das LTP neu übertragen. Es gibt zwei CRC-Berechnungsoptionen für die vier 12-Bit CRCs. Die erste (48b überschneidend) verwendet vier sich überschneidende Berechnungen, wobei jede Berechnung alle Bits innerhalb des LTP abdeckt. Die zweite (12b-16b CRC pro Spur) verwendet vier sich nicht überschneidende Berechnungen, wobei jede Berechnung auf alle Bits beschränkt ist, die auf einer der vier Spuren fließen.
  • Wie vorstehend diskutiert, werden die LT-Kontroll-Flits, die von der Link-Transfer-Schicht verwendet werden, in Null-LTPs gesendet. Null-LTPs konsumieren keinen Raum in dem Replaypuffer und werden nicht neu übertragen. Sie werden unter Verwendung von einem der Link-Transfer LT-Kontroll-Flits, die in TABELLE 2 oben zusammengefasst sind, unterschieden. Die meisten der Null-LTP-Typen werden in sequenziellen Paaren gesendet, damit garantiert ist, dass entweder mindestens einer der beiden von dem Link-Gegenstück fehlerfrei empfangen wird, oder dass ein RetrainRetryReq automatisch generiert wird, wenn sie beide einen Fehler enthalten. Ein Beispiel eines Standard-Erkennungs-Null-LTP ist in 8 veranschaulicht.
  • Standard-Erkennungs-Null-LTPs enthalten ein einzelnes, unterscheidendes Kontroll-Flit, 975 reservierte Bits und das Standard-Erkennungs sechzehn-Bit CRC-Feld. Erweiterte Erkennungs-Null-LTPs enthalten ein einzelnes unterscheidendes Kontroll-Flit, 975 reservierte Bits und die vier erweiterte Erkennung 12-Bit CRC-Felder. Die beiden Seitenband-Bits werden in einem Null-LTP bei Verwendung eines 14-Bit CRC ignoriert. Wie vorstehend diskutiert, setzt die Architektur drei Datenebenen von Dateneinheitsgranularität ein, um Datenübertragungen zu unterstützen: Fabric-Pakete, Flits und Link-Transfer-Pakete. Die Übertragungseinheit auf der Link-Transfer-Schicht ist ein LTP. Wie gezeigt, ist jedes LTP nominal 16 Flits lang und die tatsächliche Größe eines LTP kann, wie vorstehend beschrieben, in Abhängigkeit von dem bestimmten CRC-Schema, das verwendet wird, variieren, und die Verwendung von Bezugnahmen auf ein LTP mit einer Länge von 16 Flits entspricht der Anzahl an 64-Bit Flits Daten, die in dem LTP enthalten sind, ausschließlich der CRC-Bits und der 16-Bit 65er.
  • Die physikalische Schicht (auch bezeichnet als eine „PHY“) Struktur einer Ausführungsform eines Links, der vier physikalische Spuren umfasst, ist in 9 veranschaulicht. Die PHY definiert die physikalische Struktur der Linkverbindung und ist für den Umgang mit Einzelheiten der Operation der Signale auf einer bestimmten Spur zwischen zwei Link-Gegenstücken verantwortlich, wie etwa durch Komponenten A und B veranschaulicht. Diese Schicht verwaltet die Datenübertragung auf den Signaldrähten, einschließlich elektrischer Niveaus, Zeitplanungsaspekten und logischer Aspekte für das Senden und Empfangen jedes Informationen-Bits über parallele Spuren. Wie in 9 gezeigt, besteht die physikalische Konnektivität jedes Verbindungslinks aus vier unterschiedlichen Signalpaaren 900, die Spuren 0-3 in jede Richtung umfassen. Jeder Port unterstützt ein Linkpaar, das aus zwei unidirektionalen Links besteht, um die Verbindung zwischen zwei Gegenstückkomponenten zu vervollständigen. Dies unterstützt simultan Verkehr in beide Richtungen.
  • Komponenten mit Linkports kommunizieren unter Verwendung eines Paares unidirektionaler Punkt-zu-Punkt-Links, die als Link-Gegenstücke definiert sind, wie in 9 gezeigt. Jeder Port umfasst eine Transmit (Tx) Link-Schnittstelle und eine Receive (Rx) Link-Schnittstelle. In dem veranschaulichten Beispiel verfügt Komponente A über einen Tx-Port 902, der mit dem Rx-Port 904 der Komponente B verbunden ist. Gleichzeitig verfügt Komponente B über einen Tx-Port 904, der mit dem Rx-Port 908 der Komponente B verbunden ist. Ein unidirektionaler Link überträgt von Komponente A an Komponente B und der andere Link überträgt von Komponente B an Komponente A. Der „Sende“-Link und der „Empfang“-Link ist relativ dazu definiert, welcher Komponentenport Daten sendet und welcher Daten empfängt. In der in 9 veranschaulichten Konfiguration sendet der Sendelink der Komponente A Daten von dem Tx-Port 902 der Komponente A an den Rx-Port 904 der Komponente B. Der gleiche Sendelink der Komponente A ist der Port B Empfangslink.
  • Wie vorstehend angegeben, ist die fundamentale Einheit für das Übertragen von Daten zwischen Linkports ein LTP. Jedes LTP ist speziell für das Senden in eine Richtung über einen spezifischen Link, der von einem Sendeport und einem Empfangsport an gegenüberliegenden Enden des Links definiert wird. Ein LTP hat eine Lebenszeit von einer einzelnen Linkübertragung und LTPs werden dynamisch durch Abruf von Flits aus anzuwendenden VL-Puffern und deren Zusammenstellen, 16 auf einmal, in jeweilige LTPs generiert. Wie durch die LTP-Sendeströme 910 und 912 gezeigt, werden LTPs als ein Strom von Flits übertragen, wobei das erste und letzte Flit für individuelle LTPs durch die Head- und Tail-Flit-Bits abgegrenzt werden, wie vorstehend unter Bezugnahme auf 4 diskutiert.
  • Wie vorstehend diskutiert, definiert die Architektur einen Paketzustellmechanismus, der primär zielgeleitete Fabric-Pakete bzw. FPs mit einer Schicht 4 Nutzlast von 0 Bytes bis 10.240 Bytes umfasst. Dies bietet effiziente Unterstützung für das Senden eine Spanne von Nachrichten, die von einfachen ULP-Bestätigungen bis zu verkapselten Ethernet Jumbo Frames reicht. Fabric-Pakete repräsentieren die logische Nutzlasteinheit vor und nach einer HFI. Fabric-Pakete werden so genannt, weil sie eine Lebenszeit haben, die Ende-zu-Ende in einem Fabric ist. Konkreter gesagt: Die Lebenszeit eines Fabric-Pakets ist die Zeit, die die Übertragung des FP-Inhalts zwischen Fabric-Endpunkten, wie sie durch Quell- und Zieladressen für das FP definiert sind, dauert. Jeder Transferpfad eines FP beinhaltet die Übertragung über mindestens einen Link und kann eine Übertragung über mehrere Links beinhalten, wenn der Transferpfad einen oder mehrere Schalter quert.
  • Fabric-Zeitsynchronisierung
  • Gemäß weiteren Aspekten der hierin beschriebenen Ausführungsformen wird ein Mechanismus zum Synchronisieren von Zeittaktgebern in einem Fabric auf eine Weise bereitgestellt, dass eine extrem hohe Genauigkeit, die um mehrere Größenordnungen genauer ist als die unter Verwendung von IEEE 1588 derzeit erhaltene, erhalten wird. Die Technik ist von Natur aus skalierbar, was es ermöglicht, die Taktgeber von Zehntausenden oder Hunderttausenden von Knoten mit einem einzelnen Master-Taktgeber zu synchronisieren. Zusätzlich können mehrere Master-Taktgeber für weitere Skalierbarkeit implementiert werden.
  • Es gibt mehrere Aspekte, die für die Implementierung des Zeitsynchronisationsmechanismus kritisch sind. Der erste ist die Flit-basierte Übertragung von Informationen über einen Link und die Fähigkeit, Kontroll-Flits und Paket-Flits in dem Flit-Strom zu mischen. Es wird ein Master-Taktgeber verwendet, um eine Master-Zeit an verschiedene Endknoten (die als Slave-Knoten bezeichnet werden), die mit dem Fabric gekoppelt sind, unter Verwendung von speziellen Kontroll-Flits (SPCs), anstatt als ein Fabric-Paket, zu propagieren. Das bedeutet, dass die Master-Zeit-Informationen, wenn sie an einem Sendeport eines Schalters ankommen, sofort an der nächsten 8-Byte Flit-Grenze in den Link injiziert werden können. Es besteht keine Notwendigkeit abzuwarten, bis die Übertragung des aktuellen Pakets abgeschlossen ist. Dies minimiert die Verzögerung der Datenübertragung bei der Verbreitungsverzögerung durch den Schalter. Ein Neuversuch auf Linkebene bei einem Fehler könnte zu einer signifikanten Verzögerung bei der Datenübertragung führen, falls die Zeit-Kontroll-Flits neu aufgelegt werden müssten. Um dies zu vermeiden, werden die Zeit-Kontroll-Flits in einer Ausführungsform einfach fallengelassen, wenn sie durch ein Neuauflegungsereignis verzögert sind, wodurch das Protokoll gegenüber fehlenden Zeitaktualisierungen robust ist.
  • In einer Ausführungsform ist die Master-Zeit ein 64-Bit Wert, während Kontroll-Flits nur eine Last von 48-Bit befördern können. Die Master-Zeit wird daher in zwei unabhängigen Flits befördert, wobei eines die unteren 40 Bits trägt und eines die oberen (hohen) 32 Bits trägt, wobei sich 8 Bits überschneiden. Durch Befördern sich überschneidender Abschnitte des Zeitwerts zu den Endpunkten kann festgestellt werden, ob die beiden Abschnitte, die unabhängig ankommen und von denen jeder auf dem Weg fallengelassen werden könnte, einander entsprechen. Dies kann auch erlauben, dass der obere Abschnitt des Zeitwerts viel weniger häufig gesendet wird als der untere Abschnitt des Zeitwerts.
  • Anders als herkömmliche Schalter verwendet die Propagation von Zeitwerten über einen Schalter einen Datenpfad, der unabhängig von den Crossbars und Puffern ist, die für das propagieren von Paketen verwendet werden. In einer Instanziierung ist der Datenpfad ein Multi-Bit breiter Ringbus um die Peripherie des Schalterchips. Der Port, der die Zeitquelle für einen Schalter ist oder der der vorgeschaltete Port des Schalters in dem Taktgeberbaum ist, entfernt den Zeitwert aus dem Zeit-Kontroll-Flit, wenn er an dem Port ankommt und injiziert den Zeitwert auf den Ringbus. Ports, die nachgeschaltete Ports in dem Taktgeberbaum sind, kopieren den Zeitwert von dem Ringbus wenn er durchläuft und injizieren dann einen entsprechenden Zeit-Kontroll-Flit auf den Link an einer Flit-Grenze. Wenn der Zeitwert wieder zurück an seinem Ursprungsport ankommt, wird er aus dem Ring entfernt. Dies stellt einen Propagationspfad mit einer festen, bekannten Latenz von dem vorgeschalteten Port zu dem nachgeschalteten Port bereit.
  • An jedem Zielknoten in dem Taktgeberbaum werden die Zeitwerte von den Kontroll-Flits erfasst, wenn sie ankommen, und in MasterTimeHigh und MasterTimeLow Registern gespeichert. Wenn der Flit, der die Bits niedriger Ordnung des Zeitwerts trägt, ankommt, erfasst der Knoten auch den Wert des lokalen Taktgebers in einem LocalTime Register. Software, die den Knoten ausführt, kann dann diese Register lesen. In einer Ausführungsform stellt Hardware sicher, dass die Werte in den Registern sich während der Sequenz des Lesens der mehreren Register nicht verändern. Dies erfolgt entweder durch Verwendung von Schattenkopien oder durch Verhindern von Aktualisierungen während der Lesesequenz. Die vollständige 64-Bit Master-Zeit kann aus den beiden MasterTime Registern wiederhergestellt werden und durch die bekannte Propagationsverzögerung von dem Master-Taktgeber angeglichen werden (was separat berechnet wird). Dies gibt der Software den tatsächlichen Master-Zeitwert zum Zeitpunkt, zu dem die lokale Zeit erfasst wurde, was eine absolute Zeitsynchronisierung über das Fabric hinweg bereitstellt.
  • 10a und 10b veranschaulichen einen beispielhaften Taktgeberbaum 1000, in dem die Zeitsynchronisierung implementiert ist, gemäß einer Ausführungsform. Die wichtigsten Komponenten in dem Taktgeberbaum 1000 beinhalten einen Master-Taktgeberknoten 1002, einen Backup-Master-Taktgeberknoten 1004, Schalter 1006, 1008 und 1010 und Slave-Knoten 1012 und 1014. Ein oder mehrere Fabric-Manager 128 werden ebenfalls dargestellt. Dazu ist anzumerken, dass zwei derart gezeigt werden, dass die Kommunikationslinks zwischen den veranschaulichten Fabric-Managern und anderen Komponenten sich nicht kreuzen. Ein Taktgeberbaum kann generell einen oder mehrere Backup-Master-Taktgeberknoten enthalten.
  • Jeder der Master- und Slave-Knoten beinhaltet einen jeweiligen Taktgeber und eine HFI 1016. Master-Taktgeberknoten 1002 beinhaltet einen Master-Taktgeber 1018, Backup-Master-Taktgeberknoten 1004 enthält einen Master-Taktgeber 1020, Slave-Knoten 1012 enthält einen lokalen Taktgeber 1022 und Slave-Knoten 1014 enthält einen lokalen Taktgeber 1024. Jeder der Slave-Knoten 1012 und 1014 enthält ferner ein MasterTimeHigh Register 1026, MasterTimeLow Register 1028 und ein LocalTime Register 1030.
  • Jeder der Schalter 1006, 1008 und 1010 ist ähnlich konfiguriert und enthält mehrere Fabric-Ports 1032, von denen einige oder alle als Taktgeberports 1034 konfiguriert sein können. Ein Taktgeberport ist einem Fabric-Port ähnlich, mit zusätzlicher Funktionalität zum Ermöglichen der Propagation von Master-Taktgeber-Daten, wie nachfolgend beschrieben. Zu veranschaulichenden Zwecken werden nur vier Taktgeberports 1034 gezeigt (in grau, um sie von den anderen Fabric-Ports zu differenzieren). Es versteht sich jedoch, dass eine beliebige Anzahl von Fabric-Ports 1032 als ein Taktgeberport konfiguriert sein kann. Die vorgeschalteten Taktgeberports sind in den Figuren hierin in grau dargestellt, während die nachgeschalteten Taktgeberports in schwarz dargestellt sind.
  • Weitere Einzelheiten der Schalter 1006, 1008 und 1010 werden in 11 und 11b gezeigt. Jeder Schalter enthält ein Paar Ringbusse 1036 und 1038 (hierin auch als „Ringe“ bezeichnet). Wie veranschaulicht, werden Daten über Ring 1036 im Uhrzeigersinn weitergeleitet und über Ring 1038 gegen den Uhrzeigersinn. Jeder der Ringe 1038 enthält eine Vielzahl von Ring-Stopp-Knoten 1100, wovon an jedem Taktgeber-Port 1034 ein Paar bereitgestellt wird.
  • Jeder Port 1032 und Taktgeberport 1034 enthält einen Rx-Port 1102 und einen Tx-Port 1104, von denen jeder jeweils mit einem Rx-Puffer 1106 und Tx-Puffer 1108 gekoppelt ist. Für einen gegebenen Port ist jeder Rx-Puffer 1106 selektiv mit jedem Tx-Puffer eines anderen Ports über Logik und Schaltungsanordnungen für eine Crossbarverbindung 1110 koppelbar.
  • Zur besseren Übersicht und der Einfachheit halber werden die Kombination der Rx-Puffer 1106, Tx-Puffer 1108 und Crossbarverbindung 1110 in 10a und 10b als Schalter-Crossbar und Puffer 1040 dargestellt. Zusätzlich enthält jeder Schalter eine Weiterleitungs- und Routingtabelle 1111, die es dem Schalter ermöglicht, sein normales Fabric-Paket-Weiterleiten und Routing durchzuführen.
  • In einer Ausführungsform sind alle Ports Taktgeberports, die selektiv zur Unterstützung von vorgeschalteten und nachgeschalteten Taktgeberportfunktionen konfiguriert sein können. In einer Ausführungsform enthält Taktgeberport 1034 Zeit-Kontroll-Flit-Extraktionslogik 1112 und Zeit-Kontroll-Flit-Injektionslogik 1114, die jeweils selektiv von einem Fabric-Manager an jedem Taktgeberport aktiviert werden können, um einen Taktgeberbaum zu bilden. Zeit-Kontroll-Flit-Extraktionslogik 1112 wird an einem Rx-Port 1102 eines vorgeschalteten Taktgeberports implementiert und ist konfiguriert, Zeit-Kontroll-Flits aus einem Flit-Strom 1116 zu identifizieren und zu extrahieren. Die Zeit-Kontroll-Flits enthalten einen MasterTimeHigh SPC Flit 1118 und einen MasterTimeLow SPC Flit 1120. Wie in 12 gezeigt, umfasst ein MasterTimeHigh SPC Flit 1118 einen 65-Bit Flit, in dem die untersten vier Bytes (Bytes 0-3) verwendet werden, um die oberen 32 Bits des MasterTimeHigh Taktgeberwerts zu speichern. Wie in 13 gezeigt, umfasst ein MasterTimeLow SPC Flit 1120 einen 65-Bit Flit, in dem die untersten fünf Bytes (Bytes 0-4) verwendet werden, um die unteren 40 Bits des MasterTimeLow Taktgeberwerts zu speichern. Dementsprechend sollte Byte 0 von MasterTimeHigh SPC Flit 1118 und Byte 4 von MasterTimeLow SPC Flit 1120 den gleichen Wert enthalten, wenn die Zeit-Kontroll-Flits einander entsprechen.
  • In einer Ausführungsform extrahiert die Zeit-Kontroll-Flit-Extraktionslogik 1112 die 40 Bits eines MasterTimeLow SPC Flits (die MasterTimeLow Daten) oder die 32 Bits des MasterTimeHigh SPC Flits (die MasterTimeHigh Daten) und verkapselt die Daten (separat) in einem Paket und sendet die Daten auf Ringe 1036 und 1038. In einer anderen Ausführungsform ist der MasterTimeLow SPC Flit oder MasterTimeHigh SPC Flit selbst in dem Paket verkapselt und wird auf Ringen 1036 und 1038 gesendet. Während jedes Ring-Stopp-Zyklus rücken die Daten zu dem nächsten Ring-Stopp-Knoten vor, bis sie schließlich einen nachgeschalteten Taktgeberport-Ring-Stopp-Knoten erreichen. An diesem Punkt wird die Zeit-Kontroll-Flit-Injektionslogik 1114 befähigt, die Daten von dem Ring zu kopieren, die 40-Bit MasterTimeLow Daten oder 32-Bit MasterTimeHigh Daten (wie zutreffend) zu entkapseln, einen neuen MasterTimeLow oder MasterTimeHigh SPC Flit zu generieren und den neuen Flit in einen Flit-Strom 1118, der aktuell von dem Tx-Port, der der Zeit-Kontroll-Flit-Injektionslogik zugeordnet ist, ausgesendet wird, zu injizieren. In der Ausführungsform, die die gesamten MasterTimeLow und MasterTimeHigh SPC Flits verkapselt, werden die Flits extrahiert und in den Flit-Strom injiziert, ohne dass eine Generierung neuer MasterTimeLow und MasterTimeHigh SPC Flits erforderlich ist. Wie vorstehend diskutiert, können diese Zeit-Kontroll-Flits sofort an der nächsten 8-Byte Grenze in den Flit-Strom injiziert werden.
  • Der Fabric-Schalter kann auch einen lokalen Taktgeber 1116 oder einen Master-Taktgeber 1118 implementieren. In einer Ausführungsform kann ein Fabric-Schalter konfiguriert sein, die Funktion eines Master-Taktgeberknotens durchzuführen, und befindet sich an der Wurzel des Taktgeberbaums. In diesem Fall implementiert der Fabric-Schalter keinen vorgeschalteten Port. Wenn der Fabric-Schalter in einem Fabric arbeitet, das einen separaten Master-Taktgeberknoten enthält, kann der lokale Taktgeber 1116 des Schalters auf eine ähnliche Weise wie die Slave-Knoten synchronisiert werden, wie nachfolgend beschrieben. 11b zeigt weitere Einzelheiten eines Paares von Taktgeberports 1134a und 1134b, die jeweils von einem Fabric-Manager als ein vorgeschalteter Taktgeberport und ein nachgeschalteter Taktgeberport konfiguriert sind. Jeder Empfangsport 1102 enthält einen Rx-Eingabe-FIFO-Puffer 1120, in dem Flits aus einem Flit-Strom gepuffert werden. Ein CRC-Wert in jedem LTP wird verwendet, um zu verifizieren, ob alle Flits in einem LTP fehlerfrei empfangen werden. Falls nicht, wird ein Zuverlässigkeitsmechanismus verwendet, der das LTP veranlasst, erneut vom Sender gesendet zu werden. Nachdem ein LTP als erfolgreich empfangen verifiziert wurde, wird es aus dem Rx-Eingabe-FIFO-Puffer 1120 in einen Empfängerpuffer 1106 geschoben, der weiterhin als „(INQ)“ gekennzeichnet ist, was die Empfangspufferfunktionen als eine Eingabewarteschlange angibt.
  • Zusätzlich extrahiert die Zeit-Kontroll-Flit-Extraktionslogik 1112, nachdem ein LTP erfolgreich empfangen wurde, die MasterTimeLow SPC Flits und MasterTimeHigh SPC Flits und leitet sie entlang eines Bypassschaltungspfades weiter, wie durch einen Weiterleitungspfad 1122 dargestellt. Jeder Empfangsport 1102 ist mit den beiden Ringbussen 1036 und 1038 verbunden. In der Zwischenzeit konfiguriert der Fabric-Manager jeden Tx-Port 1104 eines nachgeschalteten Taktgeberports derart selektiv, dass er mit dem Ringbus gekoppelt ist, der in der geringsten Latenz beim Weiterleiten von Daten von einem vorgeschalteten Taktgeberport zu einem nachgeschalteten Taktgeberpfad resultiert. In dem veranschaulichten Beispiel wird Tx-Port 1104b selektiv mit Ringbus 1038 gekoppelt. Wie sich sehen lässt, reduziert die Verwendung eines Paares von Ringbussen die Bypass-Schaltungsanordnungslänge zwischen manchen des Paares von vorgeschalteten Rx- und nachgeschalteten Tx-Ports (im Vergleich zur Verwendung von nur einem einzelnen Ring). Bei Empfang der MasterTimeLow und MasterTimeHigh Daten (oder Flits, falls Flits entlang des Bypass-Schaltungsanordnungspfads weitergeleitet werden) wird ein entsprechender Flit in einen Tx-Ausgangspuffer 1124 am Tx-Port 1104 eingefügt und anschließend auf das Fabric zu dem nächsten Sprung in dem Taktgeberbaum ausgesendet.
  • Es gibt Implementierungen, in denen es nützlich wäre, den Zeitwert in dem Zeit-Kontroll-Flit zu aktualisieren, wenn er durch einen Schalter läuft. Falls es zum Beispiel zu einer unerwarteten Verzögerung beim Propagieren des Zeitwerts durch den Schalter kommt, könnte eine Implementierung den Zeitwert um den Betrag der unerwarteten Verzögerung inkrementieren, anstatt den Zeitwert unverändert durchlaufen zu lassen. Falls der Sendeport sich zum Beispiel in der Mitte einer Neuversuchssequenz befände, könnte der Zeitwert aktualisiert und dann gesendet werden, nachdem der Neuversuch abgeschlossen wurde. Unter weiterer Bezugnahme auf das Flussdiagramm 1400 der 14 wird die Feststellung einer Taktgeberratefehlanpassung für einen lokalen Taktgeber relativ zum Master-Taktgeber 1018 für Taktgeberbaum 1000 gemäß einer Ausführungsform wie folgt implementiert. Wie durch die äußere Schleife gezeigt, werden die folgenden Operationen auf eine zyklische Weise, wie etwa auf periodischer Basis, ausgeführt. In einem Block 1402 liest HFI 1016 oder irgendeine andere Komponente am Master-Taktgeberknoten 1002 (nicht gezeigt) Master-Taktgeber 1018 und generiert und injiziert MasterTimeHigh und MasterTimeLow SPC Flits 1118 und 1120 in eine Flit-Strom 1116 Ausgabe aus dem Sende (Tx) Port der HFI. Wie vorstehend beschrieben, enthält der MasterTimeHigh SPC Flit die MasterTimeHigh Daten, die die oberen 32 Bits der 64-Bit Taktgeberdaten umfassen, und der MasterTimeLow SPC flit enthält die unteren 40 Bits (die MasterTimeLow Daten) der 64-Bit Master-Taktgeberdaten. Wie ebenfalls vorstehend diskutiert, ermöglicht die Verwendung einer Überschneidung der 8 Bits, die den Low und MasterTimeHigh SPC Flits gemeinsam sind, einen Vergleich zum Verifizieren, dass die Taktgeberdaten sich entsprechen. Das Resultat von Block 1202 ist es, ein MasterTimeHigh SPC Flit 1118 und ein MasterTimeLow SPC Flit 1120 in Flit-Strom 1116 zu injizieren, der in Richtung eines Empfangsports für einen vorgeschalteten Taktgeberport 1134a am Schalter 1106 gesendet wird, wie in 10a gezeigt. Die MasterTimeHigh und MasterTime Low SPC Flits können in den Flit-Strom entweder als sequenzielle Paare oder in nicht sequenzielle Slots in dem Flit-Strom injiziert werden. Wie vorstehend beschrieben, müssen die MasterTimeHigh Daten nicht mit jeder Übertragung von Zeittaktgeberdaten gesendet werden, da dieser obere 32-Bit Wert sich über kürzere Zeiträume nicht verändert.
  • Die Operationen der Blöcke 1404 und 1406 werden an jedem Schalter in einem Gesamt-Taktgeberbaumpfad zwischen dem Master-Taktgeberknoten und einem gegebenen Slave-Knoten vor dem letzten Schalter in dem Pfad, bei dem die Operation eines Blocks 1408 anstatt der eines Blocks 1406 durchgeführt wird, durchgeführt. Zu veranschaulichenden Zwecken wird die Anzahl der Schalter als eine Ganzzahl n gezeigt, wobei n ein oder mehrere Schalter sein kann bzw. können. Falls es nur einen Schalter gibt, wird die Operation des Blocks 1406 übersprungen und des erfolgt keine Schleife zurück zu einem nächsten Schalter.
  • In Block 1404 werden die Zeit-Kontroll-Flits (MasterTimeHigh und MasterTimeLow SPC Flits), bei Empfang von einem Emfpangs- (Rx) Port des Taktgeberports 1134a, der als ein vorgeschalteter Taktgeberempfangsport konfiguriert ist (z. B. Rx-Port des Taktgeberports 1134a in 10a und 10b), identifiziert und die entsprechenden 32-Bit MasterTimeHigh und 40-Bit MasterTimeLow Daten werden extrahiert. Die MasterTimeHigh und MasterTimeLow Daten (wie zutreffend) werden dann um jeden der Ringe 1036 und 1038 gesendet, wobei sie sequenziell zu jedem Ring-Stopp-Knoten vorrücken, bis die Durchquerung jedes Rings abgeschlossen ist. Optional werden die MasterTimeHigh und MasterTimeLow SPC Flits selbst um die Ringe 1036 und 1038 gesendet. Wie in Block 1406 gezeigt, werden, für jeden Schalter entlang des Taktgeberbaumpfads, der einen Schalter als den nächsten Sprung hat, MasterTimeHigh und MasterTimeLow SPC Flits (wie zutreffend) in den Flit-Strom an dem Tx-Port des nachgeschalteten Taktgeberports, der dafür verwendet wird, die Master-Taktgeberdaten an den nächsten Schalter in dem Taktgeberbaum zu senden, injiziert. Eine ähnliche Operation wird in Block 1208 für den letzten Schalter entlang des Taktgeberbaumpfads zu einem Ziel-Slave-Knoten anstatt eines nächsten Schalters durchgeführt. Die entsprechenden in 10a und 10b gezeigten nachgeschalteten Taktgeberports enthalten einen nachgeschalteten Taktgeberport 1134b für Schalter 1006, nachgeschaltete Taktgeberports 1134d und 1134e für Schalter 1008 und einen nachgeschalteten Taktgeberport1134g für Schalter 1010.
  • Weiter werden an einem Block 1410, bei Empfang der MasterTimeHigh und MasterTimeLow SPC Flits an einer HFI eines Slave-Knotens, die MasterTimeHigh und MasterTimeLow Daten extrahiert und in MasterTimeHigh Register 1026 bzw. MasterTimeLow Register 1028 geschrieben. In einer Ausführungsform kann jedes dieser Register mehrere Proben von MasterTimeHigh und MasterTimeLow Daten speichern. Optional speichert jedes Register eine einzelne Probe, die von Software oder Firmware bei Speichern in dem Register gelesen wird. Zusammen mit dem Schreibvorgang in das MasterTimeLow Register 1028, wie durch Logik an dem Slave-Knoten erkannt, wird eine erste Probe des lokalen Taktgebers an dem Slave-Knoten (z. B. lokaler Taktgeber 1022 für Slave-Knoten 1012 und lokaler Taktgeber 1024 für Slave-Knoten 104) genommen und die entsprechende lokale Zeitprobe wird in dem LocalTime Register 1030 gespeichert. Zusammen mit einem nachfolgenden Schreibvorgang in das MasterTimeLow Register 1028 (der während des nächsten Zyklus erfolgen würde), wird eine zweite Probe des lokalen Taktgebers genommen und die Differenz zwischen der ersten und der zweiten lokalen Taktgeberprobe wird als ein ΔtSlave 1212 berechnet. Derweil werden jeweilige Proben der MasterTimeHigh und MasterTimeLow Werte aus dem MasterTimeHigh Register 1026 und MasterTimeLow Register 1028 gelesen, um aufeinanderfolgende Master-Taktgeber-Zeitproben zu generieren, um ein ΔtMaster 1214 zu berechnen. Optional wird ein zweiter MasterTimeLow Wert von einem ersten MasterTimeLow Wert subtrahiert, um ein ΔtMaster 1214 zu berechnen.
  • Die Differenz zwischen ΔtMaster und ΔtSlave, dividiert durch ΔtSlave, wird dann berechnet, um eine Taktgeberratefehlanpassung 1216 zwischen dem Master und lokalen (Slave) Taktgeber für den gegebenen Zeitraum zwischen Proben zu berechnen. In einer Ausführungsform wird zum Beispiel die äußere Schleife des Flussdiagramms 1200 ungefähr 10 Mal pro Sekunde auf einer periodischen Basis wiederholt und somit würde die Taktgeberfehlanpassung über 1/10 einer Sekunde (oder welcher Zeitraum von Periodizität auch immer verwendet wird) gemessen. In einer Ausführungsform ist LocalTime Register 1030 konfiguriert, mehrere lokaler Taktgeberproben zu speichern und die Differenz zwischen aufeinanderfolgenden Empfangsvorgängen von Master-Taktgeberdaten kann präzise berechnet werden (bis hinunter auf Granularitätsebene des lokalen Taktgebers, z. B. in einer Größenordnung von einigen Nanosekunden).
  • Zusätzlich zum Feststellen von Taktgeberratenfehlanpassungen für den Taktgeber jedes Slave-Knotens relativ zu dem Taktgeber des Master-Knotens sind die Taktgeber des Slave-Knotens mit dem Master-Taktgeber synchronisiert. Operationen zum Implementieren einer Ausführungsform dieses Prozesses werden in einem Flussdiagramm 1500 in 15 gezeigt. Wie durch einen Schleifenstartblock 1502 und die entsprechende äußere Schleife gezeigt, werden die Operationen des Flussdiagramms 1500 für jeden Slave-Knoten in einem Master-Taktgeberbaum durchgeführt.
  • Wie in dem Startschleifenblock 1504 und einem Block 1506 dargestellt, wird die Linksegmentlatenz für jedes Fabric-Linksegment in dem Taktgeberbaumpfad berechnet. In einer Ausführungsform erfolgt dies durch Messen einer Zeitdauer zum Vervollständigen eines Rundtrippfads über ein gegebenes Linksegment und darauffolgendes Subtrahieren des Zeitabschnitts, der durch das Verarbeiten an beiden Enden des Links in Anspruch genommen wurde. In einer Ausführungsform wird die Latenz für jedes Abschnittssegment in dem Master-Taktgeberbaum an einem ursprünglichen Fabric-Port berechnet (z. B. einem nachgeschalteten Taktgeberport an einem Schalter) und die resultierende Berechnung wird an einen oder mehrere Fabric-Manager gesendet, der bzw. die die Informationen in einer Linksegmentlatenztabelle oder dergleichen speichert bzw. speichern, wie in einem Block 1512 gezeigt. Ein beispielhafter Satz von Linksegmenten für den Master-Taktgeberbaumpfad von Master-Taktgeber-Knoten 1002 zu Slave-Knoten 1012 enthält Linksegmente 1042, 1044 und 1046 mit entsprechenden Linksegmentlatenzen, die als Δt1, Δt3, bzw. Δt5 dargestellt werden. Der Master-Taktgeberbaumpfad von Master-Taktgeberknoten 1002 zu Slave-Knoten 1014 enthält Linksegmente 1042, 1022, 1048 und 1050 mit entsprechenden Linksegmentlatenzen, die als Δt1, At3, Δt7, bzw. Δt9 dargestellt werden.
  • Als Nächstes wird, wie durch einen Startschleifenblock 1508 und einen Block 1510 gezeigt, die Schalterringpfadlatenz an jedem Schalter entlang des Master-Taktgeberbaumpfads berechnet. Diese Berechnung kann auf mehrere Weisen durchgeführt werden, einschließlich des Nehmens von Latenzzeitmessungen zwischen Ring-Stopp-Knoten an einem Schalter und Berechnens der Latenz unter Verwendung eines Modellierungswerkzeugs, das verwendet wird, um die Schaltungsanordnung in einem Schalter zu entwerfen. Generell müssten für eine gegebene Schalterkonfiguration diese Messungen vor Installieren des Schalters in dem Fabric nur einmal durchgeführt werden (oder mehrere Male unter Bildung eines Durchschnitts). Manche Schalter können konfiguriert sein, mit mehr als einer Ring-Taktgeberfrequenz zu arbeiten und erfordern somit möglicherweise ein Testen an jeder unterstützten Ring-Taktgeberfrequenz. Bei Festlegen einer Ringpfadlatenzberechnung (oder eines Berechnungssatzes für einen Schalter) werden die entsprechenden Ringpfad- und Latenzdaten an einen oder mehrere Fabric-Manager gesendet, der bzw. die die Daten in einer Ringpfadlatenztabelle oder dergleichen speichert bzw. speichern, wie durch Block 1512 gezeigt.
  • In 10a und 10b werden beispielhafte Ringpfad- und Latenzmessungen für Schalter 1006 gezeigt (Ringpfad 1052 und Latenz Δt2), Schalter 1008 (Ringpfade 1054 und 1056 und Latenzen Δt4 und Δt6) und Schalter 1010 (Ringpfad 1058 und Latenz Δt8). Ähnliche Latenzen würden für andere Ringpfade in jedem Schalter berechnet. Wie zuvor werden diese Informationen an einen Fabric-Manager (z. B. Fabric-Manager 128) gesendet, der die Ringpfadlatenzdaten in einer Tabelle oder dergleichen speichert.
  • In einem Block 1514 wird der aggregierte Gesamtwert der Linksegmentlatenzen und Schalterringlatenzen für einen gegebenen Taktgeberbaumpfad von dem Master-Knoten zu jedem Slave-Knoten wie folgt berechnet: Gesamt Taktgeberbaumpfadlatenz= Δ t ( Linksegmente ) + Δ t ( Schalterringpfade )
    Figure DE112016005917T5_0001
  • Der Fabric-Manager sendet dann die Taktgeberbaumlatenz an jeden Slave-Knoten, wie in einem Block 1516 gezeigt. In einer Ausführungsform werden diese Informationen als ein ClockOffset auf dem Slave-Knoten gespeichert, entweder im LocalTime Register 1030 oder einem separaten ClockOffset Register 1602 (siehe 16; zur besseren Übersicht nicht in 10a und 10b gezeigt).
  • 16 zeigt ein Diagramm 1600, das Operationen darstellt, die an jedem Slave-Knoten durchgeführt werden, um dessen lokalen Taktgeber mit dem Master-Taktgeber zu synchronisieren. Wie zuvor werden die MasterTimeHigh und MasterTimeLow Daten in Block 1210 extrahiert und in MasterTimeHigh und MasterTimeLow Register 1026 und 1028 geschrieben. Es wird eine entsprechende 64-Bit Master-Taktgeberzeit festgestellt. In einem Aspekt wird die Master-Taktgeberzeit als ein absoluter Zeitwert zu der Zeit, zu der sie an dem Master-Taktgeber genommen wird, erwogen. Der ClockOffset Wert, der der gesamten Taktgeberbaumpfadlatenz von dem Master-Knoten zu dem Slave-Knoten entspricht, wird dann zu der Master-Taktgeberzeit addiert, um die absolute Zeit an dem Slave-Knoten zu erhalten. Der lokale Taktgeber des Slave-Knotens wird dann nach dem Master-Taktgeber synchronisiert. Bei einer bekannten Taktgeberfehlanpassungsrate können verschiedene Techniken zum Synchronisieren des Taktgebers des Slave mit dem Master-Taktgeber eingesetzt werden, wie etwa, aber nicht beschränkt auf Techniken, die in IEEE 1588 beschrieben sind.
  • 16 zeigt ein Diagramm 1600, das Operationen darstellt, die an jedem Slave-Knoten durchgeführt werden, um dessen lokalen Taktgeber mit dem Master-Taktgeber zu synchronisieren. Wie zuvor werden die MasterTimeHigh und MasterTimeLow Daten in Block 1210 extrahiert und in MasterTimeHigh und MasterTimeLow Register 1026 und 1028 geschrieben. Es wird eine entsprechende 64-Bit Master-Taktgeberzeit festgestellt. In einem Aspekt wird die Master-Taktgeberzeit als ein absoluter Zeitwert zu der Zeit, zu der sie an dem Master-Taktgeber genommen wird, erwogen. Der ClockOffset Wert, der der gesamten Taktgeberbaumpfadlatenz von dem Master-Knoten zu dem Slave-Knoten entspricht, wird dann zu der Master-Taktgeberzeit addiert, um die absolute Zeit an dem Slave-Knoten zu erhalten. Der lokale Zeitgeber des Slave-Knotens wird dann nach dem Master-Taktgeber synchronisiert. Bei einer bekannten Taktgeberfehlanpassungsrate können verschiedene Techniken zum Synchronisieren des Taktgebers des Slave mit dem Master-Taktgeber eingesetzt werden, wie etwa, aber nicht beschränkt auf Techniken, die in IEEE 1588 beschrieben sind.
  • Unter manchen Umständen kann es notwendig sein, den aktuellen Master-Taktgeber-Knoten durch einen anderen Master-Taktgeber-Knoten zu ersetzen. Diese Situation wird zum Beispiel in 10b gezeigt, worin Master-Taktgeber-Knoten 1002 versagt hat (oder anderweitig nicht zum Unterstützen von Master-Taktgeber-Operationen zur Verfügung steht) und durch Master-Taktgeber-Backup-Knoten 1004 ersetzt wurde. Die HFI des (jetzigen) Master-Taktgeber-Knotens 1004 ist über ein Linksegment 1052 mit vorgeschaltetem Taktgeberport 1134a von Schalter 1006 verbunden, wobei die entsprechende Linksegmentlatenz als Δt10 dargestellt wird.
  • Es ist anzumerken, dass ein Ersatz-Master-Taktgeber-Knoten nicht mit dem gleichen Schalter verbunden sein muss, wie ein vorheriger Master-Taktgeber-Knoten. Vielmehr könnte ein Master-Taktgeber-Knoten mit verschiedenen Fabric-Schaltern verbunden sein. Zusätzlich müssen, wenn ein neuer Master-Taktgeber-Knoten implementiert ist, die Latenzen für die Taktgeberbaumpfade von dem Master-Taktgeber-Knoten zu jedem Slave-Knoten Gesamtlatenzen generell neu berechnet werden.
  • Die hierin offenbarten Ausführungsformen stellten eine signifikante Verbesserung gegenüber dem Stand der Technik dar. Der Fabric-Zeitsynchronisierungsmechanismus und das Protokoll stellen zum Beispiel Größenordnungen einer besseren Genauigkeit als Nur-Software-Lösungen bereit. Der IEEE 1588-Ansatz für Ethernet und der PTM-Ansatz für PCIe gehen davon aus, dass die Propagationsverzögerung für die Master-Taktgeberinformationen jedes Mal, wenn die Informationen gesendet werden, aufgrund variierender Grade von Stauung in dem Fabric variieren kann. Diese Protokolle versuchen die tatsächliche Propagationsverzögerung durch Senden von Erwiderungen und Messen der Rundtripverzögerungen zu messen. Dies macht eine komplexe Logik oder eine Firmwarebasierte Protokollsteuereinrichtung in Schaltern erforderlich, um die Berechnungen jedes Sprungs zu implementieren.
  • Das hierin beschriebene Master-Taktgeber-Synchronisierungsprotokoll verwendet einen dedizierten Bypassdatenpfad innerhalb der Schalter, um eine bekannte Propagationsverzögerung (Latenz) von der Quelle der Master-Zeitinformationen zu allen nachgeschalteten Schalterports, die Teil des definierten Taktgeberbaums sind, bereitzustellen. Dieses Protokoll kann eine viel bessere Genauigkeit liefern, weil bei der Propagationsverzögerung von einer Master-Zeitprobe zu einer anderen viel weniger Schwankung besteht.
  • Weitere Aspekte des hierin beschriebenen Gegenstands sind in den folgenden nummerierten Abschnitten dargelegt:
    1. 1. Ein Verfahren wird in einer Umgebung, einschließlich eines Master-Taktgeber-Knotens, der kommunikativ mit einer Vielzahl von Slave-Knoten über ein Fabric, das eine Vielzahl von Fabric-Schaltern und eine Vielzahl von Fabric-Links umfasst, gekoppelt ist, durchgeführt, umfassend:
      • Weiterleiten von Master-Taktgeberzeitdaten, die von einem Master-Taktgeber, der an dem Master-Taktgeber-Knoten arbeitet, generiert werden, an jeden der Vielzahl von Slave-Knoten über Taktgeberbaumpfade mit festen Latenzen;
      • für einen gegebenen Slave-Knoten, Feststellen der festen Latenz des Taktgeberbaumpfads von dem Master-Taktgeber-Knoten zu dem Slave-Knoten; und
      • Synchronisieren eines lokalen Taktgebers für den Slave-Knoten und den Master-Taktgeber, der an dem Master-Taktgeber-Knoten arbeitet, unter Verwendung der Master-Taktgeberzeitdaten, die von dem Slave-Knoten erhalten werden, und der festen Latenz des Taktgeberbaumpfads von dem Master-Taktgeber-Knoten zu dem Slave-Knoten, die festgestellt wird,
      • wobei, für zumindest einen Teil der Slave-Knoten, die Taktgeberbaumpfade von dem Master-Taktgeber-Knoten zu jenen Slave-Knoten mehrere Fabric-Schalter queren.
    2. 2. Das Verfahren nach Abschnitt 1, wobei jeder der mehreren Fabric-Schalter, die für einen gegebenen Weiterleitungspfad zwischen dem Master-Taktgeber-Knoten und einem Slave-Knoten gequert werden, umfasst:
      • eine Vielzahl von Ports, von denen jeder einen Empfangsport enthält, der operativ mit einem Empfangspuffer gekoppelt ist, und einen Sendeport, der operativ mit einem Sendepuffer verbunden ist;
      • Schaltungsanordnung, die, während des Betriebs, auswählbare Verbindung zwischen einem Empfangspuffer eines ersten Ports und einem Sendepuffer eines zweiten Ports befähigt;
      • mindestens einen Bypassschaltungspfad zwischen einem Empfangsport eines vorgeschalteten Taktgeberports und einem Sendeport eines nachgeschalteten Taktgeberports, der ein Weiterleiten von an dem Empfangsport empfangenen Daten an den Sendeport entlang eines Bypassschaltpfads befähigt.
    3. 3. Das Verfahren nach Abschnitt 2, wobei der mindestens eine Schaltungspfad einen Ringbus umfasst, mit dem zumindest ein Teil der Empfangsports und Sendeports operativ gekoppelt sind.
    4. 4. Das Verfahren nach Abschnitt 2 oder 3, wobei der mindestens eine Schaltungspfad erste und zweite Ringbusse umfasst, mit denen mindestens ein Teil der Empfangsports und Sendeports operativ gekoppelt sind, wobei Daten für den ersten Ringbus im Uhrzeigersinn weitergeleitet werden und Daten für den zweiten Ringbus gegen den Uhrzeigersinn weitergeleitet werden, und wobei die Daten auf Basis dessen, welcher Ringbus in der geringsten Latenz resultiert, entlang dem ersten oder dem zweiten Ringbus weitergeleitet werden.
    5. 5. Das Verfahren nach einem der vorstehenden Abschnitte, wobei ein Taktgeberbaumpfad zwischen einem Master-Taktgeber-Knoten und einem Slave-Knoten eine Vielzahl von Fabric-Schaltern und eine Vielzahl von Linksegmenten, die die Vielzahl von Fabric-Schaltern in Kommunikation verbinden, queren, und wobei das Feststellen der festen Latenz eines Taktgeberbaumpfads umfasst:
      • Feststellen einer Latenz für jedes der Vielzahl von Linksegmenten;
      • Feststellen einer Schalterweiterleitungslatenz von einem vorgeschalteten Taktgeberport zu einem nachgeschalteten Taktgeberport innerhalb von jedem der Vielzahl von Fabric-Schaltern, wobei der Taktgeberbaumpfad ein erstes Linksegment enthält, das mit dem vorgeschalteten Taktgeberport gekoppelt ist, und ein zweites Linksegment, das mit dem nachgeschalteten Taktgeberport verbunden ist; und
      • Aggregieren der Latenzen für jedes der Vielzahl von Linksegmenten und der Schalterweiterleitungslatenzen.
    6. 6. Das Verfahren nach einem der vorstehenden Abschnitte, wobei Daten über die Vielzahl von Fabric-Links unter Verwendung eines Stroms von Flusskontrolleinheiten (Flow Control Units, Flits) übertragen werden, und wobei die Master-Taktgeberzeitdaten innerhalb mindestens eines Flits enthalten sind, das entlang den Taktgeberbaumpfaden von dem Master-Taktgeberknoten zu der Vielzahl von Slave-Knoten weitergeleitet wird.
    7. 7. Das Verfahren nach Abschnitt 6, wobei die Master-Taktgeberzeitdaten in ersten und zweiten Flits enthalten sind, wobei das erste Flit einen oberen Bit-Abschnitt der Master-Taktgeberzeitdaten umfasst und das zweite Flit einen unteren Bit-Abschnitt der Master-Taktgeberzeitdaten enthält.
    8. 8. Das Verfahren nach Abschnitt 7, wobei ein Abschnitt des oberen Bit-Abschnitts der Master-Taktgeberzeitdaten in dem ersten Flit und der untere Bit-Abschnitt der Master-Taktgeberzeitdaten in dem zweiten Flit sich überschneiden, ferner umfassend das Vergleichen der Master-Taktgeberzeitdatenbits in dem sich überschneidenden Abschnitt, um festzustellen, dass sich der obere Bit-Abschnitt und der untere Bit-Abschnitt der Master-Taktgeberzeitdaten entsprechen.
    9. 9. Das Verfahren nach Abschnitt 6, ferner umfassend:
      • Empfangen eines Flit-Stroms, umfassend einen Strom von Flits, an einem Empfangsport eines vorgeschalteten Taktgeberports eines Fabric-Schalters, wobei der Empfangsport über einen zugeordneten Empfangspuffer verfügt;
      • Erkennen, dass eine erste Vielzahl von Flits in dem Flit-Strom Daten enthält, die Fabric-Paketen entsprechen;
      • Speichern der ersten Vielzahl von Flits in einem Empfangspuffer für den Empfangsport;
      • Erkennen, dass ein Flit in dem Flit-Strom einem Zeit-Kontroll-Flit entspricht, das Master-Taktgeberzeitdaten enthält;
      • Extrahieren der Master-Taktgeberzeitdaten aus dem Zeit-Kontroll-Flit;
      • Weiterleiten der Master-Taktgeberzeitdaten von dem Empfangsport an einen nachgeschalteten Taktgeberport in dem Fabric-Schalter entlang eines Bypassschaltungspfads;
      • Verkapseln der Master-Taktgeberzeitdaten in einem neuen Zeit-Kontroll-Flit, der an einem Sendeport des nachgeschalteten Taktgeberports generiert wird; und
      • Injizieren des neuen Zeit-Kontroll-Flits in einen Flit-Strom, der auf einen Fabric-Link von dem Sendeport ausgesendet wird.
    10. 10. Das Verfahren nach Abschnitt 6, ferner umfassend:
      • Empfangen eines Flit-Stroms, umfassend einen Strom von Flits, an einem Empfangsport eines vorgeschalteten Taktgeberports eines Fabric-Schalters, wobei der Empfangsport über einen zugeordneten Empfangspuffer verfügt;
      • Erkennen, dass ein Flit in dem Flit-Strom einem Zeit-Kontroll-Flit entspricht, das Master-Taktgeberzeitdaten enthält;
      • Weiterleiten des Zeit-Kontroll-Flits von dem Empfangsport an einen nachgeschalteten Taktgeberport in dem Fabric-Schalter ohne Puffern des Zeit-Kontroll-Flits in dem Empfangspuffer, der dem Empfangsport zugeordnet ist; und
      • Injizieren des Zeit-Kontroll-Flits in einen Flit-Strom, der auf einen Fabric-Link von einem Sendeport des nachgeschalteten Taktgeberports ausgesendet wird.
    11. 11. Das Verfahren nach Abschnitt 6, wobei, für jeden Slave-Knoten, das mindestens eine Flit, das die Master-Taktgeberdaten enthält, entlang eines Taktgeberbaumpfads von dem Master-Taktgeber-Knoten an den Slave-Knoten auf eine Weise weitergeleitet wird, die Datenintegrität der Master-Taktgeberdaten, die an den Slave-Knoten weitergeleitet werden, garantiert.
    12. 12. Das Verfahren nach einem der vorstehenden Abschnitte, ferner das Festellen einer Taktgeberratenfehlanpassung zwischen dem Master-Taktgeber und einem lokalen Taktgeber auf einem Slave-Knoten umfassend.
    13. 13. Das Verfahren nach Abschnitt 12, wobei das Feststellen der Taktgeberratenfehlanpassung zwischen dem Master-Taktgeber und dem lokalen Taktgeber umfasst:
      • Empfangen erster Master-Taktgeberzeitdaten an dem Slave-Knoten;
      • Speichern einer ersten Master-Taktgeberzeitprobe, die den ersten Master-Taktgeberzeitdaten an dem Slave-Knoten entspricht;
      • zusammen mit dem Empfangen der ersten Master-Taktgeberzeitdaten, Speichern einer ersten Probe des lokalen Taktgebers an dem Slave-Knoten;
      • Empfangen zweiter Master-Taktgeberzeitdaten an dem Slave-Knoten;
      • Speichern der zweiten Master-Taktgeberzeitdaten an dem Slave-Knoten;
      • zusammen mit dem Empfangen der zweiten Master-Taktgeberzeitdaten, Speichern einer zweiten Probe des lokalen Taktgebers an dem Slave-Knoten;
      • Subtrahieren der ersten Master-Taktgeberzeitdaten von den zweiten Master-Taktgeberzeitdaten, um eine Master-Taktgeberzeitprobendifferenz zu erhalten;
      • Subtrahieren der ersten Probe von der zweiten Probe des lokalen Taktgebers, um eine Zeitdifferenz für die lokale Taktgeberzeitprobendifferenz zu erhalten; und
      • Subtrahieren der lokalen Taktgeberzeitprobendifferenz von der Master-Taktgeberzeitprobendifferenz und Dividieren des Resultats durch die lokale Taktgeberzeitprobendifferenz, um die Taktgeberratenfehlanpassung zu erhalten.
    14. 14. Das Verfahren nach einem der vorstehenden Abschnitte, ferner umfassend:
      • Ersetzen eines Master-Taktgeber-Knotens durch einen neuen Master-Taktgeber-Knoten; und
      • Weiterleiten von Master-Taktgeberzeitdaten, die von einem Master-Taktgeber, der an dem neuen Master-Taktgeber-Knoten arbeitet, generiert werden, an jeden der Vielzahl von Slave-Knoten über Taktgeberbaumpfade mit festen Latenzen;
      • für einen gegebenen Slave-Knoten, Feststellen der festen Latenz des Taktgeberbaumpfads von dem neuen Master-Taktgeber-Knoten zu dem Slave-Knoten; und
      • Synchronisieren eines lokalen Taktgebers für den Slave-Knoten und den Master-Taktgeber an dem neuen Master-Taktgeber-Knoten unter Verwendung der Master-Taktgeberzeitdaten, die von dem Slave-Knoten erhalten werden, und der festen Latenz des Taktgeberbaumpfads von dem Master-Taktgeber-Knoten zu dem Slave-Knoten, die festgestellt wird,
    15. 15. Das Verfahren nach einem der vorstehenden Abschnitte, ferner das Implementieren des Master-Taktgebers in einem Fabric-Schalter umfassend.
    16. 16. Ein Fabric-Schalter, umfassend:
      • Eine Vielzahl von Ports, von denen jeder einen Empfangsport enthält, der operativ mit einem Empfangspuffer gekoppelt ist, und einen Sendeport, der operativ mit einem Sendepuffer gekoppelt ist, mindestens einen Port, der einen vorgeschalteten Taktgeberport umfasst, und mindestens einen Port, der einen nachgeschalteten Taktgeberport umfasst;
      • eine Schaltungsanordnung, die während des Betriebs auswählbare Verbindung zwischen einem Empfangspuffer eines ersten Ports und einem Sendepuffer eines zweiten Ports befähigt;
      • mindestens einen Bypassschaltungspfad zwischen einem Empfangsport eines vorgeschalteten Taktgeberports und einem Sendeport eines nachgeschalteten Taktgeberports, der ermöglicht, dass Master-Taktgeberzeitdaten, die an dem Empfangsport des vorgeschalteten Taktgeberports empfangen werden, an den Sendeport des nachgeschalteten Taktgeberports auf eine Weise weitergeleitet werden, dass der Empfangspuffer für den Empfangsport und der Sendepuffer für den Sendeport umgangen werden.
    17. 17. Der Fabric-Schalter nach Abschnitt 16, wobei der mindestens eine Schaltungspfad mindestens einen Ringbus mit einer Vielzahl von Ring-Knoten-Stopps, einschließlich von jeweiligen Ring-Knoten-Stopps, die operativ mit jedem des mindestens einen vorgeschalteten Taktgeberports und jedem des mindestens einen nachgeschalteten Taktgeberports gekoppelt sind, umfasst.
    18. 18. Der Fabric-Schalter nach Abschnitt 17, wobei der Fabric-Schalter konfiguriert ist, in einem Fabric implementiert zu werden, das Daten entlang Fabric-Links in einem Strom von Flusskontrolleinheiten (Flow Control Units; Flits), der Flit-Ströme umfasst, überträgt, und der Fabric-Schalter ferner konfiguriert ist:
      • einen Flit-Strom an einem vorgeschalteten Taktgeberport zu empfangen;
      • einen Zeit-Kontroll-Flit in dem Flit-Strom zu erfassen;
      • Master-Taktgeber-Zeitdaten aus dem Zeit-Kontroll-Flit zu extrahieren;
      • die Master-Taktgeberzeitdaten entlang eines ersten Ringbusses weiterzuleiten; und
      • an jedem von mehreren Ring-Stopp-Knoten auf der ersten Verbindung:
      • eine Kopie der Master-Taktgeberzeitdaten in einem neuen Zeit-Kontroll-Flit zu verkapseln; und
      • den neuen Zeit-Kontroll-Flit in einen Flit-Strom zu injizieren, der auf einen Fabric-Link von dem nachgeschalteten Taktgeberport, mit dem der Ring-Stopp-Knoten verbunden ist, ausgesendet wird.
    19. 19. Der Fabric-Schalter nach Abschnitt 17 oder 18, wobei der Fabric-Schalter konfiguriert ist, in einem Fabric implementiert zu werden, das Daten entlang Fabric-Links in einem Strom von Flusskontrolleinheiten (Flow Control Units; Flits), der Flit-Ströme umfasst, überträgt, und der Fabric-Schalter ferner konfiguriert ist:
      • einen Flit-Strom an einem vorgeschalteten Taktgeberport zu empfangen;
      • einen Zeit-Kontroll-Flit in dem Flit-Strom zu erfassen;
      • den Zeit-Kontroll-Flit entlang eines ersten Ringbusses weiterzuleiten; und
      • an jedem der mehreren Ring-Stopp-Knoten auf der ersten Verbindung:
      • eine Kopie des Zeit-Kontroll-Flit in einen Flit-Strom zu injizieren, der auf einen Fabric-Link von dem dem nachgeschalteten Taktgeberport, mit dem der Ring-Stopp-Knoten gekoppelt ist, ausgesendet wird.
    20. 20. Der Fabric-Schalter nach einem der Abschnitte 17-19, wobei der Fabric-Schalter konfiguriert ist, in einem Fabric implementiert zu werden, das Daten entlang von Fabric-Links in einem Strom von Flusskontrolleinheiten (Flow Control Units; Flits), der Flit-Ströme umfasst, überträgt, wobei die Master-Taktgeberzeitdaten in ersten und zweiten Flits enthalten sind, wobei das erste Flit einen oberen Bitabschnitt der Master-Taktgeberdaten umfasst und das zweite Flit einen unteren Bitabschnitt der Master-Taktgeberzeitdaten enthält.
    21. 21. Der Fabric-Schalter nach Abschnitt 20, wobei jeder vorgeschaltete Taktgeberport konfiguriert ist, Fehler in dem Flit-Strom zu erfassen und der Fabric-Schalter konfiguriert ist, fehlgeleitete Zeit-Kontroll-Flits daran zu hindern, von einem vorgeschalteten Taktgeberport an einen nachgeschalteten Taktgeberport weitergeleitet zu werden.
    22. 22. Der Fabric-Schalter nach einem der Abschnitte 16-21, wobei der mindestens eine Schaltungspfad erste und zweite Ringbusse umfasst, von denen jeder eine Vielzahl von Ring-Knoten-Stopps, einschließlich von jeweiligen Ring-Knoten-Stopps, die operativ mit jedem des mindestens einen vorgeschalteten Taktgeberports und jedem des mindestens einen nachgeschalteten Taktgeberports gekoppelt sind, wobei Daten entlang des ersten Ringbusses im Uhrzeigersinn weitergeleitet werden und Daten entlang eines zweiten Ringbusses gegen den Uhrzeigersinn weitergeleitet werden.
    23. 23. Der Fabric-Schalter nach einem der Abschnitte 16-22, wobei jeder der Vielzahl von Ports selektiv konfigurierbar ist, um, einer nach dem anderen, als ein vorgeschalteter Taktgeberport und ein nachgeschalteter Taktgeberport zu arbeiten.
    24. 24. Der Fabric-Schalter nach einem der Abschnitte 16-23, ferner eine Schaltungsanordnung zum Implementieren eines Master-Taktgebers umfassend.
    25. 25. Der Fabric-Schalter nach einem der Abschnitte 16-24, ferner eine Schaltungsanordnung für das Implementieren eines lokalen Taktgebers und das Synchronisieren des lokalen Taktgebers mit einem Master-Taktgeber umfassend.
    26. 26. Der Fabric-Schalter nach einem der Abschnitte 16-24, wobei der Fabric-Schalter konfiguriert ist, in einem Fabric implementiert zu werden, das Daten entlang Fabric-Links in einem Strom von Flusskontrolleinheiten (Flow Control Units; Flits), der Flit-Ströme umfasst, überträgt, wobei der Fabric-Schalter ferner umfasst:
      • Zeit-Kontroll-Flit-Extraktionslogik an jedem des mindestens einen vorgeschalteten Taktgeberports, die konfiguriert ist, Zeit-Kontroll-Flits, die aus einem Flit-Strom empfangen werden, die Master-Taktgeberzeitdaten umfassen, zu extrahieren, und Master-Zeitdaten, die in einem extrahierten Zeit-Kontroll-Flit enthalten sind, entlang eines Bypassschaltungspfads zwischen dem vorgeschalteten Taktgeberport und mindestens einem nachgeschalteten Taktgeberport weiterzuleiten.
    27. 27. Der Fabric-Schalter nach Abschnitt 26, ferner umfassend:
      • Zeit-Kontroll-Flit-Injektionslogik an jedem des mindestens einen nachgeschalteten Taktgeberports, die konfiguriert ist, Master-Zeitdaten, die von einem vorgeschalteten Taktgeberport entlang des Bypassschaltungspfads weitergeleitet werden, zu empfangen, einen neuen Zeit-Kontroll-Flit zu generieren und den neuen Zeit-Kontroll-Flit in einen Flit-Strom, der auf einen Fabric-Link von dem nachgeschalteten Taktgeberport ausgesendet wird, zu injizieren.
    28. 28. Der Fabric-Schalter nach einem der Abschnitte 16-24, wobei der Fabric-Schalter konfiguriert ist, in einem Fabric implementiert zu werden, das Daten entlang Fabric-Links in einem Strom von Flusskontrolleinheiten (Flow Control Units; Flits), der Flit-Ströme umfasst, überträgt, wobei der Fabric-Schalter ferner umfasst:
      • Zeit-Kontroll-Flit-Extraktionslogik an jedem des mindestens einen vorgeschalteten Taktgeberports, die konfiguriert ist, Zeit-Kontroll-Flits, die aus einem Flit-Strom empfangen werden, die Master-Taktgeberzeitdaten umfassen, zu extrahieren, und einen extrahierten Zeit-Kontroll-Flit entlang eines Bypassschaltungspfads zwischen dem vorgeschalteten Taktgeberport und mindestens einem nachgeschalteten Taktgeberport weiterzuleiten.
    29. 29. Der Fabric-Schalter nach Abschnitt 28, ferner umfassend:
      • Zeit-Kontroll-Flit-Injektionslogik an jedem des mindestens einen nachgeschalteten Taktgeberports, die konfiguriert ist, ein Zeit-Kontroll-Flit, das von einem vorgeschalteten Taktgeberport entlang des Bypassschaltungspfads weitergeleitet wird, zu empfangen, und den Zeit-Kontroll-Flit in einen Flit-Strom, der auf einen Fabric-Link von dem nachgeschalteten Taktgeberport ausgesendet wird, zu injizieren.
    30. 30. Ein System, umfassend:
      • Einen Master-Taktgeber-Knoten mit einem Master-Taktgeber und einschließlich einer Host-Fabric-Schnittstelle (Host Fabric Interface; HFI);
      • eine Vielzahl von Slave-Knoten, von denen jeder einen lokalen Taktgeber enthält und eine HFI enthält;
      • eine Vielzahl von Fabric-Schaltern, von denen jeder enthält:
      • eine Vielzahl von Ports, von denen jeder einen Empfangsport enthält, der operativ mit einem Empfangspuffer gekoppelt ist, und einen Sendeport, der operativ mit einem Sendepuffer gekoppelt ist, mindestens einen Port, der einen vorgeschalteten Taktgeberport umfasst, und mindestens einen Port, der einen nachgeschalteten Taktgeberport umfasst;
      • Schaltungsanordnung, die, während des Betriebs, auswählbare Verbindung zwischen Paaren von Empfangspuffern und Sendepuffern verschiedener Ports befähigt;
      • mindestens ein Bypassschaltungspfad zwischen dem mindestens einen vorgeschalteten Taktgeberport und dem mindestens einen nachgeschalteten Taktgeberport; und
      • eine Vielzahl von Fabric-Links, die Ports an der Vielzahl von Fabric-Schaltern, dem Master-Taktgeber-Knoten und der Vielzahl der Slave-Knoten untereinander verbinden,
      • wobei während des Betriebs des Systems der Master-Taktgeber-Knoten Master-Taktgeberzeitdaten generiert, die an jeden der Slave-Knoten über einen Taktgeberbaumpfad mit einer festen Latenz weitergeleitet werden, wobei jeder Taktgeberbaumpfad den Bypassschaltungspfad für mindestens einen Fabric-Schalter und eine Vielzahl von Fabric-Links quert.
    31. 31. Das System nach Abschnitt 30, wobei jeder Fabric-Schalter konfiguriert ist, Master-Taktgeberzeitdaten entlang dem mindestens einen Bypassschaltungspfad auf eine Weise weiterzuleiten, die die Empfangspuffer, die Sendepuffer und die Schaltungsanordnung umgeht.
    32. 32. Das System nach Abschnitt 31, wobei das System Operationen zum Ermöglichen von Synchronisation der lokalen Taktgeber an den Slave-Knoten mit dem Master-Taktgeber durchführt, umfassend:
      • Weiterleiten von Master-Taktgeberzeitdaten, die von dem Master-Taktgeber generiert werden, an jeden der Vielzahl von Slave-Knoten über einen jeweiligen Taktgeberbaumpfad mit einer festen Latenz;
      • für jeden Slave-Knoten, Feststellen der festen Latenz des Taktgeberbaumpfads von dem Master-Taktgeber-Knoten zu dem Slave-Knoten; und
      • Synchronisieren eines lokalen Taktgebers für den Slave-Knoten und den Master-Taktgeber, der an dem Master-Taktgeber-Knoten arbeitet, unter Verwendung der Master-Taktgeberzeitdaten, die von dem Slave-Knoten erhalten werden, und der festen Latenz des Taktgeberbaumpfads von dem Master-Taktgeber-Knoten zu dem Slave-Knoten, die festgestellt wird,
    33. 33. Das System nach Abschnitt 32, wobei das System ferner konfiguriert ist:
      • eine Taktgeberratenfehlanpassung des lokalen Taktgebers an jedem Slave-Knoten relativ zu dem Master-Taktgeber zu erfassen; und
      • die Taktgeberratenfehlanpassung, die für jeden lokalen Taktgeber festgestellt wurde, einzusetzen, um die Synchronisierung zwischen dem Master-Taktgeber und jedem lokalen Taktgeber aufrechtzuerhalten.
    34. 34. Das System nach einem der Abschnitte 30-33, wobei das System ferner konfiguriert ist, Datenintegrität der Master-Taktgeberzeitdaten, die an jeden Slave-Knoten weitergeleitet werden, zu garantieren.
  • Obwohl manche Ausführungsformen unter Bezugnahme auf bestimmte Implementierungen beschrieben wurden, sind gemäß manchen Ausführungsformen auch andere Implementierungen möglich. Zusätzlich müssen die Anordnung und/oder Reihenfolge von Elementen oder anderen Merkmalen, die in den Zeichnungen veranschaulicht und/oder hierin beschrieben sind, nicht auf die bestimmte veranschaulichte und beschriebene Weise angeordnet sein. Gemäß manchen Ausführungsformen sind viele andere Anordnungen möglich.
  • In jedem in einer Figur gezeigten System können die Elemente in manchen Fällen jeweils das gleiche Bezugszeichen oder ein unterschiedliches Bezugszeichen haben, was darauf hindeutet, dass die repräsentierten Elemente unterschiedlich und/oder ähnlich sein könnten. Ein Element kann jedoch flexibel genug sein, um unterschiedliche Implementierungen zu haben und mit manchen oder allen der hierin gezeigten oder beschriebenen Systeme zu arbeiten. Die in den Figuren gezeigten verschiedenen Elemente können die gleichen sein oder sich unterscheiden. Die Bezugnahme auf ein erstes Element und ein zweites Element ist zufällig.
  • In der Beschreibung und den Ansprüchen können die Begriffe „gekoppelt“ und „verbunden“ sowie deren Ableitungen verwendet werden. Es versteht sich, dass diese Begriffe nicht als Synonyme füreinander beabsichtigt sind. Vielmehr kann in bestimmten Ausführungsformen „verbunden“ verwendet werden, um anzugeben, dass zwei oder mehr Elemente in direktem physischen oder elektrischen Kontakt miteinander stehen. „Gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem physischen oder elektrischen Kontakt stehen. „Gekoppelt“ kann jedoch auch bedeuten, dass zwei oder mehr Elemente nicht in direktem Kontakt miteinander stehen, aber dennoch immer noch miteinander kooperieren oder interagieren.
  • Eine Ausführungsform ist eine Implementierung oder ein Beispiel der Erfindungen. Bezugnahmen in der Spezifikation auf „eine Ausführungsform“, „manche Ausführungsformen“ oder „andere Ausführungsformen“ bedeuten, dass ein/e bestimmte/s Merkmal, Struktur oder Eigenschaft, das/die in Verbindung mit den Ausführungsformen beschrieben wird, in mindestens manchen Ausführungsformen, aber nicht zwangsläufig allen Ausführungsformen der Erfindungen enthalten ist. Die verschiedenen Erscheinungsformen von „eine Ausführungsform“ oder „manche Ausführungsformen“ beziehen sich nicht alle zwangsläufig auf die gleichen Ausführungsformen.
  • Nicht alle Komponenten, Merkmale, Strukturen, Eigenschaften usw., die hierin beschrieben und veranschaulicht sind, müssen in einer bestimmten Ausführungsform oder in Ausführungsformen enthalten sein. Falls die Spezifikation angibt, dass eine Komponente, ein Merkmal, eine Struktur oder Eigenschaft zum Beispiel enthalten sein „kann“ oder „könnte“, muss diese/s bestimmte Komponente, Merkmal, Struktur oder Eigenschaft nicht enthalten sein. Falls die Spezifikation oder der Anspruch auf „ein“ Element Bezug nimmt, bedeutet dies nicht, dass es nur ein Element gibt. Falls die Spezifikation oder die Ansprüche auf „ein zusätzliches“ Element Bezug nimmt bzw. nehmen, schließt dies nicht aus, dass es mehr als eines der zusätzlichen Elemente gibt.
  • Ein Algorithmus gilt hier und generell als eine selbstkonsistente Sequenz von Akten oder Operationen, die zu einem gewünschten Resultat führen. Dies beinhaltet physikalische Manipulationen physikalischer Quantitäten. Üblicherweise, aber nicht zwangsläufig, nehmen diese Quantitäten die Form elektrischer oder magnetischer Signale an, die dazu fähig sind, gespeichert, übertragen, kombiniert, verglichen und anderweitig manipuliert zu werden. Es hat sich bisweilen als praktisch erweisen, vor allem aus Gründen der üblichen Verwendung, sich auf diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Terme, Zahlen oder dergleichen zu beziehen. Es versteht sich jedoch, dass alle diese und ähnliche Begriffe mit den angemessenen physikalischen Quantitäten zu assoziieren sind und lediglich praktische Bezeichnungen sind, die auf diese Quantitäten angewendet werden.
  • Wie vorstehend diskutiert, können verschiedene Aspekte der Ausführungsformen hierin durch entsprechende Software- und/oder Firmwarekomponenten und -anwendungen ermöglicht werden, wie etwa Software und/oder Firmware, die von einem eingebetteten Prozessor oder dergleichen ausgeführt wird. Ausführungsformen dieser Erfindungen können somit als ein Softwareprogramm, Softwaremodule, Firmware und/oder verteilte Software, die von einer gewissen Form von Prozessor, Prozessorkern oder eingebetteter Logik einer virtuellen Maschine, die auf einem Prozessor oder Kern ausgeführt wird, oder anderweitig auf oder innerhalb eines computerlesbaren oder maschinenlesbaren nicht transitorischen Speichermediums implementiert oder realisiert ist, verwendet werden oder diese unterstützen. Ein computerlesbares oder maschinenlesbares nicht transitorisches Speichermedium beinhaltet jedweden Mechanismus zum Speichern oder Übertragen von Informationen in einer Form, die von einer Maschine (z. B. einem Computer) lesbar ist. Ein computerlesbares oder maschinenlesbares nicht transitorisches Speichermedium beinhaltet zum Beispiel jedweden Mechanismus, der Informationen in einer Form bereitstellt (d. h. speichert und/oder überträgt), die einem Computer oder einer Rechenmaschine (z. B. Rechenvorrichtung, Elektroniksystem usw.) zugänglich ist, wie etwa beschreibbare/nichtbeschreibbare Medien (z. B. Nur-Lese-Speicher (ROM), Direktzugriffsspeicher (RAM), Magnetplattenspeichermedien, optische Speichermedien, Flash-Speichervorrichtungen usw.). Der Inhalt kann direkt ausführbar („Objekt-“ oder „ausführbare“ Form), Quellcode oder Differenzcode („Delta“ oder „Patch“ Code) sein. Ein computerlesbares oder maschinenlesbares nicht transitorisches Speichermedium kann auch einen Speicher oder jede Datenbank beinhalten, von der Inhalt heruntergeladen werden kann. Das computerlesbare oder maschinenlesbare nicht transitorische Speichermedium kann auch eine Vorrichtung oder ein Produkt beinhalten, auf dem zum Zeitpunk des Verkaufs oder der Lieferung Inhalt gespeichert ist. Die Lieferung einer Vorrichtung mit gespeichertem Inhalt oder das Angebot von Inhalt zum Herunterladen über ein Kommunikationsmedium kann daher als das Bereitstellen eines Herstellungsartikels, der ein computerlesbares oder maschinenlesbares nicht transitorisches Speichermedium mit solchem, hierin beschriebenen Inhalt verstanden werden.
  • Verschiedene Komponenten, auf die vorstehend als Prozesse, Server oder Werkzeuge Bezug genommen wird, und die hierin beschrieben werden, können Mittel zum Durchführen der beschriebenen Funktionen sein. Die von verschiedenen, hierin beschriebenen Komponenten durchgeführten Operationen und Funktionen können von Software implementiert werden, die auf einem Verarbeitungselement, über eingebettete Hardware oder dergleichen, oder eine beliebige Kombination von Hardware und Software ausgeführt wird. Solche Komponenten können als Softwaremodule, Hardwaremodule, Spezialsoftware (z. B. anwendungsspezifische Hardware, ASICs, DSPs usw.), eingebettete Steuereinrichtungen, fest verdrahtete Schaltungsanordnungen, Hardwarelogik usw. implementiert sein. Softwareinhalt (z. B. Daten, Anweisungen, Konfigurationsinformationen usw.) können über einen Herstellungsartikel bereitgestellt werden, einschließlich computerlesbarer oder maschinenlesbarer nicht transitorischer Speichermedien, die Inhalt bereitstellen, der Anweisungen repräsentiert, die ausgeführt werden können. Der Inhalt kann darin resultieren, dass ein Computer verschiedene hierin beschriebene Funktionen/Operationen ausführt.
  • Wie hierin verwendet, kann eine Liste von Objekten, die durch den Begriff „mindestens eine/s von“ zusammengeführt werden, eine Kombination der aufgeführten Begriffe bedeuten. Die Formulierung „mindestens eines von A, B oder C“ kann zum Beispiel A; B; C; A und B; A und C; B und C; oder A, B und C bedeuten.
  • Es ist nicht beabsichtigt, dass die vorstehende Beschreibung veranschaulichter Ausführungsformen der Erfindung, einschließlich dessen, was in der Zusammenfassung beschrieben ist, erschöpfend ist oder die Erfindung auf die präzisen offenbarten Formen beschränkt. Obwohl zu veranschaulichenden Zwecken konkrete Ausführungsformen und Beispiele der Erfindung beschrieben werden, sind im Umfang der Erfindung verschiedene äquivalente Modifikationen möglich, wie der Fachmann erkennen wird.
  • Diese Modifikationen können angesichts der vorstehenden ausführlichen Beschreibung an der Erfindung vorgenommen werden. Die in den nachfolgenden Ansprüchen verwendeten Begriffe dürfen nicht derart ausgelegt werden, dass sie die Erfindung auf die spezifischen Ausführungsformen, die in der Spezifikation und den Zeichnungen offenbart werden, beschränken. Vielmehr wird der Umfang der Erfindung in seiner Gesamtheit durch die folgenden Ansprüche bestimmt, die in Übereinstimmung mit anerkannten Lehren der Anspruchsauslegung auszulegen sind.

Claims (25)

  1. Verfahren durchgeführt in einer Umgebung, einschließlich eines Master-Taktgeber-Knotens, der kommunikativ mit einer Vielzahl von Slave-Knoten über ein Fabric, das eine Vielzahl von Fabric-Schaltern und eine Vielzahl von Fabric-Links umfasst, gekoppelt ist, umfassend: Weiterleiten von Master-Taktgeberzeitdaten, die von einem Master-Taktgeber, der an dem Master-Taktgeber-Knoten arbeitet, generiert werden, an jeden der Vielzahl von Slave-Knoten über Taktgeberbaumpfade mit festen Latenzen; für einen gegebenen Slave-Knoten, Feststellen der festen Latenz des Taktgeberbaumpfads von dem Master-Taktgeber-Knoten zu dem Slave-Knoten; und Synchronisieren eines lokalen Taktgebers für den Slave-Knoten und den Master-Taktgeber, der an dem Master-Taktgeber-Knoten arbeitet, unter Verwendung der Master-Taktgeberzeitdaten, die von dem Slave-Knoten erhalten werden, und der festen Latenz des Taktgeberbaumpfads von dem Master-Taktgeber-Knoten zu dem Slave-Knoten, die festgestellt wird, wobei, zumindest für einen Teil der Slave-Knoten, die Taktgeberbaumpfade von dem Master-Taktgeber-Knoten zu jenen Slave-Knoten mehrere Fabric-Schalter queren.
  2. Verfahren nach Anspruch 1, wobei jeder der mehreren Fabric-Schalter, die für einen gegebenen Weiterleitungspfad zwischen dem Master-Taktgeber-Knoten und einem Slave-Knoten gequert werden, umfasst: eine Vielzahl von Ports, von denen jeder einen Empfangsport enthält, der operativ mit einem Empfangspuffer gekoppelt ist, und einen Sendeport, der operativ mit einem Sendepuffer verbunden ist; Schaltungsanordnung, die, während des Betriebs, auswählbare Verbindung zwischen einem Empfangspuffer eines ersten Ports und einem Sendepuffer eines zweiten Ports befähigt; mindestens einen Bypassschaltungspfad zwischen einem Empfangsport eines vorgeschalteten Taktgeberports und einem Sendeport eines nachgeschalteten Taktgeberports, der ein Empfangen von Daten an dem Empfangsport zum Weiterleiten an den Sendeport entlang eines Bypassschaltpfads befähigt.
  3. Verfahren nach Anspruch 2, wobei der mindestens eine Schaltungspfad einen Ringbus umfasst, mit dem zumindest ein Teil der Empfangsports und Sendeports operativ gekoppelt sind.
  4. Verfahren nach Anspruch 2 oder 3, wobei der mindestens eine Schaltungspfad erste und zweite Ringbusse umfasst, mit denen mindestens ein Teil der Empfangsports und Sendeports operativ gekoppelt sind, wobei Daten für den ersten Ringbus im Uhrzeigersinn weitergeleitet werden und Daten für den zweiten Ringbus gegen den Uhrzeigersinn weitergeleitet werden, und wobei die Daten auf Basis dessen, welcher Ringbus in der geringsten Latenz resultiert, entlang dem ersten oder dem zweiten Ringbus weitergeleitet werden.
  5. Verfahren nach einem der vorstehenden Ansprüche, wobei ein Taktgeberbaumpfad zwischen einem Master-Taktgeber-Knoten und einem Slave-Knoten eine Vielzahl von Fabric-Schaltern und eine Vielzahl von Linksegmenten, die die Vielzahl von Fabric-Schaltern in Kommunikation verbinden, queren, und wobei das Feststellen der festen Latenz eines Taktgeberbaumpfads umfasst: Feststellen einer Latenz für jedes der Vielzahl von Linksegmenten; Feststellen einer Schalterweiterleitungslatenz von einem vorgeschalteten Taktgeberport zu einem nachgeschalteten Taktgeberport innerhalb von jedem der Vielzahl von Fabric-Schaltern, wobei der Taktgeberbaumpfad ein erstes Linksegment enthält, das mit dem vorgeschalteten Taktgeberport gekoppelt ist, und ein zweites Linksegment, das mit dem nachgeschalteten Taktgeberport verbunden ist; und Aggregieren der Latenzen für jedes der Vielzahl von Linksegmenten und der Schalterweiterleitungslatenzen.
  6. Verfahren nach einem der vorstehenden Ansprüche, wobei Daten über die Vielzahl von Fabric-Links unter Verwendung eines Stroms von Flusskontrolleinheiten (Flow Control Units, Flits) übertragen werden, und wobei die Master-Taktgeberzeitdaten innerhalb mindestens einer Flit enthalten sind, die entlang den Taktgeberbaumpfaden von dem Master-Taktgeber-Knoten zu der Vielzahl von Slave-Knoten weitergeleitet wird.
  7. Verfahren nach Anspruch 6, wobei die Master-Taktgeberzeitdaten in einer ersten und einer zweiten Flit enthalten sind, wobei die erste Flit einen oberen Bit-Abschnitt der Master-Taktgeberzeitdaten umfasst und die zweite Flit einen unteren Bit-Abschnitt der Master-Taktgeberzeitdaten enthält.
  8. Verfahren nach Anspruch 7, wobei ein Abschnitt des oberen Bit-Abschnitts der Master-Taktgeberzeitdaten in der ersten Flit und der untere Bit-Abschnitt der Master-Taktgeberzeitdaten in der zweiten Flit sich überschneiden, ferner umfassend das Vergleichen der Master-Taktgeberzeitdatenbits in dem sich überschneidenden Abschnitt, um festzustellen, dass sich der obere Bit-Abschnitt und der untere Bit-Abschnitt der Master-Taktgeberzeitdaten entsprechen.
  9. Verfahren nach Anspruch 6, ferner umfassend: Empfangen eines Flit-Stroms, umfassend einen Strom von Flits, an einem Empfangsport eines vorgeschalteten Taktgeberports eines Fabric-Schalters, wobei der Empfangsport über einen zugeordneten Empfangspuffer verfügt; Erkennen, dass eine erste Vielzahl von Flits in dem Flit-Strom Daten enthält, die Fabric-Paketen entsprechen; Speichern der ersten Vielzahl von Flits in einem Empfangspuffer für den Empfangsport; Erkennen, dass eine Flit in dem Flit-Strom einer Zeit-Kontroll-Flit entspricht, die Master-Taktgeberzeitdaten enthält; Extrahieren der Master-Taktgeberzeitdaten aus der Zeit-Kontroll-Flit; Weiterleiten der Master-Taktgeberzeitdaten von dem Empfangsport an einen nachgeschalteten Taktgeberport in dem Fabric-Schalter entlang eines Bypassschaltungspfads; Verkapseln der Master-Taktgeberzeitdaten in eine neue Zeit-Kontroll-Flit, die an einem Sendeport des nachgeschalteten Taktgeberports generiert wird; und Injizieren der neuen Zeit-Kontroll-Flit in einen Flit-Strom, der auf einem Fabric-Link von dem Sendeport ausgesendet wird.
  10. Verfahren nach Anspruch 6, ferner umfassend: Empfangen eines Flit-Stroms, umfassend einen Strom von Flits, an einem Empfangsport eines vorgeschalteten Taktgeberports eines Fabric-Schalters, wobei der Empfangsport über einen zugeordneten Empfangspuffer verfügt; Erkennen, dass eine Flit in dem Flit-Strom einer Zeit-Kontroll-Flit entspricht, die Master-Taktgeberzeitdaten enthält; Weiterleiten der Zeit-Kontroll-Flit von dem Empfangsport an einen nachgeschalteten Taktgeberport in dem Fabric-Schalter ohne Puffern der Zeit-Kontroll-Flit in dem Empfangspuffer, der dem Empfangsport zugeordnet ist; und Injizieren der Zeit-Kontroll-Flit in einen Flit-Strom, der auf einem Fabric-Link von einem Sendeport des nachgeschalteten Taktgeberports ausgesendet wird.
  11. Verfahren nach Anspruch 6, wobei, für jeden Slave-Knoten, die mindestens eine Flit, die die Master-Taktgeberzeitdaten enthält, entlang eines Taktgeberbaumpfads von dem Master-Taktgeber-Knoten an den Slave-Knoten auf eine Weise weitergeleitet wird, die Datenintegrität der Master-Taktgeberzeitdaten, die an den Slave-Knoten weitergeleitet werden, garantiert.
  12. Verfahren nach einem der vorstehenden Ansprüche, ferner das Festellen einer Taktgeberratenfehlanpassung zwischen dem Master-Taktgeber und einem lokalen Taktgeber auf einem Slave-Knoten umfassend.
  13. Verfahren nach Anspruch 12, wobei das Feststellen der Taktgeberratenfehlanpassung zwischen dem Master-Taktgeber und dem lokalen Taktgeber umfasst: Empfangen erster Master-Taktgeberzeitdaten an dem Slave-Knoten; Speichern einer ersten Master-Taktgeberzeitprobe, die den ersten Master-Taktgeberzeitdaten an dem Slave-Knoten entspricht; zusammen mit dem Empfangen der ersten Master-Taktgeberzeitdaten, Speichern einer ersten Probe des lokalen Taktgebers an dem Slave-Knoten; Empfangen zweiter Master-Taktgeberzeitdaten an dem Slave-Knoten; Speichern der zweiten Master-Taktgeberzeitdaten an dem Slave-Knoten; zusammen mit dem Empfangen der zweiten Master-Taktgeberzeitdaten, Speichern einer zweiten Probe des lokalen Taktgebers an dem Slave-Knoten; Subtrahieren der ersten Master-Taktgeberzeitdaten von den zweiten Master-Taktgeberzeitdaten, um eine Master-Taktgeberzeitprobendifferenz zu erhalten; Subtrahieren der ersten Probe von der zweiten Probe des lokalen Taktgebers, um eine Zeitdifferenz für die lokale Taktgeberzeitprobendifferenz zu erhalten; und Subtrahieren der lokalen Taktgeberzeitprobendifferenz von der Master-Taktgeberzeitprobendifferenz und Dividieren des Resultats durch die lokale Taktgeberzeitprobendifferenz, um die Taktgeberratenfehlanpassung zu erhalten.
  14. Verfahren nach einem der vorstehenden Ansprüche, ferner umfassend: Ersetzen eines Master-Taktgeber-Knotens durch einen neuen Master-Taktgeber-Knoten; und Weiterleiten von Master-Taktgeberzeitdaten, die von einem Master-Taktgeber, der an dem neuen Master-Taktgeber-Knoten arbeitet, generiert werden, an jeden der Vielzahl von Slave-Knoten über Taktgeberbaumpfade mit festen Latenzen; für einen gegebenen Slave-Knoten, Feststellen der festen Latenz des Taktgeberbaumpfads von dem neuen Master-Taktgeber-Knoten zu dem Slave-Knoten; und Synchronisieren eines lokalen Taktgebers für den Slave-Knoten und den Master-Taktgeber an dem neuen Master-Taktgeber-Knoten unter Verwendung der Master-Taktgeberzeitdaten, die von dem Slave-Knoten erhalten werden, und der festen Latenz des Taktgeberbaumpfads von dem Master-Taktgeber-Knoten zu dem Slave-Knoten, die festgestellt wird,
  15. Fabric-Schalter, umfassend: eine Vielzahl von Ports, von denen jeder einen Empfangsport enthält, der operativ mit einem Empfangspuffer gekoppelt ist, und einen Sendeport, der operativ mit einem Sendepuffer gekoppelt ist, mindestens einen Port, der einen vorgeschalteten Taktgeberport umfasst, und mindestens einen Port, der einen nachgeschalteten Taktgeberport umfasst; Schaltungsanordnung, die, während des Betriebs, auswählbare Verbindung zwischen einem Empfangspuffer eines ersten Ports und einem Sendepuffer eines zweiten Ports befähigt; mindestens einen Bypassschaltungspfad zwischen einem Empfangsport eines vorgeschalteten Taktgeberports und einem Sendeport eines nachgeschalteten Taktgeberports, der ermöglicht, dass Master-Taktgeberzeitdaten, die an dem Empfangsport des vorgeschalteten Taktgeberports empfangen werden, an den Sendeport des nachgeschalteten Taktgeberports auf eine Weise weiterzuleiten sind, dass der Empfangspuffer für den Empfangsport und der Sendepuffer für den Sendeport umgangen werden.
  16. Fabric-Schalter nach Anspruch 15, wobei der mindestens eine Schaltungspfad mindestens einen Ringbus mit einer Vielzahl von Ring-Knoten-Stopps, einschließlich jeweiliger Ring-Knoten-Stopps, die operativ mit jedem des mindestens einen vorgeschalteten Taktgeberports und jedem des mindestens einen nachgeschalteten Taktgeberports gekoppelt sind, umfasst.
  17. Fabric-Schalter nach Anspruch 16, wobei der Fabric-Schalter konfiguriert ist, in einem Fabric implementiert zu werden, das Daten entlang Fabric-Links in einem Strom von Flusskontrolleinheiten (Flow Control Units; Flits), der Flit-Ströme umfasst, überträgt, und der Fabric-Schalter ferner konfiguriert ist: einen Flit-Strom an einem vorgeschalteten Taktgeberport zu empfangen; eine Zeit-Kontroll-Flit in dem Flit-Strom zu erfassen; Master-Taktgeberzeitdaten aus der Zeit-Kontroll-Flit zu extrahieren; die Master-Taktgeberzeitdaten entlang eines ersten Ringbusses weiterzuleiten; und an jedem Ring-Stopp-Knoten auf der ersten Verbindung: eine Kopie der Master-Taktgeberzeitdaten in einer neuen Zeit-Kontroll-Flit zu verkapseln; und die neue Zeit-Kontroll-Flit in einen Flit-Strom zu injizieren, der auf einem Fabric-Link von dem nachgeschalteten Taktgeberport, mit dem der Ring-Stopp-Knoten verbunden ist, ausgesendet wird.
  18. Fabric-Schalter nach Anspruch 16 oder 17, wobei der Fabric-Schalter konfiguriert ist, in einem Fabric implementiert zu werden, das Daten entlang Fabric-Links in einem Strom von Flusskontrolleinheiten (Flow Control Units; Flits), der Flit-Ströme umfasst, überträgt, und der Fabric-Schalter ferner konfiguriert ist: einen Flit-Strom an einem vorgeschalteten Taktgeberport zu empfangen; eine Zeit-Kontroll-Flit in dem Flit-Strom zu erfassen; die Zeit-Kontroll-Flit entlang eines ersten Ringbusses weiterzuleiten; und an jedem einer Vielzahl von Ring-Stopp-Knoten auf der ersten Verbindung: eine Kopie der Zeit-Kontroll-Flit in einen Flit-Strom zu injizieren, der auf einem Fabric-Link von dem nachgeschalteten Taktgeberport, mit dem der Ring-Stopp-Knoten gekoppelt ist, ausgesendet wird.
  19. Fabric-Schalter nach einem der Ansprüche 15-18, wobei der mindestens eine Schaltungspfad einen ersten und einen zweiten Ringbus umfasst, von denen jeder eine Vielzahl von Ring-Knoten-Stopps, einschließlich jeweiliger Ring-Knoten-Stopps, die operativ mit jedem des mindestens einen vorgeschalteten Taktgeberports und jedem des mindestens einen nachgeschalteten Taktgeberports gekoppelt sind, umfasst, wobei Daten entlang des ersten Ringbusses im Uhrzeigersinn weitergeleitet werden und Daten entlang eines zweiten Ringbusses gegen den Uhrzeigersinn weitergeleitet werden.
  20. Fabric-Schalter nach einem der Ansprüche 15-19, wobei der Fabric-Schalter konfiguriert ist, in einem Fabric implementiert zu werden, das Daten entlang Fabric-Links in einem Strom von Flusskontrolleinheiten (Flow Control Units; Flits), der Flit-Ströme umfasst, überträgt, wobei der Fabric-Schalter ferner umfasst: Zeit-Kontroll-Flit-Extraktionslogik an jedem des mindestens einen vorgeschalteten Taktgeberports, die konfiguriert ist, Zeit-Kontroll-Flits, die aus einem Flit-Strom empfangen werden, die Master-Taktgeberzeitdaten umfassen, zu extrahieren, und eines von a) einer extrahierten Zeit-Kontroll-Flit oder b) Master-Zeitdaten, die in einer extrahierten Zeit-Kontroll-Flit enthalten sind, entlang eines Bypassschaltungspfads zwischen dem vorgeschalteten Taktgeberport und mindestens einem nachgeschalteten Taktgeberport weiterzuleiten.
  21. Fabric-Schalter nach Anspruch 20, ferner umfassend: Zeit-Kontroll-Flit-Injektionslogik an jedem des mindestens einen nachgeschalteten Taktgeberports, die konfiguriert ist a) Master-Zeitdaten, die von einem vorgeschalteten Taktgeberport entlang des Bypassschaltungspfads weitergeleitet werden, zu empfangen, eine neue Zeit-Kontroll-Flit zu generieren und die neue Zeit-Kontroll-Flit in einen Flit-Strom, der auf einen Fabric-Link von dem nachgeschalteten Taktgeberport ausgesendet wird, zu injizieren; und/oder b) eine Zeit-Kontroll-Flit, die von einem vorgeschalteten Taktgeberport entlang des Bypassschaltungspfads weitergeleitet wird, zu empfangen, und die Zeit-Kontroll-Flit in einen Flit-Strom, der auf einen Fabric-Link von dem nachgeschalteten Taktgeberport ausgesendet wird, zu injizieren.
  22. System, umfassend: einen Master-Taktgeber-Knoten mit einem Master-Taktgeber und einschließlich einer Host-Fabric-Schnittstelle (Host Fabric Interface; HFI); eine Vielzahl von Slave-Knoten, von denen jeder einen lokalen Taktgeber enthält und eine HFI enthält; eine Vielzahl von Fabric-Schaltern, von denen jeder enthält: eine Vielzahl von Ports, von denen jeder einen Empfangsport enthält, der operativ mit einem Empfangspuffer gekoppelt ist, und einen Sendeport, der operativ mit einem Sendepuffer gekoppelt ist, mindestens einen Port, der einen vorgeschalteten Taktgeberport umfasst, und mindestens einen Port, der einen nachgeschalteten Taktgeberport umfasst; Schaltungsanordnung, die, während des Betriebs, auswählbare Verbindung zwischen Paaren von Empfangspuffern und Sendepuffern verschiedener Ports befähigt; mindestens einen Bypassschaltungspfad zwischen dem mindestens einen vorgeschalteten Taktgeberport und dem mindestens einen nachgeschalteten Taktgeberport; und eine Vielzahl von Fabric-Links, die Ports an der Vielzahl von Fabric-Schaltern, dem Master-Taktgeber-Knoten und der Vielzahl von Slave-Knoten untereinander verbinden, wobei während des Betriebs des Systems der Master-Taktgeber-Knoten Master-Taktgeberzeitdaten generiert, die an jeden der Slave-Knoten über einen Taktgeberbaumpfad mit einer festen Latenz weitergeleitet werden, wobei jeder Taktgeberbaumpfad den Bypassschaltungspfad für mindestens einen Fabric-Schalter und eine Vielzahl von Fabric-Links quert.
  23. System nach Anspruch 22, wobei jeder Fabric-Schalter konfiguriert ist, Master-Taktgeberzeitdaten entlang dem mindestens einen Bypassschaltungspfad auf eine Weise zu weiterzuleiten, die die Empfangspuffer, die Sendepuffer und die Schaltungsanordnung umgeht.
  24. System nach Anspruch 23, wobei das System Operationen zum Ermöglichen von Synchronisation der lokalen Taktgeber an den Slave-Knoten mit dem Master-Taktgeber durchführt, umfassend: Weiterleiten von Master-Taktgeberzeitdaten, die von dem Master-Taktgeber generiert werden, an jeden der Vielzahl von Slave-Knoten über einen jeweiligen Taktgeberbaumpfad mit einer festen Latenz; für jeden Slave-Knoten, Feststellen der festen Latenz des Taktgeberbaumpfads von dem Master-Taktgeber-Knoten zu dem Slave-Knoten; und Synchronisieren eines lokalen Taktgebers für den Slave-Knoten und den Master-Taktgeber, der an dem Master-Taktgeber-Knoten arbeitet, unter Verwendung der Master-Taktgeberzeitdaten, die von dem Slave-Knoten erhalten werden, und der festen Latenz des Taktgeberbaumpfads von dem Master-Taktgeber-Knoten zu dem Slave-Knoten, die festgestellt wird
  25. System nach Anspruch 23 oder 24, wobei das System ferner dafür konfiguriert ist: eine Taktgeberratenfehlanpassung des lokalen Taktgebers an jedem Slave-Knoten relativ zu dem Master-Taktgeber zu erfassen; und die Taktgeberratenfehlanpassung, die für jeden lokalen Taktgeber festgestellt wurde, einzusetzen, um die Synchronisierung zwischen dem Master-Taktgeber und jedem lokalen Taktgeber aufrecht zu erhalten.
DE112016005917.5T 2015-12-22 2016-11-16 Exascale-fabric-zeitsynchronisierung Withdrawn DE112016005917T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/977,773 2015-12-22
US14/977,773 US10372647B2 (en) 2015-12-22 2015-12-22 Exascale fabric time synchronization
PCT/US2016/062195 WO2017112142A1 (en) 2015-12-22 2016-11-16 Exascale fabric time synchronization

Publications (1)

Publication Number Publication Date
DE112016005917T5 true DE112016005917T5 (de) 2018-11-22

Family

ID=59067051

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112016005917.5T Withdrawn DE112016005917T5 (de) 2015-12-22 2016-11-16 Exascale-fabric-zeitsynchronisierung

Country Status (4)

Country Link
US (1) US10372647B2 (de)
CN (1) CN107040326B (de)
DE (1) DE112016005917T5 (de)
WO (1) WO2017112142A1 (de)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10784986B2 (en) 2017-02-28 2020-09-22 Intel Corporation Forward error correction mechanism for peripheral component interconnect-express (PCI-e)
US10771189B2 (en) 2018-12-18 2020-09-08 Intel Corporation Forward error correction mechanism for data transmission across multi-lane links
US10834434B2 (en) * 2018-12-28 2020-11-10 Intel Corporation Methods and apparatus to reduce audio streaming latency between audio and Gigabit Ethernet subsystems
US11637657B2 (en) 2019-02-15 2023-04-25 Intel Corporation Low-latency forward error correction for high-speed serial links
US11249837B2 (en) 2019-03-01 2022-02-15 Intel Corporation Flit-based parallel-forward error correction and parity
CN109947173B (zh) * 2019-03-18 2020-12-18 上海安路信息科技有限公司 最大时钟偏差的计算方法及计算系统
US11296994B2 (en) 2019-05-13 2022-04-05 Intel Corporation Ordered sets for high-speed interconnects
CN110267200A (zh) * 2019-06-27 2019-09-20 合肥更鼓电子科技有限公司 一种基于高精度时间同步网络的基站定位方法
US11212023B2 (en) * 2019-11-06 2021-12-28 Microsoft Technology Licensing, Llc Systems and methods for nodes communicating using a time-synchronized transport layer
US11740958B2 (en) 2019-11-27 2023-08-29 Intel Corporation Multi-protocol support on common physical layer
DE102019219475B4 (de) * 2019-12-12 2021-08-05 Continental Automotive Gmbh Verfahren zur Optimierung der Zeitsynchronisation zwischen über ein Kommunikationsnetzwerk verbundenen Netzwerkgeräten
US11463187B2 (en) 2020-04-14 2022-10-04 Google Llc Fault tolerant design for clock-synchronization systems
US11463973B2 (en) * 2020-04-28 2022-10-04 Microsoft Technology Licensing, Llc Clock synchronization using wireless side channel
US11734105B2 (en) * 2020-07-06 2023-08-22 International Business Machines Corporation Efficient error reporting in a link interface
CN114070448B (zh) * 2021-12-06 2023-07-25 重庆邮电大学 一种基于多属性决策的主时钟选取方法
CN114173367B (zh) * 2021-12-23 2023-11-03 烽火通信科技股份有限公司 时间同步路径保护方法、装置及可读存储介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5935232A (en) 1995-11-20 1999-08-10 Advanced Micro Devices, Inc. Variable latency and bandwidth communication pathways
US8428069B2 (en) * 1998-08-19 2013-04-23 Wayne Richard Howe Stealth packet switching
AU2003215841A1 (en) * 2002-04-30 2003-11-17 International Business Machines Corporation Method and arrangement for local synchronization in master-slave distributed communication systems
US7492770B2 (en) 2005-08-31 2009-02-17 Starent Networks, Corp. Synchronizing data transmission over wireless networks
US8599827B2 (en) 2011-10-21 2013-12-03 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatuses for maintaining synchronization between a radio equipment controller and an item of radio equipment
US8737551B1 (en) 2012-11-06 2014-05-27 Motorola Mobility Llc Synchronizing receive data over a digital radio frequency (RF) interface
US9665121B2 (en) * 2014-12-11 2017-05-30 Khalifa University Of Science, Technology And Research Method and devices for time transfer using peer-to-peer transparent clocks

Also Published As

Publication number Publication date
US20170177527A1 (en) 2017-06-22
CN107040326A (zh) 2017-08-11
CN107040326B (zh) 2019-03-22
US10372647B2 (en) 2019-08-06
WO2017112142A1 (en) 2017-06-29

Similar Documents

Publication Publication Date Title
DE112016005917T5 (de) Exascale-fabric-zeitsynchronisierung
DE102020112346A1 (de) Techniken zum betrieb einer tdm-mac
DE60219047T2 (de) Eine allgemeine eingabe-/ausgabearchitektur und entsprechende verfahren zum aufbau virtueller kanäle darin
DE112011102415B4 (de) Registerzugriff in einer verteilten virtuellen Brückenumgebung
DE112015006944B4 (de) Einrichtung, System und Verfahren zum Ermöglichen einer Kommunikation über eine Verbindung mit einer Vorrichtung außerhalb einer Baugruppe
DE69533230T2 (de) Verfahren und vorrichtung zur verbesserung der fehlertoleranz eines netzwerkes
DE102013209118B4 (de) Beibehaltung und Änderung von Netzwerküberlastungsbenachrichtigungen während der Übertragung von Netzwerkdaten zwischen einem physischen Netzwerk und einem virtuellen Netzwerk
DE112010001824B4 (de) Paketierte Schnittstelle zur Kopplung von Agenten
DE60317890T2 (de) Verfahren und anordnung zur lokalen synchronisation in verteilten master-slave-kommunikationssystemen
DE112013005090T5 (de) Steuernachrichtenübermittlung in einem mehrfach-Slot-Verbindungsschicht-Flit
DE112013001306B4 (de) Verwalten eines verteilten Fabric-Systems
DE112011103225B4 (de) Schaltkreisvorrichtung, System und Verfahren mit Drosseln einer integrierten Verbindung
DE112015006961T5 (de) Verbindungsfehlerdetektion in mehrfachchipgehäusen
USRE49806E1 (en) Timestamping packets in a network
DE112011100164T5 (de) Umsetzen einer geordneten und zuverlässigen Übertragung von Datenpaketen
DE102014108457B3 (de) Netzwerkverteiler
CN105993150A (zh) 增加网络设备中的分组处理速率
DE112005001364T5 (de) Verarbeiten von Empfangsprotokolldateneinheiten
DE102009043278A1 (de) Netzsynchronisation über IP-Netze
DE102019003979B4 (de) System und verfahren zum durchführen einer interpacket-gap-reparatur für verlustbehaftete protokolle
DE112004002043B4 (de) Verfahren, System und Programm zum Aufbau eines Pakets
DE102020102820A1 (de) Zeitstempel-Ausrichtung über mehrere Rechenknoten
DE102022129250A1 (de) Übertragungsrate basierend auf detektierter verfügbarer Bandbreite
DE102020110851A1 (de) Verteilte fehler- und anomaliekommunikationsarchitektur für analog- und misch-signalsysteme
DE102015010969A1 (de) Netzwerkmodul zum Senden und/oder Empfang von Datenpaketen von einer Netzwerkeinrichtung und Verfahren

Legal Events

Date Code Title Description
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee