Sprungmarken

Die letzten Meldungen

Wartung des zentralen Installationsservers Rocky

21. November 2014

Am Mittwoch den 26.11.201, sowie am Dienstag den 02.12.2014 und am Mittwoch den 03.12.2014 werden jeweils ganztags die beiden zentralen Installationsserver Rocky.rrze.uni-erlangen.de und Sylvester.wiso.uni-erlangen.de nicht zur Verfügung stehen.
Weiterlesen...

Wartungsankündigung: Schulungszentrums-Seiten am 24.11. zeitweise nicht erreichbar

21. November 2014

Wegen einer Wartung der Datenbank sind die Webseiten des Schulungszentrums am 24.11. voraussichtlich ab 9.00 Uhr einige Stunden lang nicht erreichbar. Bitte entschuldigen Sie die Störung.
Weiterlesen...

Serverwartung am 12.12.2014 ab 16:00 Uhr für die Novell-Server MEMORY und SCRABBLE

18. November 2014

Große Serverwartung des MEMORY und SCRABBLE am 12.12.2014.  Die Server stehen somit von Freitag, den 12.12.2014, 16:00 Uhr bis Montag, den 15.12.2014, 8:00 Uhr nicht zur Verfügung.
Weiterlesen...

Meldungen nach Thema

 

SGI Origin 3400

Diese Maschine ist seit dem 14. März 2008 Geschichte. Nach dem Ausfall eines weiteren Computebricks in der schon seit laengerem nicht mehr gewarteten (Wartungsvertrag ausgelaufen, Ersatzteile verboten teuer) Maschine war sie nicht mehr betriebsfähig, denn für den Betrieb sind mindestens 2 funktionierende Computebricks nötig.
Diese Dokumentation hat daher bestenfalls noch historischen Wert.

Photo der SGI Origin 3400 Seit Juni 2001 ist am RRZE eine Maschine der Externer Link:  Firma SGI vom Typ Origin 3400 mit 28 Prozessoren und 56GByte Hauptspeicher installiert. Es handelt sich um eine ccNUMA-Architektur, d.h. der gesamte Hauptspeicher ist von jedem Prozessor aus linear adressierbar, physikalisch jedoch auf Knoten zu je vier CPUs verteilt. Cache-Kohärenz über die Prozessoren hinweg wird von der Hardware automatisch sicher gestellt.

Dieser Rechner ist für speicherintensive, serielle bzw. moderat parallele Programme vorgesehen. Als Parallelisierungsmodell bietet sich auf einer ccNUMA-Architektur natürlich ein Thread-Ansatz (OpenMP, POSIX Threads) an, jedoch sind auch MPI und PVM verfügbar. Shared- und distributed-Memory-Parallelisierung können auch gemischt verwendet werden.

Hardwareaustattung und Architektur

Prozessoren

Bei den 28 Prozessoren handelt es sich um MIPS R14000-CPUs mit folgenden Eigenschaften:

  • 4-fach superskalar mit out-of-order Execution
  • 500 MHz Taktfrequenz. Die CPU kann zwei Fließkomma-Operationen (eine Multiplikation, eine Addition) pro Takt ausführen, woraus sich eine Spitzenleistung von 1 GFlop/s ergibt. Die Latenz jeder FP-Einheit beträgt dabei 2 Takte, die Latenz einer MULT/ADD-Operation 4 Takte.
  • Je 32 kB L1-Daten- bzw. Instruktionscache mit zweifacher Assoziativität. Die Bandbreite des Datencaches beträgt 12 GByte/s (2 Loads + 1 Store pro Takt), die Länge einer Cache-Zeile ist 32 Byte (4 Worte).
  • 8 MByte unified L2-Cache, zweifach assoziativ. Der L2-Cache hat die gleiche Bandbreite wie der L1-Cache und eine etwas schlechtere Latenz.
  • Die theoretische Bandbreite zum Hauptspeicher beträgt 1.6 GByte/s für jeden Prozessor (200 MHz, 64 Bit). Aufgrund der Organisation des Speicher-Interfaces kann es passieren, dass dieser Wert in der Realität wesentlich geringer ausfällt (s.u.).

