2014-02-26 21 views
9

Ich schreibe eine Multi-Threaded OpenMPI-Anwendung, MPI_Isend und MPI_Irecv von mehreren Threads verwenden, um Hunderte von Nachrichten pro Sekunde zwischen Rängen über InfiniBand RDMA auszutauschen.InfiniBand: Übertragungsrate hängt von MPI_Test * Frequenz

Übertragungen sind in der Größenordnung von 400 - 800KByte, generieren etwa 9 Gbps ein- und aus für jeden Rang, gut innerhalb der Kapazität von FDR. Einfache MPI-Benchmarks zeigen ebenfalls eine gute Leistung.

Der Abschluss der Übertragungen wird überprüft, indem alle aktiven Übertragungen mit MPI_Testsome in einem dedizierten Thread abgefragt werden.

Die Übertragungsraten, die ich erreiche, hängen von der Nachrichtenrate ab, aber noch wichtiger von der Abfragehäufigkeit von MPI_Testsome. Das heißt, wenn ich alle 10ms abfrage, enden die Anfragen später als wenn ich alle 1ms abfrage.

Ich würde erwarten, dass, wenn ich evert 10ms statt alle 1ms abfragte, würde ich höchstens 9ms später über abgeschlossene Anfragen informiert werden. Ich würde nicht erwarten, dass die Übertragungen die Fertigstellung durch weniger Aufrufe von MPI_Testsome verzögern und somit die gesamten Übertragungsraten verlangsamen. Ich würde erwarten, dass MPI_Testsome vollständig passiv ist.

Jeder hier hat eine Ahnung, warum dieses Verhalten auftreten könnte?

Antwort

9

Das beobachtete Verhalten ist auf die Art und Weise zurückzuführen, in der der Operationsfortschritt in Open MPI implementiert wird. Das Senden oder Empfangen einer Nachricht, unabhängig davon, ob sie synchron oder asynchron erfolgt, führt dazu, dass eine Reihe interner Vorgänge in die Warteschlange gestellt wird. Progression ist im Grunde die Verarbeitung dieser eingereihten Operationen. Es gibt zwei Modi, die Sie beim Erstellen der Bibliothek auswählen können: eine mit einem asynchronen Progressions-Thread und eine ohne die Standardeinstellung.

Wenn die Bibliothek mit aktiviertem asynchronen Progressionsthread kompiliert wird, wird die Warteschlange von einem Hintergrundthread bearbeitet und verarbeitet. Dies ermöglicht, dass Hintergrundübertragungen parallel mit dem Benutzercode beginnen, erhöht jedoch die Latenz. Ohne asynchrone Progression sind Operationen schneller, aber eine Progression kann nur stattfinden, wenn der Benutzercode in die MPI-Bibliothek aufruft, z. während in MPI_Wait oder MPI_Test und Familie. Die Funktionsfamilie MPI_Test ist so implementiert, dass sie so schnell wie möglich zurückkehrt. Das bedeutet, dass die Bibliothek einen Kompromiss zwischen der Ausführung von Aufgaben im Anruf, der Verlangsamung oder der schnellen Rückmeldung ausgleichen muss, was bedeutet, dass bei jedem Anruf weniger Vorgänge ausgeführt werden.

Einige der Open MPI-Entwickler, insbesondere Jeff Squyres, besuchen ab und zu Stack Overflow. Er könnte möglicherweise mehr Details zur Verfügung stellen.

Dieses Verhalten ist für Open MPI kaum spezifisch. Sofern nicht stark hardwaregestützt, wird MPI üblicherweise nach den gleichen Methoden implementiert.

+1

Danke! Ich habe nicht erkannt, asynchrone Progression ist nicht der Standard. Ich habe jedoch einen 'btl_openib_async_event_thread' ausgeführt (nach gdb). Die Option 'btl_openib_use_async_event_thread' ist ebenfalls festgelegt. Ich werde mit der Neuerstellung von OpenMPI beginnen, um zu sehen, ob ich diesen Aspekt besser kontrollieren kann. –

+2

Dieser 'openib'-asynchrone Thread ist nicht der asynchrone Progressions-Thread, den ich erwähnt habe. Es liest Benachrichtigungsnachrichten aus den InfiniBand-Abschlusswarteschlangen und aktualisiert möglicherweise den Status der ausstehenden Ereignisse in der Progressions-Warteschlange. –