Kautz - SiCortex SC5832 Aktuelles (news) Allgemeines Hardware (972 Knoten mit MIPS64-6Core, 4GB) Software (Gentoo Linux) Zugang/Ansprechpartner Termine/Infos/Planung Anwender/Projekte Probleme Aktuelles: 07.10.09 Bitte vermeiden Sie Out-Of-Memory und Full-/tmp Situationen 01.11.17 Ausserbetriebnahme (taken offline)

Rechnersystem-Kurzbeschreibung

Mit der Installation einer SC5832 der Firma SiCortex im Januar 2009 steht den Nutzern unserer Universität ein massiv paralleler MPI-Rechencluster zur Verfügung. Die Kautz ist für spezielle Anwendungen mit hohen Anforderungen an Kommunikations- und Compute-Leistungen bestimmt.

Hardware

• Für Anwendungen mit hohen File-I/O kann eine RAM-Disk angelegt werden, um die Anwendung zu beschleunigen. Z.B. erreicht ein System mit 40 RAM-Diskknoten (80GB) beim Lesen von 256 Files summarisch etwa 12GB/s. Bitte wenden Sie sich in diesem Fall an den Administrator.
• Paper zur effizienten Teilung des Kautzgraph in Subgraphen:
  W. Taylor, J. Leonard, L.C. Stewart: "Efficient tilings of de Bruijin and Kautz graphs", arXiv:1101.1932v1 [cs.DC] 10Jan2011 (MIT-CTP-4202)
• ieee08-paper N.Godiwala, J. Leonard, M. Reilly: "A Network Fabric for Scalable Multiprocessor Systems" 2008 IEEE

weitere Informationen finden Sie unter: wikipedia/SiCortex, www.SiCortex.com (Insolvenz 2009, offline seit 2010), sowie www.Megware.de/de/cluster/computecluster/sicortex/(offline seit 2011), Datasheet (PDF)

Systemsoftware, Kommerzielle Software

• Gentoo Linux
• MPICH2, gnuc, pathscale compiler
• scmpi, blas, lapack, blacs, scalapack
• 128bit long double (1e-34 statt 1e-19(96bit),1e-15(64bit))
• Jobsystem: slurm
  • Policy: FiFo + BackFill (Backfill-Jobs muessen in die Restlaufzeit aller laufenden Jobs passen, 2012-06)
  • Grosse Jobs (Zielgruppe) werden ggf. gegenueber kleinen Jobs bevorzugt, kurze gegenueber langen
  • Kurzbeschreibung jobfile job.sh

  #!/bin/bash
  # srun-options:
  # -K = kill job if a task does exit with nonzero value
  # ACHTUNG: please use maximum 3GB/node to avoid system crashs! (2012-06)
  # --cpus-per-task=1 --task-mem=500  =  500 MB/task * 6 tasks/node = 3.0 GB/node
  # --cpus-per-task=2 --task-mem=1000 = 1000 MB/task * 3 tasks/node = 3.0 GB/node
  # --cpus-per-task=3 --task-mem=1500 = 1500 MB/task * 2 tasks/node = 3.0 GB/node
  # --cpus-per-task=6 --task-mem=3000 = 3000 MB/task * 1 tasks/node = 3.0 GB/node
  # in case of less than 6 tasks/node think about sharing nodes (option -s)
  # please always define number of nodes, p.e. -N 3-7, MinNodes will be used else
  #
  echo -n "JOBID=$SLURM_JOBID NNODES=$SLURM_NNODES NPROCS=$SLURM_NPROCS"
  echo    " MEM=$SLURM_TASK_MEM WTIME=$SLURM_TIMELIMIT"
  echo "NODELIST=$SLURM_NODELIST"
  echo "job-class=partition= $(squeue -j $SLURM_JOBID -h -o \"%P\")"
  #
  # *** next line is for your parallel-job ***
  srun -K --cpus-per-task=1 --task-mem=500 ./a.out # mpi-executable
  # 
  # output some job-infos:
  # job[step]id,  begintime,  time=d-hh:mm:ss, nnodes, ntasks, CPUs, lnodes
  squeue -j $SLURM_JOBID -o "%.7i %.14b %.11M %.6D %.6C %n"
  

  • Kurzbeschreibung Job-Kommandos
  