Distributed Shared Memory (DSM)

Der Hauptspeicher der Origin3400 folgt dem sog. ccNUMA (cache-coherent Non-Uniform Memory Access) Prinzip. Für den Anwender bedeutet dies zunächst, dass er den gesamten Speicher des Systems als einen einzigen Adressraum ansehen kann.
Physikalisch handelt es sich jedoch nicht um einen gemeinsamen Speicher, sondern um einen verteilten Speicher mit gemeinsamem Adressraum (Distributed Shared Memory = DSM). Dabei ist der Zugriff auf den Speicher intern wie folgt organisiert:

  • Compute Node (C-Brick): Jeweils vier Prozessoren mit eigenem L1- und L2-Cache greifen über einen Hub (s.u.) auf einen gemeinsamen "lokalen" Speicher zu. Hier sind die Prozessoren im Hinblick auf den Speicher gleichberechtigt, es handelt sich also um ein echtes SMP-System.
  • Router Bricks: Sie stellen die Verbindung unter den C-Bricks her und bilden damit die Basis des sogenannten NUMALink-Netzwerkes
  • Das Origin3400 System besteht aus zwei R-Bricks, die miteinander verbunden sind und kann daher mit maximal 4 * 4 * 2 = 32 Prozessoren ausgerüstet werden (s.u.).

SMP-Modul

Auf einem CPU-Modul ("C-Brick") befinden sich 4 CPUs zusammen mit 8 GByte RAM. Der Datenverkehr findet über das sogenannte "Bedrock ASIC" statt, ein Crossbar-Hub-Modul, das auch die Verbindung zum NUMALink-Netzwerk und I/O-Bausteinen (I-Bricks bzw. P-Bricks) herstellt:

Schema des SMP-Moduls Layout eines C-Bricks, des zentralen SMP-Moduls. Bedrock ASIC mit Interfaces zu CPUs, Speicher, Netzwerk und I/O

Je zwei CPUs teilen sich also eine Bandbreite von 1.6 GByte/s zum Hauptspeicher. Bei speichergebundenen Applikationen kann es also sinnvoll sein, nur zwei der vier CPUs auf einem C-Brick zu benutzen. Die Bandbreite zum NUMALink-Netzwerk beträgt immer noch 1.6 GByte/s, so dass eine CPU pro C-Brick mit voller Geschwindigkeit auf entfernten Speicher zugreifen kann, natürlich mit entsprechend höherer Latenz.

Der I/O-Port dient zum Anschluss von I-Bricks bzw. P-Bricks, die I/O-Devices wie Bootplatten und PCI-Interfaces enthalten.

NUMALink-Netzwerk

Die C-Bricks sind über das sogenannte NUMALink-Netzwerk gekoppelt. Das zentrale Element ist der sogenannte Router Brick (R-Brick), ein nichtblockierender Switch mit acht (im Fall der Origin 3400 sechs) Ports. An ihn können bis zu vier C-Bricks und vier bzw. zwei weitere R-Bricks angeschlossen werden. Die Origin 3400 am RRZE mit sieben C-Bricks und zwei R-Bricks sieht somit schematisch folgendermaßen aus:

Schema des Origin 3400-Systems Layout des Origin 3400 Systems am RRZE. Grün, blau und rot sind beispielhaft drei Speicherzugriffspfade mit unterschiedlicher Latenz eingezeichnet.

