![[*]](http://fubphpc.tu-graz.ac.at/icons.gif/foot_motif.gif){kind=icon}
, sondern die permanent verfügbare Rechenleistung (/FLOPW, FLOPM
oder FLOPY) von
Interesse.
Noch vor etwa 15 Jahren wurden beinahe ausschließlich große Computer im Time-Sharing Verfahren benutzt. Jeder Benutzer hatte dadurch Zugang zur gesamten Rechenleistung einer Organisation. Heute sind viele Workstations den Benutzern direkt zugeordnet; diese Computer werden häufig nur während kurzer Zeiten vollständig genutzt. Mittels High Throughput Computing wird versucht, diese Ressourcen verfügbar zu machen.
Nachtrag: MOSIX
Allerdings sind Supercomputer in Anschaffung und Unterhalt wesentlich teurer als Workstations. Die Entwicklung paralleler Programme wird durch diverse Bibliotheken (PVM [1], MPI [2], ...) zwar unterstützt; dennoch ist Parallelverarbeitung [3] programmtechnisch anspruchsvoll. Die beiden Bibliotheken ermöglichen allerdings die Verwendung von Workstations im Netz zum parallelen Ablauf von Programmen.
Beim High Throughput Computing (HTC) wird besonders auf die
Rechenleistung über lange Zeiträume geachtet; in vielen Fällen ist die kurze
Antwortzeit des HPC nicht erforderlich; notwendig ist, die Berechnungen in
absehbarem Zeitrahmen fertigzustellen. Bei der Rechengeschwindigkeit ist
daher weniger die Spitzenleistung in FLOPS, sondern die permanent verfügbare Rechenleistung (/FLOPW, FLOPM
oder FLOPY) von
Interesse.
Diese Eigenschaften können ohne Veränderungen an den Betriebssystemen erzielt werden. Benutzer von Condor müssen ihre Programme nicht verändern; Linken mit einigen speziellen Libraries ist allerdings notwendig, wenn die Programme im Standard Universe laufen sollen.
Die Hauptziele bei der Entwicklung von Condor waren:
Wenn der Rechner von der Konsole aus benutzt wird, erzeugt Condor in der
Standardkonfiguration einen
Checkpoint, beendet die Ausführung des Programms und setzt die Ausführung
auf einem anderen Computer fort.
Condor sucht freie Kapazitäten, startet den Prozeß auf diesem Rechner, kümmert sich um die Umlenkung der Dateizugriffe auf das Dateisystem des lokalen Rechners; periodische Checkpoints zum automatischen Wiederaufsetzen nach einem Crash werden automatisch erzeugt.
Die Programme müssen im Hintergrund lauffähig sein und dürfen keine Benutzerinteraktionen verlangen. Jeglicher Input wird aus Dateien gelesen; Output vom Schirm auf Dateien umgelenkt. Die Namen dieser Dateien werden in einer Submit-Datei festgelegt.
http://www.cs.wisc.edu/condor/geladen werden. Die Lizenzbedingungen der Academic Object Code Use License for Condor gestatten die unentgeltliche Nutzung für nicht kommerzielle Zwecke.
Frühere Versionen waren als Quelltexte erhältlich; ab der Version 6.0 sind nur mehr die ausführbaren Programme verfügbar. Unterstützte Plattformen sind Silicon Graphics IRIX, Sun Solaris Sparc/i386, Digital Unix, IBM AIX und Linux i386. Ältere Versionen laufen auch mit Sun OS und HPUX 10. Unterstützung für Windows NT war für diese Version geplant, konnte aber wegen technischer Schwierigkeiten mit dem Betriebssystem noch nicht realisiert werden.
Leider gibt es für die aktuelle Version 6.0 keine Manual Pages im troff-Format mehr. Dokumentation [7] ist lokal unter /usr/local/doc/condor/... zu finden.
Programme die im Standard Universe laufen sollen, müssen mit einigen speziellen Bibliotheken gelinkt werden. Dazu ist nur nötig, vor dem Befehl zum Erzeugen der ausführbaren Programme condor_compile anzugeben.
können parallele Programme ausgeführt werde; Condor stellt die geforderte
Anzahl von Computern aus dem Pool der gerade freien Rechner bereit.
Um die Prozesse zu starten, muß eine Submit-Datei geschrieben und mit dem Befehl condor_submit ausgeführt werden. Ein einfaches Beispiel für eine Submit-Datei ist
Executable = foo Error = foo.err Log = foo.log Arguments = 1 3 Input = inp.$(Process) Output = out.$(Process) Queue 100
Mit dieser Datei wird das Programm foo 100 mal ausgeführt. Die Standardeingabe bzw. Standardausgabe wird dabei für den ersten Prozess auf die Dateien inp.0 und out.0 gelenkt; für den zweiten Prozess auf inp.1 und out.1. Die Fehlerausgaben werden nach foo.err und die Logginginformationen nach foo.log geschrieben.
Während die Programme laufen, kann mit dem Kommando condor_status die Belegung der Computer im Pool geprüft werden; mit condor_q -global wird der Status der wartenden Programme gezeigt.
Das Programm erhält seine Eingabeparameter über die Kommandozeile:
positron_walk <anz> <en>
<anz> Anzahl der Positronen
<en> Anfangsenergie der Positronen [eV]
Als Ausgabe wird die Restenergie und der Endpunkt des Positrons auf die Standardausgabe geschrieben.
Für die Simulation verwendete ich jeweils 5000 Positronen, die Anfangsenergie wurde in Schritten von 100 eV von 1000 bis 5500 eV variiert. Ich habe mit einem Perl-Skript die Submit-Datei erzeugt. Abschicken der Programme zu Condor erzeugt 46 Prozesse, die der Reihe nach den freien Computern zugeordnet werden.
Die Laufzeiten der einzelnen Programme liegen im Bereich von 20 Sekunden bis 7 Minuten; alle Tasks waren am 7.6.1998 nach etwa 27 Minuten abgeschlossen. Verwendet wurde dabei ein Pentium 200MMX und vier i486DX2/66 mit 128 bzw. 32 MB RAM. Die Laufzeiten können mit dem Befehl condor_history | less betrachtet werden.
Zur Programmierung des Perl-Skripts war ein Mehraufwand von wenigen Minuten notwendig. Für eine parallele Implementierung wäre der zusätzliche Aufwand wesentlich größer gewesen.
#!/usr/bin/perl -w
print <<EOF
Executable = positron_walk
Log = foo.log
Error = foo.err
Universe = vanilla
EOF;
for ($e=1000; $e<=5500; $e+=100){
print "Arguments = 5000 $e\n";
print "Output = foo.out.$e\n";
print "Queue\n\n";
}
Executable = positron_walk Log = foo.log Error = foo.err Universe = vanilla Arguments = 5000 1000 Output = foo.out.1000 Queue Arguments = 5000 1100 Output = foo.out.1100 Queue .... .... .... Arguments = 5000 5500 Output = foo.out.5500 Queue
An der Submit Datei sieht man, daß die Verwendung des Prozesszählers praktischer wäre; leider kann man in der Submit-Datei nicht rechnen.
This document was generated using the LaTeX2HTML translator Version 97.1 (release) (July 13th, 1997)
Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -html_version 3.2 -split 0 -no_navigation HTC.tex.
The translation was initiated by on 9/4/1998