# MPI Job abschicken (6*150=900 cores), max. 18 h
sbatch -p scx-comp --nodes 50-150 --time 18:00:00 job.sh
# MPI big Job abschicken (6*950=5700 cores), max. 48 h
sbatch -p big --nodes 950-950 --time 48:00:00 job.sh
# MPI Job abschicken (200-400 Nodes), max. 80 min
sbatch -p scx-comp --nodes 200-400 --time 01:20:00 job.sh
# bitte immer eine max. Zeit vorgeben, sonst Verkuerzung der Laufzeit moeglich
# Langlaeufer ab z.B. 4h werden durch zyklische Aenderung von MaxTime ggf. seltener gestartet
# Kurzlaeufer werden dadurch priorisiert
# Luecken werden nur mit Jobs gefuellt (back-fill), die auch in die Restlaufzeit aller laufenden Jobs passen
sinfo # Knoten- und Partitionsinformationen
squeue -l # Jobliste anzeigen
scancel JOBNUMMER # Job loeschen
scontrol show partitions # alle Queue-Limits anzeigen
scontrol show jobs # alle Jobeigenschaften anzeigen


• Achtung: kein Backup der Nutzerdaten!
• Achtung: bitte aus Ruecksicht auf andere Nutzer (FiFo) nur wenige (1-3) Big-Jobs einstellen!

Zugang/Ansprechpartner

Der Zugang erfolgt aus der UNI-Domain über ssh kautz.urz.uni-magdeburg.de (141.44.8.32) mit Public-Key. Wenn Sie Windows und Excced für den Zugang (grafisch) benutzen, beachten Sie bitte die Konfigurationshinweise des URZ. Accounts können im Kontaktbüro des Rechenzentrums beantragt werden.
Füllen Sie dazu bitte Formular A aus.

Bitte beachten Sie, dass unsere Computeserver nicht der Aufbewahrung von Daten dienen. Deshalb sind die Plattensysteme nur teilweise mit Redundanz ausgestattet und auf Backups wird zugunsten von Performance und Stabilitaet verzichtet. Sichern Sie bitte selbst Ihre Resultate zeitnah und entfernen Sie angelegte Dateien, um anderen Nutzern genug Speicher fuer deren Rechnungen zur Verfuegung stellen zu koennen. Danke! Für Fragen und Probleme wenden Sie sich bitte an mailto:Joerg.Schulenburg(at)URZ.Uni-Magdeburg.DE?subject=WWW-Kautz oder Tel.0391-67-58408.