Damit ergeben sich für das Origin3400 System folgende Speicherhierarchien:

  • L1-Cache: 32 kB On-Chip
  • L2-Cache: 8 MB Off-Chip
  • Memory lokal: Zugriff über den Hub auf das lokale Memory innerhalb eines C-brick. (1 x Hub)
  • Memory nicht-lokal-1: Zugriff auf das Memory eines anderen C-Brick, der aber am gleichen R-Brick angeschlossen ist. ( 1 x Hub + 1 x Router + 1 x Hub)
  • Memory nicht-lokal-2: Zugriff auf das Memory eines anderen C-Brick, der nicht am gleichen R-Brick angeschlossen ist. ( 1 x Hub + 1 x Router + 1 x Router + 1 x Hub)

Die unterschiedlichen Wege zu den Daten unterscheiden sich also sowohl im Hinblick auf Bandbreite als auch Latenz des Zugriffes (daher auch die Bezeichnung NUMA). Es ist daher sinnvoll - falls möglich -, die Datenzugriffe so zu organisieren, dass neben den beiden Caches vor allem Daten aus dem lokalen Speicher gelesen werden, und das mit möglichst großer Bandbreite. Im Abschnitt über DSM-Umgebungsvariablen ist beschrieben, wie man dem System dabei etwas unter die Arme greifen kann.

Zugang und Umgebung

Systemname: mssgi1.rrze.uni-erlangen.de (IP: 131.188.3.26)

Für einen Schnupper-Account bzw. einen Projektantrag wenden Sie sich bitte an die HPC-Beratung des RRZE. in jedem Fall ist jedoch ein gültiger RRZE-Benutzeraccount Voraussetzung, den man in der Service-Theke beantragen kann.

Arbeitsumgebung

Das Setup aller erforderlichen Pfade und sonstigen Umgebungsvariablen, die zur Nutzung der Standardsoftware notwendig sind, wird für Nutzer der csh automatisch beim Einloggen durchgeführt. Für Nutzer anderer Shells hier eine kurze Übersicht:

Alle gebräuchlichen Shells (sh, bash, csh, tcsh, ksh) sind in /usr/bin vorhanden. Damit alle Programme und Tools gefunden werden, sollte die PATH-Variable wie folgt aussehen:

PATH=/sbin:/usr/sbin:/usr/bsd:/usr/bin/X11:/usr/gnu/bin:/usr/freeware/bin:/usr/pbs/bin

Da einige der GNU-Tools nicht 64-Bit-fest sind bzw. ein anderes Verhalten zeigen als die Standard-IRIX-Tools, empfehlen wir dringend, den Pfadteil /usr/gnu/bin:/usr/freeware/bin möglichst weit hinten zu platzieren.

Die MANPATH-Variable sollte folgende Pfade enthalten:

MANPATH=/usr/pbs/man:/usr/share/catman:/usr/share/man:/usr/catman:/usr/man:/usr/gnu/catman:/usr/freeware/catman

Plattenplatz

Standardmäßig ist das Home-Directory das gleiche wie auf allen HPC-Maschinen des RRZE. Gleichzeitig existiert aber unter /home.stand/mssgi1/ ein lokales RAID-System, auf dem jedem Benutzer ein eigenes Verzeichnis eingerichtet wird. Der Pfad dorthin lautet dann allgemein /home.stand/mssgi1/<group>/<username>. Die lokale Platte ist unter dem Pfad /home/mssgi1/ von allen RRZE-Hosts (z.B. vom Dialog-Server cssun) aus über NFS erreichbar und befindet sich auch im RRZE-Backup.

Der gesamte lokale Plattenplatz beläuft sich aktuell auf ca. 700 GByte. Abgesehen vom lokalen Homedirectory gibt es noch einen temporären Datenbereich unter /var/tmp/, der sich nicht im Backup befindet und keinen Quota-Beschränkungen unterliegt. Dort abgelegte Daten unterliegen allerdings einer Gleitlöschung, d.h. alle Dateien, die älter als 6 Monate sind, werden automatisch gelöscht. Die Aufteilung der Plattenkapazität stellt sich im Moment wie folgt dar:

