Dieser Bericht gliedert sich in zwei Teile. Der erste Teil knüpft an die im letzten Zwischenbericht dargestellten Anwendungen an und erläutert, wie sich die beschriebenen softwaretechnischen Konzepte umsetzen lassen konnten. Im zweiten Teil werden Anstrengungen beschrieben, die insbesondere die Datenübertragung über das Gigabit-Testbed beleuchten sollen.
Im Zwischenbericht GTP-Projekt ViSpaS März 2000 (ZB-0003) wurde die Konzeption zur computertechnischen Umsetzung ausführlich erläutert. Hier soll der aktuelle Stand der Implementierung beschrieben werden. Eine ausführliche Diskussion erfolgt im Abschlussbericht Ende 2000.
Abbildung 1: Initialisierungs-Fenster (links) und Control-GUI-Fenster (rechts)
Das Control-Interface (Control-GUI) wurde umgesetzt und weitgehend implementiert. In Abbildung 1 sind links das Initialisierungs-Fenster zur Eingabe der projektspezifischen Parameter und rechts das Control-Interface, das sich in 3 Teilfenster aufteilt, zu sehen (siehe auch ZB-0003, Abschnitt grafische Benutzeroberfläche).
Es wurde eine Möglichkeit vorgesehen, die zu einem Projekt gehörenden Einstellungen unter einem Projektnamen zu speichern, um so einfach an verschiedenen Problemstellungen arbeiten zu können. Vom Control-Interface ist es nun möglich, das Programm fhimd per Knopfdruck zu starten oder zu beenden. Während der Rechnung kann man manuell die aktuelle Elektronendichte und Atomkonfiguration abfragen und visualisieren, sofern sie vom fhimd-Programm schon berechnet wurden. Dazu wird eine Anfrage an den Daten-Server geschickt (siehe ZB-0003, Abschnitt Datenkommunikation), der die Elektronendichte bzw. die Atomkonfiguration in das gewünschte Format konvertiert und zurückschickt, wo sie dann der Visualisierung zur Darstellung übergeben wird (siehe Abbildung 2).
Abbildung 2: Visualisierung der Atomkonfiguration (grüne und weiße Kugeln) und der Elektronendichte (blaue Iso-Oberfläche)
Zur Zeit wird an der Optimierung der Konvertierung und der Darstellung der Elektronendichte gearbeitet. Da die Datenstruktur der Wellenfunktionen hinsichtlich der Konvertierung, Übertragung und Darstellung sehr ähnlich ist, kann man die Funktionalität der Elektronendichte-Visualisierung leicht auf die von Wellenfunktionen übertragen.
Um die Leistungsfähigkeit des Gigabit-Testbeds einschätzen zu können, ist es wichtig, verschiedene Messungen unter realistischen Betriebsbedingungen durchzuführen. Dazu standen hier Optimierungen hinsichtlich maximalen Datenduchsatzes im Vordergrund. Die im Zwischenbericht GTB-Projekt ViSpaS März 2000 besprochenen Problemstellungen der Ergonomie, Stabilität und Flexibilität der Software wurden dabei zunächst ausgeklammert.
Die Gigabit-Testbed-Verbindung vom Rechenzentrum Garching (Rechner cray t3e) zum FHI Berlin (Rechner SGI rodin) wird zur Zeit im Modus CLIP (classical IP over ATM) betrieben. Durch den ATM- und IP- Overhead ergibt sich für den 622 MBit Adapter ein maximaler Durchsatzwert von 538,053 MBit/sec [Abschlussbericht Testbed West, Bericht GIGAnet http://webdoc.sub.gwdg.de/ebook/ah/1999/dfn/GTBWest.pdf].
Für Messungen des Durchsatzes wurde das parallele Programm fhi98md so verändert, dass während einer Rechnung unterschiedlich große Datenmengen über das Gigabit-Testbed geschickt werden können, die auf der anderen Seite (rodin) von einem Programm empfangen werden. Die für die Socket-Kommunikation zuständigen Funktionen sind c-Routinen, die vom fhi98md-Fortran-Code aufgerufen werden.
Folgende Parameter haben sich hinsichtlich des maximalen Durchsatzes als optimal erwiesen:
MTU = 65280 Byte (maximum transmission unit) des Fore-ATM-Interfaces; Diese Puffergröße kann auf dem ATM-Interface bis maximal 65535 Byte groß werden [FORE-Runner User's Manual 5.1.6], die benutzte MTU wurde vom HiPPI-Switch vorgegeben.
TCP-Buffersize = 2097152 Byte - Puffergröße beim Initialisieren der Socketverbindung innerhalb einer c-Routine (getestet wurden 524288 - 4194304) auf cray und rodin.
Das Programm fhi98md wurde für die hier beschriebenen Messungen des Durchsatzes mit Hilfe des Queueing-Systems (small queue) der cray T3E gestartet und lief parallel auf 16 Prozessoren.
Das Einsammeln der verteilten Daten zum dreidimensionalen Datensatz der Elektronendichte von den einzelnen Prozessoren erfolgte mit der cray-shmemget-Routinen vor dem Senden. Die Kommunikation über die Socket-Verbindung übernahm ein ausgewählter Prozessor (master), um zu gewährleisten, dass die Durchsatzrate unabhängig von der Anzahl der Prozessoren ist.
Für die Bestimmung des Durchsatzes wurde vor und nach dem Aufrufen der socket-write-Routine die Zeit mit Hilfe der gettimeofday-Routine ausgegeben. Zunächst wird eine „normale“ Rechnung (in der Grafik mit Nr. 000704-0812 bezeichnet) ausführlicher erläutert. Im Anschluss werden verschiedene typische Abweichungen besprochen. Als Beispiel wurde hier eine GaAs-Struktur mit 8 Atomen berechnet.
Abbildung 3: Durchsatzraten während einer Rechnung: der Durchsatz auf der cray ist in rot dargestellt, der auf der rodin in schwarz. Nach jeder Iteration des fhi98md-Programms wird eine neue Elektronendichte berechnet und über das Gigabit-Testbed gesendet - hier als rechteckige Balken dargestellt. Die Größe des übermittelten Datenfeldes wurde nach jeweils 10 Iterationen vervierfacht, beginnend mit 2 MBit (entspricht einem Datenfeld von 32000 64-Bit-Realzahlen) bis zu einer maximalen Größe von 896 MBit (14 Mio Realzahlen), wie in der unteren x-Achse zu sehen ist.
In Abbildung 3 sieht man den Durchsatz der übermittelten Daten während einer Rechnung bei verschieden großen Datenfeldern. Auf der rodin geht die Durchsatzrate (rote Linien) bei einer Datenfeld-Größe von 131 MBit (ab der 31. Iteration, 150 sec in Abb. 3) in eine Sättigung von etwa 300 MBit/sec (siehe auch Abbildung 4) während auf der cray ein Wert von etwa 250 MBit/sec erreicht wird. Für die Differenz der Durchsatzraten sind wahrscheinlich Pufferungen in den Rechnern selbst sowie auf der Strecke verantwortlich.
Die hohen Durchsatzwerte bei kleinen Datenpaketen auf der cray (schwarze Linien bis 100 sec in Abbildung 3) sind auf Fehler der gettimeofday-Routine durch die begrenzte zeitliche Auflösung des Rechners zurückzuführen.
Abbildung 4: Durchsatzrate in Abhängigkeit von der gesandten Datenmenge auf rodin. Man erkennt gut das Ansteigen des Durchsatzes bei steigender Datenmenge und das Erreichen der Sättigung bei einer Feldgröße von 130 MBit.
Abbildung 5: Zeit für das Senden eines Datenpaketes (Dt) in Abhängigkeit von der Größe der Datenmenge
Die Größe des Durchsatzes scheint von vielen anderen Faktoren abhängig zu sein. Nachfolgend sind fünf Beispiele für unterschiedliche, aber typische Verhaltensmuster des Durchsatzes während einer Messung bei ansonsten gleichen Parametern (16 Prozessoren, Datenmenge 2 - 896 MBit, 99 Iterationen, MTU 65280) aufgeführt.
Verglichen mit der Messung in Abbildung 3 sind in Abbildung 6 deutliche zeitliche Schwankungen zu erkennen.
In Abbildung 7 liegt die Durchsatzrate relativ konstant bei 260 MBit/sec und sinkt dann bei 430 sec auf einen relativ konstanten Wert von 215 MBit/sec.
In Abbildung 8 sinkt die Durchsatzrate relativ gleichmäßig von 300 auf 240 MBit/sec.
Abbildung 9 zeigt einen starken Einbruch der Durchsatzrate bei 500 sec.
In Abbildung 10 ist der Durchsatz während einer Rechnung zu sehen, die nach 40 Iterationen abstürzte.
Abbildung 6: Beispiel (a) Durchsatzmessungen mit relativ starken Schwankungen des Durchsatzes [000703-1928]
Abbildung 7: Beispiel (b) Durchsatzmessung mit plötzlicher Abnahme des Durchsatzes [000704-1327]
Abbildung 8: Beispiel (c) Durchsatzmessung mit langsamer Abnahme des Durchsatzes [000704-1247]
Abbildung 9: Beispiel (d) Durchsatzmessung mit Einbrüchen des Durchsatzes [000703-1349]
Abbildung 10: Beispiel (e) Durchsatzmessung mit Absturz des visualisierenden Daten zu puffern und mit einem separaten Prozess / fhi98md-Programms nach 40 Iterationen [000704-1148]
Die Messungen der Durchsatzraten zeigen, dass es möglich ist, Daten direkt von dem fhi98md-Programm über das Gigabit-Testbed zur Visualisierung an die Grafik-Workstation zu senden, wobei ein Durchsatz von 300 MBit/sec erreicht werden konnte. Diese Durchsatzrate entspricht 0.3 - 10 Datensätzen / sec und erscheint für den interaktiven Betrieb akzeptabel.
Die starken äußeren Einflüsse, insbesondere die häufigen, vom Netz verursachten Abstürze des fhi98md-Programms, machen diese Art der Datenübertragung jedoch nicht praktikabel, da ein unvorhergesehener Abbruch des Programms nicht akzeptabel ist. Es erwies sich daher als zwingend, die zu visualisierenden Daten zu puffern und mit einem separaten Prozess / separaten Programm (siehe Abschnitt I Daten-Server) über das Gigabit-Testbed zu übermitteln.