Termine/Infos/Planung:

 19.01.09 - Lieferung (Fotos) + Inbetriebnahme der SC5832
 29.01.09 - MPI-Benchmark Vergleich (mpi_stress.c from SpinPack)
 03.02.09 - Lustre FS rekonfiguriert
 21.02.09 - Lustre Stabilitaetsprobleme, kein login moeglich (Fehlkonfiguration)
 03.02.09 - 6*dd und IOR-2.10.2 erreicht max. 1080MB/s (6 Streams on OST_00..05)
            bei mehr Streams 400-800 MB/s (summarisch)
 05.03.09 - 400 Nodes down durch Nutzer (srun ... srun), kill + slurmd restart
 08.03.09 - Ausfall Lustre FS /home, 11:11 reboot!
 09.03.09 - Lustre auf TCP via SC-Fabric umgestellt, stabiles Lustre (/home = 150MB/s)
            m20n13-tx2=disabled (possible trigger of lustre bugs)
 19.03.09 - Erfahrungsbericht (pdf) beim Treffen des ZKI Arbeitskreis Supercomputing
 31.03.09 - Ausfall Lustre FS /home (?), 15:00 reboot
 07.04.09 - System down for maintenance, board m20 replaced (reboot)
 17.04.09 - head node crashed, head node rebooted, jobs not affected
 22.04.09 - Einweihung (Talks: T. Blum, J. Schulenburg, H.-W. Meuer, J. Richter, L. Tobiska, G. Janiga)
 03.05.09 - 17:11 Ausfall Temperatursensor msp1.PoL_11 + shutdown, 05.05. Board getauscht
 05.05.09 - LustreError on head-Node, head-node rebooted, jobs not affected
 08.06.09 - IO-node m10n1 hanging
 10.06.09 - LustreErrors (/lustre, /lustre1, 3.6. m11n26+m17n13 + 9.6. m17n13 fabricd errors) - reboot 
 15.06.09 - LustreErrors (/lustre1, 13.6. fabmon errors at m23n10) - reboot
 18.08.09 - LustreErrors (fabmon errors 16.6.+17.08. 23:22 m17n13,m21n9, 22.6. m11n26) - reboot + stress test
 20.08.09 - 04:26 new fabmon-errors on m17n13,m21n9 (m0n1?) (2 nodes disabled) ca. 16:00 reboot + stress test
 22.08.09 - 06:00 Ausfall Klimaanlage (Power off bis Montag 24.08.09)
 22.09.09 - reboot node m17n0, dead lustre client (caused by bit-errors?)
 09.10.09 - 2bit-Memory-Error on scx-m17n0 explored (Node disabled)
 16.11.09 - reboot machine (Lustre inkonsistent)
 29.11.09 - ca. 17:00 Ausfall Klimaanlage (Power off)
 12.12.09 - Ausfall Node m29n8 ECC Error (am 18.12. auskonfiguriert)
 13.01.10 - 18:00 Ausfall Klimaanlage (Wasser-Rueckkuehlung)
 08.03.10 - 13:30 Connection timed out to m29n18, L2 CSW ECC Error, Jobs crashed
 17.06.10 - 20:00 Ausfall Klimaanlage + Notabschaltung
 25.07.10 - 02:16 Crash Node m24n18 Error: "ICE9-dma"
 04.09.10 - 18:45 Crash Node m24n18 Error: "ECC" (6.9. reboot + set down)
 06.09.10 - 2bit-Memory-Error on scx-m24n18 explored (Node disabled) 
 08.09.10 - Crash Node m34n26 Error: "ECC" (set down) + Job6339 crashed
 13.09.10 - 08:50 maintenance - test stability at 633 MHz
            (Test-Ergebnis: m34n26=stabil, m17n0,m24n18=2-bit-errors)
 21.09.10 - kernel panic m10n1 (unused IO-node, reboot m10n1 on 11.10.)
 13.10.10 - kernel panic m10n1 (unused IO-node, PCI-Probleme, reboot m10n1)
 13.10.10 - partitionsparameter angepasst (MaxTime=15d zur Schadensbegrenzung)
 08.11.10 - ca. 14:47 Ausfall m17n13 unknown reason ... ??? (full reboot)
 11.11.10 - crash m29n8 Error: "ECC" (reboot m29n8 + set down)
 14.11.10 - crash m10n1 (unused IO-node, reboot m10n1)
 23.11.10 - node m10n1 + m34n26 crashed, boot problems ... bad RAM m34n26
 25.11.10 - Board m34 getauscht
 06.12.10 - crash m10n1 (unused IO-node)
 09.12.10 - 21:30 Job 6611 (n=6*250) crashed (Bus error), no reason found
 18.12.10 - 03:48 USV meldet Kurzschluss, Hauptsicherung ausgeloest, OFF
 20.12.10 - 09:15 48V*100A Netzteil (1 von 6) ausgefallen, getauscht
 26.03.11 - Ausfall Lustre, Reboot
 27.05.11 - ab 14:00 Abschaltung wegen Arbeiten an der Klimaanlage (bis max. Montag)
 10.06.11 - 146GB-HD des RAID-5 am SSP getauscht (Predictive Failure)
 23.01.12 - 4 Nodes ausgefallen (m16n20,m20n10,m21m17,m25n24 not_reachable)
            bisher laengste uptime von 967 nodes fuer ca. 6 Monate
 25.01.12 - seit ca. 14:00 Probleme mit Lustre (kein login, timeout)
            2*reboot, Problem mit Timer CPU2 m21n17, node deaktiviert
 27.04.12 - partition (queue) modifiziert, scx-comp bis 100 Nodes, neu: big
            um grossen Jobs zeitweise eine bessere Chance zu geben
 16.05.12 - neue fill-partition "short" max. 4h (oder weniger)
            alle Partition-MaxTimes werden zyklisch geaendert, so dass
            Kurzlaeufer (z.B. 4h) schneller drankommen,
            Langlaeufer kommen seltener zum Start
            (z.B. kommt ein 10d Job erst nach etwa 10d seine Chance)
 05.06.12 - system bugs bezueglich OOM+malloc entdeckt (Jobkills+NodeCrashs)
            overcommit_ratio = 98 (-70MB, 100 causes OOM by memeater + scfab)
 07.06.12 - temporary full lustre-FS (user jobs)
 08.06.12 - reboot to clear nodes, set overcommit_ratio = 95 and
            activate sbatch/srun-wrapper scripts to limit memory/task + time
 11.06.12 - 100%CPU durch verklemmten "node_clock_agent" belegt,
            Prozesse fuer ca.3 Tage ca. 50* langsamer, Agent gekillt
 12.06.12 - Datenverlust (genullte Bereiche) im user-job-logfile (lustre)
          - Probleme Disk6 im RAID5-Verbund waehrend mkfs m2n1:/dev/sdc
          - Folgeprobleme mit Lustre, OOM auf m2n1 durch LustreServer? etc.
 13.06.12 - wiederholt verklemmte Promise VTrak E310f (FC-RAID) Firmware (kein Zugriff mehr)
          - Fehlfunktion des VTrak RAID (Drive offline, Spare springt nicht an)
          - 17:17 VTrak: Spare nach Resets + Plattenwechsel doch angesprungen
            und nach RAID5-Rebuild + Lustre restart Betrieb stabilisiert
 19.06.12 - power off um msp19 + msp31 fuer reboot wiederzubeleben, Jobs weg,
            home-filesystem lustre durch nfs ersetzt (robuster? ggf. Datenverluste!)
 09.07.12 - m25n24 mit ECC-Fehlern abgestuerzt, auskonfiguriert (8 nodes down)
 28.08.12 Klimaausfall 3h nach Spannungsdrop 03:43 bis max Tn+29C ohne Ausfall
          logs: WARNING: TIMEOUT on scx-msp$m MspEnv_Power_Pol_$n: ... (30GB/d)
 01.09.12 Ausfall m19n6, 10.09.12 Ausfall m7n14 (Nachwehen? reboot geplant)
 13.09.12 booten hing, deshalb master neu gestartet, jobs geloescht
 15.10.12 Ausfall 146GB-HD des RAID-5 am SSP (Platte ersetzt)
 28.11.12 20:56-22:24 Ausfall Node m19n8 (Ursache unklar, Core#4 haengt?, 13.12.)
 13.06.13 slurm durch OOM instabil?  Nodes m21n1,2,5,... disconnected
 14.06.13 15:30 reboot cluster (failed!), power off/on
 18.06.13 m35n10 nicht per JTAG/I2C erreichbar, Board m35 getauscht
          RAMs m24n18 m16n20 m17n0 mit Bitflips und sporadischen L2-ECC-Crashs
          m24n18,m17n1 wandert mit zu n8,n1 und wurden getauscht
          weitere RAM-Tests (OOM fuehrt zu slurmd und sshd crashes)
 19.06.13 weitere RAMs getestet und getauscht (CEs m3n11 m12n7 m29n13 m19n20 m4n23 m25n24 m19n15)
 20.06.13 weitere RAMs getauscht (CEs m29n8 ...)
 21.06.13 keine weiteren ECC-Fehler bei memtest, Normalbetrieb ab ca. 12:00
 23.06.13 08:42 correctable ECC-Error (CE) on m19n8 (was m19n15), no action
 29.06.13 10:25 correctable ECC-Error (CE) on m17n8, no action
 12.07.13 11:06 correctable ECC-Error (CE) on m12n8, dma-errors
 08.08.13 Austausch RAMs m19n8 und m12n8, testtausch m10+m12 wegen m10n1
 26.08.13 02:30 Crash m14n20        (Ursache unklar, reboot node)
 21.10.13 08:00 kernel panic m10n17 (Ursache unklar, reboot node)
 21.12.13 23:00 Klimaprobleme im Serverraum,  set queue big down (less heat)
 04.02.14 14:27 Ueberlastung NFS (?), OOM@m2n1, 5 Knoten aufgehaengt (5*reboot) 
 08.02.14 00:50 Absturz node m22n23 (Ursache unklar, warmboot 12.02.)
 03.03.14 Ausfall node m24n7 und m27n14 (bleiben bis reboot offline)
 18.09.14 unerwarteter I/O-error m11n19 im Anwenderprogramm, reboot geplant
 19.09.14 Fr-Di System boot bleibt beim module (scfab,scio,sceth) laden haengen
 25.09.14 Fehler gefunden: m11n19 hat defekte Bits im L2-cache bemerkt, auskonfiguriert
 20.04.15 8ter Knoten m2n1 mit nfs ausgefallen (Folge?), RAM-Tausch m11n19
          2h-Diagnose + RAM-Tausch m15n13 m25n18 m13n4 m0n21 + Diagnose 3h
 21.04.15 RAM-Tausch m17n8 m29n17 m4n8 m15n13 + neuer Diagnose-Lauf(3h)
          18 getauschte DIMMs von 1864 2GB-ULV-DDR2-DIMMs in 6 Jahren (1% Ausfallrate)
          m15n13 hat L2-Bitfehler im Diagnose-Test auch nach DIMM-Tausch (set down)
 12.10.15 m17n13 sc-Netzwerkproblem (link: m17n13-rx0 - m21n9-tx2)? warmboot hilft nicht
 13.10.15 Folgeausfall komplettes sc-Netzwerk 
          reboot fails mit ECC-Fehlern auf m10n16, DIMMs m10n16+m16n12 getauscht
 14.10.15 diagnose-run 8h, 3 nodes mit ECC-Problemen, 1 instabiler Link
 15.03.16 reboot, NFS-node hatte nach 8 Tagen parallel file-read Out-Of-Memory (5700 tasks)
 13.06.16 login problems, new (pedantic) network router, bad netmask corrected
 26.07.16 node m2n1 (nfs-server) crashed (CPU-Error+kernel-panic), reboot
 26.09.16 1 of 2 power units defect (power redundancy lost), ok after replug
 20.10.16 Teilausfall Rueckkuehlung + Bedampfung (30C, 30% RF WL), jobs suspended
 06.12.16 22:00 Ausfall Kaltwasser der Klimaanlage (auto-shutdown 02:13 38C)
 22.12.16 17:15 breakdown board 34 incl. network, trying reboot
 11.02.17 Out-of-Memory on master (up=881days, slapd=2.5GB), plz send an email if nodes show problems (full reboot required)
 09.03.17 m4n5 lot of ECC-errors, /var/log 100% filled, node configured out
 18.08.17 Stromausfall durch Abschaltung (statt Bypass) ueberhitzter USV,
          Klimatisierung der USV durch Nager stillgelegt,
          Probleme mit Board34 beim wiedereinschalten
 01.11.17 Ausserbetriebnahme
 

Projekte:

• SpinPack - Quantenspinsysteme, exakte Diagonalisierung, spezifische Benchmarks
• CCCM - Quantenspinsysteme, Coupled Cluster Method
• Strömungsmechanik
• Benchmarks (preprint/pdf) der AG Numerische Simulation, Optimierung und Hochleistungsrechnen (KIT - Karlsruher Institut für Technologie), 2009
• Simulationen von molekularen Strukturen auf Oberflächen von Festkörpern und deren Eigenschaften (Struktur, Dynamik, Reaktivität), Methoden: Quantenchemie-Codes wie Car-Parinello molecular dynamics/Dichtefunktionaltheorie für periodische Strukturen und Dalton ( Institut für Chemie (ICH), FVST, Uni Magdeburg, Aug. 2009)
• Tests mit eigenem Finite-Elemente-Code MooNMD (IAN/FMA, Okt. 2009)
• MonteCarlo-Simulationen (Phototaxis of Halobacterium salinarum) Nov. 2009
• Bild-Simulationen zu Rastertunnel- und Rasterkraftmikroskopie mit Quantum-Expresso der FVST - Institut fuer Chemie (ICH) Jul. 2011
• "Wieviele Löcher verträgt der Schweizer Käse?" Berechnung der Perkolationsschwelle in kontinuierlichen Systemen. ITP Okt. 2011
• "Multi-phase and multi-reactive flows through complex geometry caused by fire involving radioactive materials", Institut fuer Apparate- und Umwelttechnik (FVST-IAUT) using OpenFOAM, Mai 2013
• LABS (Low autocorrelated binary sequences) - Problems (ITP) 2015

Probleme:

• - wiederholt Ausfaelle der Lustre-FS ausgeloest durch (temporaere?) HW/Link-Ausfaelle (s. Termin/Info-Liste), spaeter ersetzt durch NFS (langsamer)
• - Node-Crashs durch OOM trotz abgschaltetem overcommit_memory, (wegen zusaetzlicher race condition fuer malloc schwer zu verhindern, fork+malloc, _ratio=95 statt 100 reduziert OOM-Problem mit malloc + scfab), memaeter + scancel fuehrt aber trotzdem immer zu slurmd-crashes, da slurmd dynamisch user-memory benoetigt (Designschwaeche!? moeglicher slurmd-fix: kmemory, genug reservememory oder kein dyn. Memory fuer essentielle Funktionen)
• - Memory bitfehler verhindern teilweise booten des ganzen Clusters, weil scnet nicht startet, moeglicherweise auch scnet-Ausfaellte durch RAM-bitfehler getriggert (ToDo: fallback-function zu langsamen msp-network), ECC-Fehler erscheinen in edac/dma/dma0/ce_count und edac/cpu/cpu0/ce_count, nicht bei edac/mc/mc0/ce_count. cpu/panic_on_ue muss fuers (panic-freie) counting disabled sein.
• - die MIPS-CPU scheint beim parallelen lesenden(!) Zugriff der CPU-Cores auf gemeinsamen Speicher den L1-Data-Cache zu invalidieren, was zu erheblichen Performanceeinbussen fuehren kann. Ausschliessliche Nutzung Thread-lokalen Speichers umgeht das Problem. Alternativ kann Knoten-internes MPI benutzt werden, was aber bei Nutzung aller Knoten i.d.R. (wegen der kleineren Datenpakete) schlechter skaliert. Normalerweise tritt ein solches Problem nur bei schreibenden Zugriffen auf den gleichen oder dicht benachbarten Speicher statt (false sharing, selbe Cache-line).

Weitere HPC-Systeme:

IB-Cluster t100(2016), HP GS 1280 marvel(2003-2009), 8-Wege-QuadOpteron meggie(2009), der kleine Bruder SC072-PDS asgard(2009), ISUT-Cluster comp2,
weitere Infos zu zentralen Compute-Servern im CMS

Author: Joerg Schulenburg, Uni-Magdeburg URZ, Tel. 58408 (2009-2015)