Aufteilung der Plattenkapazitäten
PfadGröße [GB]Kommentar
/home.stand/mssgi1/220 Quota: verschiedene Quota-Stufen möglich, Maximum 20/40 GByte
/var/tmp 470 nicht im Backup, Gleitlöschung!
/tmp< 20 Bitte nicht verwenden!

In /tmp/ sollten nie irgendwelche Userdaten abgelegt werden, denn dieses Verzeichnis befindet sich auf der root-Partition, auf der auch das Betriebssystem residiert. Bitte in /tmp/ keine Daten ablegen!

Programmierung

Compiler

Compiler für C (cc), C++ (CC), FORTRAN77 (f77) und FORTRAN95 (f90) sind vorhanden. Speziell im Hinblick auf Optimierung bieten diese Compiler extrem vielfältige Möglichkeiten. Hier soll eine kurze Übersicht der wichtigsten Optionen genügen. Bei der Beschreibung ist jeweils die Manpage angegeben, auf der man Genaueres erfahren kann.

Generische Optionen

-Oxx=0,1,2,3,fast : Optimierungsstufe
-IPA:...Einstellungen für interprocedural analysis. In einem getrennten Linker-Schritt muss ebenfalls -IPA angegeben sein. [ipa(5)]
-OPT:...feinere Optimierungseinstellungen (Rundung etc.) [opt(5)]
-INLINE:...Festlegungen für die Inlining-Strategie [ipa(5)]
-MP:...Einstellungen zum Multiprocessing
-apoAutomatische Shared-Memory-Parallelisierung einschalten.
-mpMultiprocessing-Direktiven einschalten. Impliziert -MP:openmp=ON. Diese Option ist immer zu verwenden, wenn OpenMP-Direktiven verarbeitet werden sollen.
-DEBUG:... Einstellungen für runtime-Debugging. Wichtige Suboptionen (mit den möglichen Werten ON bzw. OFF) sind [debug_group(5)]:
Einstellungen für runtime-Debugging.
subscript_check Prüfe auf Überschreitungen von Array-Grenzen. Bei F90 wird nur dann abgebrochen, wenn auch die Shellvariable F90_BOUNDS_CHECK_ABORT=YES gesetzt ist.
trap_uninitializedSetzt alle uninitialisierten Fließkomma-Variablen und Pointer auf einen Wert, der bei Benutzung entweder einen FP-Trap oder SEGV erzeugt.
-LNO:...Einstellungen für die Optimierung verschachtelter Schleifen [lno(5)]
-64Erzeugen von 64-Bit-Code. Bitte auch die Hinweise über die mathematischen Bibliotheken im Abschnitt Software beachten!

Bei den zusammengesetzten Optionen (wie -IPA:...) folgt der eigentlichen Option ein String, der diverse Suboptionen steuert. Die Suboptionen sind mit ':' zu trennen. Beispiel:
-DEBUG:subscript_check=ON:trap_uninitialized=ON

Debugger

Der symbolische Debugger von SGI heißt cvd. Mit ihm lassen sich sowohl serielle als auch MPI- bzw. OpenMP-Programme analysieren. Auch die Profiling-Tools (s.u.) sind hier eng mit integriert.

Profiler

Die Profiling-Suite unter IRIX heißt SpeedShop [speedshop(1)]. Die zentralen Tools, die man kennen sollte, lauten:

  • ssusage: Schneller Überblick über Ressourcen-Verbrauch
  • ssrun: Kommandozeilen-Tool zum Profilen von Anwendungen.
  • prof: Auswertung der von ssrun gelieferten Daten.
  • perfex: Auslesen von Hardware-Countern vor und nach dem Programmlauf.

ssusage

Zur Übersicht über verbrauchte Ressourcen dient das Kommando ssusage:
ssusage <executable+args>

ssrun

Dies ist das zentrale Tool, das für die meisten Profiling-Aufgaben ausreicht. Die Ausgabe von ssrun wird mittels prof(1) ausgewertet. ssrun erlaubt es, verschiedene Experimente mit einem Executable durchzuführen. Das Executable muss dabei üblicherweise nicht neu übersetzt oder gelinkt werden (eine Ausnahme bilden hier natürlich manuell instrumentierte Programme):

