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?
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. –
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. –