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.

Seit Juni 2001 ist am RRZE eine Maschine der 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:

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:

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:

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

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:

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:

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:

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)]):

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 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:

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

Message Passing mit PVM

Auch 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 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

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:

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).

#!/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 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 2³¹ 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).

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 SGI Techpubs Library eingesehen werden.

Letzte Änderung: 13. Maerz 2012, Historie