ssrun [<options>] -<experiment-type> <executable+args>

Das Resultat eines Experiments, d.h. die Profiling-Rohdaten, wird dann in einem File (bei MPI- oder OpenMP-Programmen in mehreren Files) gespeichert, die später mit prof auszuwerten sind. Die Filenamen haben dabei folgenden Aufbau:

<executable-name>.<experiment-type>.<m|p|f|s|e><PID>

Der Buchstabe vor der PID gibt an, ob es sich um den Master- bzw. einen der Slave-Threads handelt, oder ob der Prozess mittels fork(), system() oder exec() gestartet worden war. Die nützlichsten Experimente sind:

Experimente mit ssrun
experiment-typeAktion
totaltimeMisst inklusive und exklusive Wallclock-Zeit für alle Funktionen des Programmes. Bei der inklusiven Zeit sind jeweils die Auführungszeiten aller aufgerufenen Subroutinen mit eingerechnet. Die Exklusive Zeit misst nur die im Code der jeweligen Routine verbrachte Zeit. Subroutinen, die ge-inline-d wurden, zählen hier jedoch dazu.
usertimeSiehe totaltime, nur dass hier die eigentliche Laufzeit des Programmes einchließlich Systemroutinen gemessen wird.
idealBestimmt jeweils die Anzahl, wie oft jeder Block in einem Programm aufgerufen wurde und wie viele Instruktionen bzw. Cycles darin verbracht wurden. Die angegebenen Zeiten sind ideale Zeiten, d.h. sie gelten unter perfekten Bedingungen (keine Bus Contention etc.)
iok.A.
mpik.A.

Bei ideal-Experimenten ist zu bemerken, dass ssrun vor der Ausführung sowohl das Executable als auch sämtliche benötigten Libraries automatisch instrumentiert. Dazu werden im aktuellen Verzeichnis Kopien der entsprechenden Files mit veränderten Namen angelegt.

prof

prof dient dazu, die binären Ausgabefiles von ssrun in ein lesbares Format zu "übersetzen".

prof <options> <profiling-file>

Wichtige Optionen:

-iSortieren der Ausgabe nach der inklusiven statt der exklusiven Laufzeit.
-b Zusätzliche Ausgabe eines "Butterfly-Listings", in dem der gesamte Call-Graph des Programmes (welche Routine wird von welcher anderen Routine aufgerufen) abzulesen ist.
-calipers <start> <stop> Beschränkung des Profilings auf die Zeit zwischen dem Durchlaufen der angegebenen Caliper-Punkte.

perfex

perfex dient zum Auslesen von Performance-Countern auf Programm-Ebene, d.h. es wird beim Start und beim Ende des Programmes ausgelesen und auf Wunsch auch durch die Laufzeit dividiert. Auf diese Weise lässt sich z.B. die Zahl der Cache-Misses oder der ausgeführten Fließkomma-Instruktionen ermitteln.

Shared Memory Programmierung mit Threads

Die Programmierumgebung auf der O3400 unterstützt OpenMP [pe_environ(5)] und POSIX Threads [pthreads(5)]. Leider lassen sich die beiden Strategien nicht in einem Programm mischen. OpenMP Threads bekommen eigene PIDs und sind somit in "top" leicht zu identifizieren. POSIX Threads sind immer mit im Mutterprozess enthalten, haben also alle die gleiche PID und erscheinen nicht getrennt. Beim Profiling erzeugt jeder OpenMP Thread ein eigenes Datenfile, wohingegen die Daten aller POSIX Threads in einem einzigen File gesammelt werden.

OpenMP

Bitte beachten: Nur durch den Parameter -mp bzw. -MP:openmp=ON werden OpenMP-Direktiven im Quellcode vom Compiler berücksichtigt. Auch SGI- bzw. CRAY-spezifische Direktiven sind möglich. Das Verhalten von OpenMP-Programmen kann zur Laufzeit mit Umgebungsvariablen gesteuert werden:

OMP_NUM_THREADS Maximale Zahl zu verwendender Threads falls OMP_DYNAMIC=TRUE, sonst einfach die Zahl der Threads. OMP_NUM_THREADS=1 entspricht vollkommen der seriellen Ausführung des Codes.
OMP_DYNAMIC Falls TRUE wird die Zahl der OpenMP Threads zur Laufzeit je nach Anforderung gewechselt, jedoch übersteigt die Anzahl nie OMP_NUM_THREADS.
OMP_SCHEDULE Scheduling Policy für work-sharing-Konstrukte mit schedule(runtime) in OpenMP-Direktiven. Der Wert von OMP_SCHEDULE sollte dabei dem eigentlich gewünschten Argument der schedule-Option einer OpenMP-Direktive entsprechen, z.B. "dynamic,20".
OMP_NESTEDOhne Funktion. Verschachtelte Parallelisierung wird derzeit von der OpenMP-Implementierung auf der Origin nicht unterstützt.

DSM-Umgebungsvariablen

Die Abbildung der Daten eines Benutzerprogramms auf den verteilten Speicher sowie die Zuordnung der Prozesse bzw. Threads zu den Prozessoren sind für die Performance oft entscheidende Einflussgrößen. Diese können zur Programmlaufzeit vom Benutzer mit Hilfe von Umgebungsvariablen gesteuert werden (siehe auch [pe_environ(5)]):

DSM-Umgebungsvariablen
_DSM_MUSTRUN Bindet jeden Benutzerprozess fest an einen Prozessor Default: OFF
_DSM_PPM Gibt an, wieviele Prozessoren pro Compute Node verwendet werden. Default: 4
_DSM_VERBOSE Falls die Variable gesetzt ist, werden vom OS während der Programmlaufzeit Informationen über die DSM Parameter ausgegeben. Default: OFF

Message Passing mit MPI

Es existieren keine speziellen Compilerskripten für die Übersetzung und das Linken von MPI-Programmen. Die nötigen include-Files (mpi*.h) stehen im Standard-Suchpfad, und beim Linken ist lediglich -lmpi (bei C++-Programmen -lmpi++ -lmpi) anzufügen. Unterstützt wird derzeit Version 1.2 des Externer Link:  MPI-Standards, zusammen mit einigen Elementen des MPI-2 Standards (One-Sided Communication, MPI-IO).

Das Starten von MPI-Programmen erfolgt wie üblich mittels mpirun(1):
mpirun <options> <executable> <argumente>

Wichtige Optionen sind:

Optionen von mpirun
-prefix <prefix_string>Wenn ein MPI-Prozess etwas auf stdout oder stderr ausgibt, so wird dieser Ausgabe der prefix-String vorangestellt (dazu muss die Ausgabe mit newline terminiert sein). Im String bedeutet %g den Rang des Prozesses in MPI_COMM_WORLD, %G die Gesamtzahl der Prozesse.
[-np] <num>Startet num MPI-Prozesse
-statsJeder MPI-Prozess gibt beim abschließenden MPI_Finalize() eine Kommunikations-Statistik aus. Sinnvoll bei gleichzeitiger Verwendung von -prefix.

Die Manpage zu MPI(1) enthält weitere Informationen zu IRIX-MPI.

Message Passing mit PVM

Auch Externer Link:  PVM (Version 3.3.10) wird auf der Origin unterstützt und ist in /usr/array/PVM installiert. PVM verwendet auf dieser Architektur zur Kommunikation Shared Memory. Weitere Informationen liefert die Manpage pvm_intro(1).

Batch Queueing

Seit Anfang 2006 ist statt auf dem Memory-Server das Batchsystem Externer Link:  Torque (Terascale Open-Source Resource and QUEue Manager) im Einsatz, das auch auf dem IA32-Cluster verwendet wird.

Jobs werden submittiert, indem ein sog. Jobskript erstellt und an das qsub-Kommando übergeben wird.

Wichtige qsub-Optionen

Übersicht der qsub-Optionen
-N <Jobname>Setzt einen Namen für den Job, der bei qstat angezeigt wird
-o <outfile>In das angegebene File wird die Standard-Ausgabe abgelegt
-e <errfile>dito für Standard-Fehlerausgabe
-j oe Leitet die Standard-Fehlerausgabe auf stdout um (es wird nur ein Ausgabefile erzeugt, das beide Streams enthält).
-q <Queue>Auswahl der Queue (s.u.). Default-Queue ist router.
-l ncpus=<CPUzahl>Anforderung von CPUs. Die Angabe von "nodes=..." wie auf dem IA32-Cluster ist hier sinnlos. Siehe auch den Abschnitt über Jobskripten.
-l walltime=HH:MM:SS Angabe der benötigten Wallclock-Zeit (Laufzeit) für den Job. Wird nichts angegeben, so wird ein Default-Wert für die gewählte Queue angenommen (momentan ein Stunde). Die Nennung eines Laufzeitlimits hilft dem Scheduler bei der Entscheidung, welche Jobs gestartet werden sollen (Kurzläufer haben Vorteile).
-IInteraktiver Job. Der Benutzer bekommt eine interaktive Shell, wenn der Job startet. Nützlich zum Debuggen und z.B. für Software mit grafischer Oberfläche.
-M x@y -m abeBei Abbruch, Start und Beendigung des Jobs wird eine E-Mail an x@y versandt.
-VAlle Umgebungsvariablen im Environment des qsub-Kommandos werden an den Job weitergereicht.

Die mit -l spezifizierten Ressourcen können auch in einer Option kombiniert werden:

qsub -l ncpus=4,walltime=01:00:00 skript
 

Queues

Folgende Queues sind auf dem Memory-Server eingerichtet:

Queues auf dem Memory-Server
normalFür Jobs bis 16 CPUs und 48 Stunden Laufzeit.
long Für Jobs bis 4 CPUs und 10 Tagen Laufzeit
routerWenn beim qsub keine Queue angegeben wurde, so landet der Job automatisch in der router-Queue. Von dort aus wird er nach Maßgabe seiner Ressourcen-Anforderungen (z.B. ncpus) in eine der anderen Queues einsortiert.

Im Allgemeinen kann man sich also die Angabe der Queue beim Submittieren sparen, sofern man eine CPU-Zahl spezifiziert hat.

Schnelle Testläufe können interaktiv gestartet werden. Relevante Queue-Parameter (maximale Knotenzahl pro Job, Wallclock-Limits) bekommt man mittels der Kommandos qstat -q bzw. qstat -Q -f.

Beispiel-Jobskripten für Torque

Alle Optionen für das qsub-Kommando können auch im Jobskript untergebracht werden. Mit "#PBS" beginnende Kommentarzeilen werden von Torque entsprechend interpretiert (s. Beispiele). Die erste Skriptzeile, die nicht leer und keine Kommentarzeile ist, leitet die Ausführung ein und stoppt jegliche Interpretation von #PBS-Zeilen.

Die Variable $PBS_JOBID enthält die JobID des laufenden Jobs. Für weitere wichtige Shell-Variablen, die im Jobskript ausgewertet werden können, siehe die Manpage zu qsub(1B).

Beispiel-Jobskripten für Torque
Serieller Job:Paralleler Job:
#!/bin/csh
#
# stdout und stderr umleiten
#
#PBS -o job.out
#PBS -e job.err
#
# 8 Stunden Rechenzeit
#
#PBS -l walltime=08:00:00
#

# in das Verzeichnis wechseln, in dem
# der Job submittiert wurde

cd $PBS_O_WORKDIR
 
# los!

./a.out
      
#!/bin/csh
#PBS -o pjob.out
#PBS -e pjob.err
#
# 8 CPUs fuer 6 Stunden
#
#PBS -l ncpus=8,walltime=06:00:00

# in das Verzeichnis wechseln, in dem
# der Job submittiert wurde

cd $PBS_O_WORKDIR
 
# los!

mpirun -np 8 ./a.out
      

Software

Betriebssystem IRIX

Der Memory-Server läuft aktuell unter dem SGI-eigenen UNIX-Betriebssystem Externer Link:  IRIX Version 6.5.

Mathematische Bibliotheken

Mathematische Standardbibliotheken [math(3M)]

Natürlich ist libm als Standard-Bibliothek via -lm verfügbar und enthält alle gewohnten Funktionen. Darüber hinaus gibt es noch die Bibliothek libfastm, die für viele Standardfunktionen schnellere Alternativen mit etwas reduzierter Genauigkeit bereit hält.

SCSL [intro_scsl(3S)]

In der "SGI/CRAY Scientific Library" (libscs, libscs_mp libscs_i8, libscs_i8_mp) sind diverse mathematische Softwarepakete vereint. Die Versionen mit dem Anhängsel "_mp" sind dabei SMP-parallelisierte Codes (siehe auch den Abschnitt über Shared-Memory-Parallelisierung). Der Zusatz "_i8" hingegen führt zu Versionen, die mit 8 Byte langen Array-Indizes umgehen können. Wenn also das 64-Bit-Programmiermodell gewählt wird, um mit großen Arrays zu Arbeiten (mehr als 231 Elemente), ist die Verwendung dieser Library-Versionen Pflicht.

Folgende Pakete stellt SCSL zur Verfügung:

  • BLAS Level 1, 2 und 3 [intro_blas1(3S), intro_blas2(3S), intro_blas3(3S)]
  • LAPACK 3.0 [intro_lapack(3S)]
  • FFT, Faltung, Korrelation [intro_fft(3S)]
  • Lineare Gleichungslöser für dünn besetzte Systeme [intro_solvers(3S)]

Applikationen

MARC/Mentat 200X

MARC und Mentat sind in aktuellen Versionen in /local/marc/ installiert und können mittels
/local/bin/marc200X bzw. /local/bin/mentat200X
aufgerufen werden (X = je nach installierter bzw. benötigter Version).

Externer Link:  MATLAB

MATLAB ist in /local/matlab/ installiert und kann mittels
/local/bin/matlab
aufgerufen werden.

Tools

GNU Tools

In /usr/gnu/bin sind einige bekannte freie Tools installiert. Die gebräuchlichsten davon sind gmake, gawk, less, tar, emacs. Auch das ls-Kommando ist vorhanden, wobei GNU ls Files über 4 GByte Länge nicht korrekt anzeigen kann.

GNU-Compiler

GCC 3.x

In /usr/freeware/bin ist der GNU-Compiler "gcc" in Version 3.x installiert. Dieses Paket umfasst sowohl den C- als auch den C++- und den Java-Compiler. Um die Manpages zu bekommen, sollte der Pfad /usr/freeware/catman in MANPATH enthalten sein. Antworten auf häfige Probleme finden sich in /usr/freeware/relnotes/gcc.html.

Offizielle SGI-Dokumentation

Die komplette Sammlung der wichtigsten offiziellen Dokumente von SGI zu Compilern, sonstiger Software und Hardware kann in der Externer Link:  SGI Techpubs Library eingesehen werden.

Letzte Änderung: 13. Maerz 2012, Historie

zum Seitenanfang

Startseite | Kontakt | Impressum

RRZE - Regionales RechenZentrum Erlangen, Martensstraße 1, D-91058 Erlangen | Tel.: +49 9131 8527031 | Fax: +49 9131 302941

Inhaltenavigation

Zielgruppennavigation

  1. Studierende
  2. Beschäftigte
  3. Einrichtungen
  4. IT-Beauftragte
  5. Presse & Öffentlichkeit