Category Archives: Hardware, Treiber

Beiträge zu der von mir eingesetzten Hardware

SSD Raid Arrays unter Linux – I – ein facettenreiches Thema

Posted on by

Ein neues Test-System bietet eine gute Gelegenheit, neue Technologie unter Linux auszuprobieren. In diesem Fall einen SSD-Raid-Verbund. So etwas mache ich natürlich nicht nur zum Vergnügen. Mein eigentliches Ziel ist es, Berechnungen eines Kunden, die auf Daten einer oder mehrerer MySQL-Datenbanken mit Tabellen mit bis 20 Millionen Datensätzen zurückgreifen, für die HW eines kleineren Standalone-Servers zu optimieren. Dabei sollen die Raid-Arrays auf ein bestimmtes Lastverhalten und andere Faktoren hin optimiert werden. Ich habe dabei doch ein paar Überraschungen erlebt.

Bzgl. SSDs hat sich in den letzten Jahren ja viel getan; die aktuellen SSDs sind schneller, die preislich erschwingliche Kapazität ist deutlich größer geworden. Am wichtigsten ist aber, dass sich die Haltbarkeit verbessert hat. Das ist für kleinere Unternehmen durchaus ein Punkt. Der Austausch von mehreren SSDs kostet ja nicht nur Geld, sondern auch Betriebsausfallzeiten und ggf. Aufwände externer Administratoren.

Diese Artikelserie ist für Leute gedacht, die sich dem Einsatz von SSD-Arrays im privaten Bereich oder aber in kleinen Unternehmen annähern wollen – und dabei sicher über einige grundlegende Fragen stolpern. Wir betrachten also SSD-Raid-Arrays in Linux-Workstations oder kleineren Linux-Servern. Dabei fassen wir auch den Einsatz von SATA3-Onboard-Controllern ins Auge – für Intel Chipsätze wie den Z170, dessen Sunrise-Point-Controller und Intels zugehörige, sog. “iRST”-Technologie.

In einem Linux-Blog ist vor allem auch der Einsatz von Linux-SW-Raid-Arrays von Interesse. Viele der in den kommenden Artikeln getroffenen Feststellungen zu Linux-SW-Raids gelten dabei ganz unabhängig von der Anlagengröße oder dem verwendeten SATA/SAS-Controller.

Raid mit SSDs – ein facettenreiches Thema

Warum will man überhaupt SSD-Raid-Arrays einsetzen? Typische Motive sind: Eine Verbesserung der Ausfallsicherheit und Performanceverbesserungen über das Leistungsvermögen einer einzelnen SSD hinaus.

Nach meiner Meinung sollte man diese Punkte jedoch gut hinterfragen, bevor man unbedarft Geld in die Beschaffung mehrerer SSDs steckt. Im Besonderen sollte man nicht auf Werbeversprechen, die mit sequentiellen Lese- und Schreibraten argumentieren, hereinfallen. Ferner gibt es (nicht nur unter Linux) einige weitere Punkte zu beachten:

  • Kann man für kleinere Server Mainboard-Sata-Controller nutzen? Oder ist ein Griff zu HW-Controllern schon aus Performancegründen unumgänglich?
  • Bietet der Einsatz spezieller Technologie (wie etwa Intels iRST; s.u.) für einfache Mainboard SATA3-Controller Vorteile gegenüber nativen SW-Raid-Verfahren unter Linux?
  • Will man das System aus einem Raid-Array heraus booten? Geht das überhaupt?
  • Wie sieht es mit dem Verschleiß der SSDs aus? Hat die Art des Raid-Systems darauf einen Einfluss? Lässt sich der fstrim-Befehl für Partitionen auf Raid-Arrays absetzen?
  • Von welchen Faktoren und Konfigurationsparametern hängt die Performance eines Linux-SW-Raid-Arrays ab?
  • Kann man den Standardeinstellungen vertrauen, die manche Linux-Installer für die Konfiguration von Raid-Arrays anbieten?

Arbeitet man sich in die Thematik ein, so merkt man schnell, dass das Thema “SSD-Arrays” eine Wissenschaft für sich ist. Und dann stößt man z.T. auch auf wirklich widersprüchliche Hinweise im Internet:

Das schlimmste Beispiel sind Artikel zur sog. Chunk-Size eines Arrays. Da werden von Administratoren mal möglichst große Chunk-Sizes im Bereich von 2 MB empfohlen, während andere möglichst kleine “Chunk Size”-Größen zwischen 8 und 32 KB empfehlen. Jeweils natürlich mit unterschiedlichen Begründungen, die vom Leser
selten zur Deckung gebracht werden können. Es kommt dann die Frage auf, ob die jeweiligen Autoren nicht implizite Annahmen bzgl. bestimmter Lastprofilen gemacht haben …

Ich habe nun mehrere Tage mit eigenen Tests und Informationsbeschaffung verbracht – erst jetzt hat sich ein Vorgehensmodell herauskristallisiert. Ich werde mir dabei aus guten Gründen Reserven für weitere datenbankspezifische Experimente offen lassen. Inzwischen habe ich immerhin einige Erkenntnisse gewonnen, die auch anderen helfen können, wenigstens ein paar essentielle Fehler und eine unkritische Übernahmen von Empfehlungen zu vermeiden.

Verfügbare Ressourcen auf dem neuen Test-System

Mein neues Testsystem hat folgende Ressourcen:
i6700K-CPU, 64 GB RAM, 4 Raid10 HDDs mit HW-Controller, 1 rel. teure SSD 850 Pro, 4 relativ kostengünstige SSDs 850 EVO.

Das Z170-Mainboard weist einen onboard Intel Z170-SATA3-Controller (Sunrise Point) auf, der mit Intel Rapid Storage Technologie [iRST] betrieben werden kann. Es handelt sich dabei um eine Lösung von Intel, die eine (Vor-) Konfiguration von Raid-Platten-Verbänden bereits im BIOS zulässt. Ich spreche in den kommenden Artikeln kurz vom “iRST-Controller”, wenn denn iRST im BIOS aktiviert ist.

Was ist das vorläufige Zwischenergebnis nach etlichen Tests?

Um den Leser einen Vorgeschmack zu geben, hier ein paar vorläufige Entscheidungen:

  1. Ich habe eine klare Entscheidung für Linux-SW-Raid getroffen und gegen den Einsatz von iRST getroffen. Weniger aus Performance-Gründen, als vor allem aus Gründen der Flexibilität. Auf iRST werde ich ganz verzichten; die Platten werden BIOS-seitig im reinen AHCI-Modus angesprochen.
  2. Es werden hauptsächlich Raid-10-Arrays und keine Raid-5-Arrays zum Einsatz kommen. Dies ist eine fundamental wichtige Entscheidung! Sie ist primär dadurch motiviert, die SSDs zu schonen. Raid 10 ist hinsichtlich Plattenplatz teuer – aber das erscheint mir im Vergleich zur Plattenabnutzung nach meinen bisherigen Erfahrungen ein relativ kleiner Preis zu sein.
  3. Ich werde das Betriebssystem (OS Suse 42.2 und alternativ Debian) nicht auf einer Partition des Raid-Systems selbst aufsetzen – und wenn doch, dann nur zu Testzwecken, aber nicht zum produktiven Arbeiten.
  4. Ich werde die Raid-Erstellung nicht halbautomatisch über YaST, sondern manuell vornehmen. Hierfür gibt es einen guten Grund, den ich in einem kommenden Artikel erläutern werde.
  5. Bzgl. des Partition-Alignments werde ich dagegen nach vielen manuellen Checks Opensuses’ YaST bzgl. dessen Alignment-Algorithmen vertrauen.
  6. Insgesamt werde ich auf den SSDs ca. 12% Plattenplatz ungenutzt lassen. Das ist teuer, aber bzgl. des Verschleißes eine Vorsichtsmaßnahme.

  7. LVM wird zum Einsatz kommen; die logischen Volumes werden mit guten Reserven bzgl. des eigentlichen Platzbedarfes angelegt.
  8. Ich werde mir die Option für mehr als 2 Raid Arrays auf ein und demselben Plattenverbund offen lassen. Für echte Hochperformance-Aufgaben werde ich kleine Raid-5-Arrays weiter austesten.
  9. Für weitere intensivere Applikations- und Datenbanktests werde ich mindestens 2 Raid-Arrays mit ganz unterschiedlichen Raid Chunk Sizes, nämlich 512KB bzw. 32KB verwenden. Die Chunk Size hat sich als ein essentieller Parameter für eine gute Performance erwiesen.
  10. Bzgl. der endgültigen Wahl der Chunk Size gibt es gleich mehrere Aspekte zu beachten – u.a. die Art der Last: Random I/O? Kleine Blocksizes? Viele parallele und konkurrierende Prozesse mit Plattenzugriff oder eher
    zeitlich getrennte Einzelprozesse mit hohen Last-Peaks? Viele separate Zugriffe? Applikationen mit Threading zur Lastverteilung? Auf einem halbwegs ausgelasteten Fileserver wüsste ich jetzt bereits die richtige Wahl; für unsere spezielle PHP/MySQL-Anwendung sind weitere Tests und ggf. sogar eine stärkere Parallelisierung des SW-Algorithmen für mehrere CPU-Cores erforderlich.

Eine wichtige Sache, die ich auch gelernt habe:

Man kann die potentiellen Probleme nicht allein mit einfachen Testtools wie “hdparm -tT”, “dd” für das Lesen und Schreiben größerer Test-Datenmengen mit unterschiedlichen Blockgrößen oder grafischen Tools wie “gnome-disks” erfassen.

Ein Ergebnis wie

irst_raid_ssdroot_20mb_400_from_old_rux

für den iRST ist nicht wirklich aussagekräftig. Tools wie “fio”, die eine differenzierter parametrierte Last erzeugen können, sind wesentlich hilfreicher.

Aber der Reihe nach – in den zunächst kommenden Teilen dieser Miniserie
SSD Raid Arrays unter Linux – II – HW-Controller?
gehe ich zunächst ein wenig auf das Thema HW-Controller ein. Lohnt sich deren Einsatz?

Es folgen dann ein paar Beiträge zum Einsatz von iRST im Vergleich zu nativen SW-Raids.

Danach werde ich mich mit Frage Raid-5 vs. Raid-10 auseinandersetzen. Ein weiterer Artikel zeigt dann, wie man Raid-10-Arrays unter Linux praktisch konfiguriert.

Schließlich werde ich Performance-Daten präsentieren und daraus Schlussfolgerungen bzgl. der Raid-Konfiguration ziehen.

Der eine oder andere praktisch veranlagte Leser wird sich im Gegensatz zu der von mir gewählten Themenfolge vielleicht als erstes auf das Thema einer Anlage und Konfiguration von SW-Raid-Arrays stürzen wollen. Bitte, kein Problem! Ich empfehle vorab eine intensive Auseinandersetzung mit dem “mdadm”-Kommando und seinen Optionen. Siehe zur Einführung etwa

https://raid.wiki.kernel.org/index.php/RAID_setup
https://www.thomas-krenn.com/de/wiki/Software_RAID_mit_MDADM_verwalten
https://www.digitalocean.com/community/tutorials/how-to-create-raid-arrays-with-mdadm-on-ubuntu-16-04
https://linux.die.net/man/8/mdadm
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.advdisk.html#sec.yast2.system.raid

Einen kleinen “Kurs” zu mdadm bietet die Seite
https://www.tecmint.com/understanding-raid-setup-in-linux/.

Firefox – HTML5 – kein Sound bei purem Alsa und Einsatz einer .asoundrc für eine Xonar D2X

Posted on by

Vor etwa 2 Jahren hatte ich in diesem Blog mehrere Artikel zur Einrichtung der Xonar D2X unter Linux – genauer unter Opensuse 13.1 (mit KDE) – verfasst. Ein Fazit war, dass Pulseaudio für diese Karte nicht vernünftig funktionierte. Zumindest dann nicht,

  • wenn man Stereo-Signale auf mehrere Ausgangskanäle upmixen will
  • und wenn man seine relativen Volume-Einstellungen für die verschiedenen analogen Ausgangskanäle nicht ständig bei Lautstärke-Änderungen unter dem Mixer von “pavucontrol” verlieren will.

Die Karte selbst nimmt keinen Mix auf N.1-Ausgabe-Systeme vor; das direkt unterstützte Mixing blendet den Center und Bass-Speaker aus.

Die Xonar D2X läuft bei mir inzwischen unter Leap 42.1. Dass der Pulseaudio-Layer mit pavucontrol als Mixer trotz diverser optischer Aufbesserungen inzwischen besser mit Mehrkanalkarten umgehen könne, sehe ich nicht. Ich bleibe dabei: Pulseaudio schafft mehr Probleme als es löst. Das liegt weniger an der Idee eines auf Alsa und anderen Soundsystemen aufsetzenden Zwischenlayers als an der schlechten Umsetzung dieses Layers für verschiedene Karten – im besonderen Multikanal-Karten. Problematisch ist dabei, dass für eine evtl. mögliche Reproduktion der Mixing- und PCM-Plugin-Optionen von Alsa unter Pulseaudio aus meiner Sicht erhebliche Detailkenntnisse von Pulseaudio erforderlich sind. Ganz schlimm wird es nach meiner Erfahrung dann, wenn das System mehrere Multikanal-Soundkarten enthält.

Im letzten meiner Artikel zur D2X
Asus Xonar D2X unter Linux / Opensuse 13.1 – III – Alsa Upmix 2.0 auf 5.1
hatte ich eine Muster-Datei “~/.asoundrc” für das Upmixing von Stereo-Eingangssignalen angegeben und die völlige Deaktivierung von Pulseaudio empfohlen. Über die “.asoundrc” wurde auch ein SW-Volume-Regler angelegt, um für alle Quellen und über alle Output-Kanäle der D2X hinweg die Lautstärke regeln zu können, ohne die relative Laustärke-Gewichtung der Kanäle zueinander zu verändern.

Probleme mit Firefox und mit KDE5

Leider verlassen sich offenbar immer mehr Entwickler auf ein laufendes Pulseaudio – so schlecht das auch sein mag. Das führt dann bei denjenigen, die aus guten Gründen nur mit Alsa arbeiten wollen, zu mehr oder weniger großen Problemen. Ein schlimmer Bug ist aus meiner Sicht der, dass z.B. unter KDE 5 (unter OS Leap 42.1) von bei mir über 20 verfügbaren HW und virtuellen PCM Alsa-Devices nur noch genau eines angezeigt wird, wenn Pulseaudio deaktiviert ist (s. https://bugs.kde.org/show_bug.cgi?id=362476). Dennoch sind die Devices da und aktiv – wie etwa die Device Übersichten unter Amarok oder VLC beweisen.

Richtig übel wurde es aber, als Firefox [FF] plötzlich keinen Sound mehr ohne Pulseaudio zu liefern schien.
Auch ein Leser, der meinen Vorschlägen aus dem oben genannten Artikel gefolgt ist, ist nun über dieses Problem gestolpert, dass auch mich schon seit einiger Zeit geplagt hat:

https://wiki.gentoo.org/wiki/ALSA und dort den Bereich “Troubleshooting” oder auch https://bbs.archlinux.org/viewtopic.php?id=186650.

Bei mir dagegen war das Problem mit FF anders gelagert. Vielleicht helfen die nachfolgenden Ausführungen deshalb auch dem einen oder anderen Leser weiter, der sein Firefox-Problem bislang nicht lösen konnte.

Ausgangssituation mit der Xonar D2X als primärer Soundkarte

In meinem aktuellen Arbeitsplatzsystem befinden sich mehrere Soundkarten. Ich befasse mich in diesem Artikel aber nur mit dem Fall, dass lediglich die Xonar D2X als primäre Karte genutzt wird. Unter Opensuse (in meinem Fall in der Version Leap 42.1) kann man die Grundeinrichtung etwa mit YaST vornehmen:

yast_snd

Mit Hilfe der Funktionalität von YaST’s Sound-Einrichtung deaktivieren wir zudem das Pulseaudio-System mittels entsprechender Optionen unter dem Button “Andere” >> “Pulseaudio-Konfiguration” vollständig. (Unter anderen Linux-Varianten sind zur Deaktivierung von Pulseaudio andere Schritte erforderlich). Danach sichern wir die Einstellungen und starten das System neu.

Die explizite Einrichtung der D2X mittels YaST bewahrt uns ggf. noch nicht zwingend vom Laden weiterer Kernelmodule und Treiber für andere Soundkarten durch udev. Wir müssen daher für die nachfolgenden Alsa-Einstellungen prüfen, an welcher Position die D2X unter den verschiedenen Soundkarten tatsächlich erkannt wird.

Die grundsätzlich verfügbaren Karten zeigen folgende Befehle; die D2X ist u.a. als “C-Media Electronics Inc CMI8788 [Oxygen HD Audio]” unter den PCI-Devices erkennbar. 

me@mysystem:~> aplay -l | grep Karte  
rmo@rux:/proc/asound> aplay -l | grep Karte
Karte 0: D2X [Xonar D2X], Gerät 0: Multichannel [Multichannel]
Karte 0: D2X [Xonar D2X], Gerät 1: Digital [Digital]
Karte 1: PCH [HDA Intel PCH], Gerät 0: ALC1150 Analog [ALC1150 Analog]
Karte 1: PCH [HDA Intel PCH], Gerät 1: ALC1150 Digital [ALC1150 Digital]
Karte 2: NVidia [HDA NVidia], Gerät 3: HDMI 0 [HDMI 0]
Karte 2: NVidia [HDA NVidia], Gerät 7: HDMI 1 [HDMI 1]
Karte 2: NVidia [HDA NVidia], Gerät 8: HDMI 2 [HDMI 2]
Karte 2: NVidia [HDA NVidia], Gerät 9: HDMI 3 [HDMI 3]
Karte 3: XFi [Creative X-Fi], Gerät 0: ctxfi [Front/WaveIn]
Karte 3: XFi [Creative X-Fi], Gerät 1: ctxfi [Surround]
Karte 3: XFi [Creative X-Fi], Gerät 2: ctxfi [Center/LFE]
Karte 3: XFi [Creative X-Fi], Gerät 3: ctxfi [Side]
Karte 3: XFi [Creative X-Fi], Gerät 4: ctxfi [IEC958 Non-audio]

 
und 

root:~ # lspci -nn | grep Audio
00:1f.3 Audio device [0403]: Intel 
Corporation Sunrise Point-H HD Audio [8086:a170] (rev 31)
01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:0fba] (rev a1)
02:00.0 Audio device [0403]: Creative Labs EMU20k2 [X-Fi Titanium Series] [1102:000b] (rev 03)
04:04.0 Multimedia audio controller [0401]: C-Media Electronics Inc CMI8788 [Oxygen HD Audio] [13f6:8788]

 
Nach der Konfiguration der D2X mit YaST und einem Neustart des Systems finden wir unter Opensuse folgenden Eintrag in der Datei “/etc/modprobe.d/50-sound.conf” vor: 

options snd slots=snd-virtuoso
# rChK.j3r564qQSgF:Virtuoso 200 (Xonar D2X)
alias snd-card-0 snd-virtuoso

Wir lassen diesen Eintrag unverändert.

Die aktuell gültige Reihenfolge der Karten ist auch wie folgt erkennbar: 

me@mysystem:~> cat /proc/asound/cards
 0 [D2X            ]: AV200 - Xonar D2X
                      Asus Virtuoso 200 at 0xd000, irq 16
 1 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0xdf640000 irq 146
 2 [NVidia         ]: HDA-Intel - HDA NVidia
                      HDA NVidia at 0xdf080000 irq 17
 3 [XFi            ]: SB-XFi - Creative X-Fi
                      Creative X-Fi 20K2 Unknown

 
Die D2X wird also von ALSA definitiv als erste Soundkarte (mit der Nummer 0) verwendet – was immer udev sonst entdeckt und an Modulen nachgeladen haben mag. Wäre dies nicht der Fall, hätten wir dies in der Datei “/etc/modprobe.d/50-sound.conf” durch Festlegung von “index”-Parameter-Werten für die Module festlegen müssen (s. hierzu etwa https://bbs.archlinux.org/viewtopic.php?pid=1445611#p1445611).

Eine mit Firefox nicht funktionierende “.asoundrc”

Meine ursprüngliche “~/.asoundrc” für diesen Fall sah (etwas verkürzt) etwa so aus: 

pcm.dmix51 {
	type asym
	playback.pcm {
		type dmix

		# Don't block other users
		# http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html
		ipc_key_add_uid true

		ipc_key 5678293
		ipc_perm 0660
		ipc_gid audio

		slave {
			# 2 for stereo, 6 for surround51, 8 for surround71
			channels 6
			pcm {
				# mplayer chooses S32_LE, but others usually S16_LE
				#format S24_LE
				format S16_LE

				# 44100 or 48000
				# 44100 for music, 48000 is compatible with most h/w
				rate 44100
				#rate 48000

				type hw
				card 0
				device 0
				subdevice 0
			}

			#period_size 512
			period_size 1024
			#period_size 512

			# 4096 might make sound crackle
			# mplayer2 chooses 8192. Half-Life 2 chooses 16384.
			# If too large, use CONFIG_SND_HDA_PREALLOC_SIZE=2048
			buffer_size 16384
		}
	}
	capture.pcm "hw:0"
}

ctl.dmix51 {
	type hw
	card 0
}

pcm.upmix {
	type plug
	slave.pcm "dmix51"
	   
	#front
   	ttable.0.0 1
    	ttable.1.1 1

	#side / rear -left
	ttable.0.2 1.0

	#side / rear - right
    	ttable.1.3 1.0

	#center    
    	ttable.0.4 0.5
    	ttable.1.4 0.5

	# bass
    	ttable.0.5 0.2
    	ttable.1.5 0.2
    
}
pcm.!default {
	type softvol
	slave.pcm "upmix"
	control {
	  name "SW master"
	  card 0
	}
}

 
Diese Datei mit ihren verketteten Upmixing-Definitionen (Stereo zu 5.1) und dem initial definierten Softvol-Regler funktioniert für praktisch alles – nur nicht für Firefox!

Den Softvol-Regler hatte ich, wie gesagt, am Anfang der Plugin-Kette angelegt, um den Input für die verschiedenen Kanäle der D2X an einer zentralen Stelle steuern zu können – bei gleichzeitiger
Aufrechterhaltung der relativen Lautstärke-Verhältnisse zwischen den Kanälen. Unter KMIX sieht das dann so aus:

kmix

Den “SW-Master”-Regler kann man dann zum Hauptkanal für die Kmix-Einstellungen machen und damit die Lautstärke über einen (!) Regler auch im Systemabschnitt der KDE-Kontrolleiste anpassen, ohne die relativen Kanal-Lautstärken zu verändern.

Lösungsansatz für das Firefox-Problem

Nach etwas Rumprobieren kam ich schließlich auf den Gedanken, dass Firefox beim Default-Device – also am Anfang der Plugin-Kette für die Sound-Verarbeitung – möglicherweise ein PCM-Device vom Typ “plug” erwartet und mit dem “softvol”-Plugin nicht umgehen kann. Ich habe daher folgende Änderung vorgenommen: 

defaults.pcm.card 0
defaults.pcm.device 0
defaults.ctl.card 0

pcm.dmix51 {
	type asym
	playback.pcm {
		type dmix

		# Don't block other users
		ipc_key_add_uid true

		ipc_key 5678293
		ipc_perm 0660
		ipc_gid audio

		slave {
			# 2 for stereo, 6 for surround51, 8 for surround71
			channels 6
			pcm {
				#format S32_LE
				format S16_LE

				# 44100 or 48000
				# 44100 for music, 48000 is compatible with most h/w
				rate 44100
				#rate 48000

				type hw
				card 0
				device 0
				subdevice 0
			}

			#period_size 512
			period_size 1024
			#period_size 512

			buffer_size 16384
		}
	}
	capture.pcm "hw:0"
}

ctl.dmix51 {
	type hw
	card 0
}

pcm.upmix {
	type plug
	slave.pcm "dmix51"
	   
	#front
    	ttable.0.0 1
    	ttable.1.1 1

	#side / rear -left
	ttable.0.2 1.0

	#side / rear - right
    	ttable.1.3 1.0

	#center    
    	ttable.0.4 0.5
    	ttable.1.4 0.5

	# bass
    	ttable.0.5 0.2
    	ttable.1.5 0.2
    
}

pcm.vol {
	type softvol
	slave.pcm "upmix"
	control {
	  name "SW master"
	  card 0
	 }
}

pcm.!default {
	# !!! 
	type plug 
	slave.pcm "vol"
}

 
(Die ersten Statements dienten nur der Sicherheit, dass in jedem Fall die erste Soundkarte genutzt wird. Mit der D2X funktioniert übrigens auch die Format-Festlegung “format S32_LE”).

Und siehe da:
Die vorgenommene kleine Änderung unter dem “pcm.!default”-Eintrag und das Verlagern des Volume-Reglers in ein eigenes Plugin “vol” brachte den Erfolg! Nach einem Ausloggen aus KDE und erneutem Einloggen produzierten Youtube-Videos unter FF plötzlich Töne – ohne dass ich irgendetwas an der vorherigen Funktionalität für die D2X verloren hätte.

Im Grunde ist durch das künstliche PCM-Device vom Typ “plug” mit dem Verweis auf das slave.pcm “vol” der SW-Volume-Regler nur als ein weiteres separates Glied der PCM-Plugin-Kette definiert worden.

Warum FF im Gegensatz zu anderen Browsern und Soundquellen so sensibel auf unterschiedliche Alsa-Plugin-Typen reagiert, ist mir unklar. Aber im Moment bin ich froh, das Problem wenigstens einer Lösung zugeführt zu haben, ohne Pulseaudio anwerfen zu müssen.

Viel Spass weiterhin mit der Xonar D2X – ohne Pulseaudio !

CPU Kühler Alpenföhn Brocken 2 – Empfehlung für Linux Workstations

Posted on by

ich hatte letzte Woche eine neue Linux-Workstation für eine Kunden aufzusetzen. Dabei kam ein i7-6700K-Prozessor von Intel zum Einsatz. Auf der Suche nach einem passenden Lüfter blieb ich dann beim Brocken 2 (siehe http://www.alpenfoehn.de/cpu-kuehler/brocken-2) hängen; nicht zuletzt aufgrund seines Preises.

Nach ersten Eindrücken möchte an dieser Stelle eine Empfehlung aussprechen:

Ich hatte noch nie so niedrige CPU-Temperaturen in irgendeinem von mir gebauten PC-System ( ca. 32° Celsius CPU-Temperatur im Linux-Normalbetrieb (Lüfter auf 640 U/min; aktive Anwendungen: Libreoffice / Kontact / VMware mit Win7/ 2xKVM mit Linux-Systemen). Im völligen Leerlauf (obwohl es sowas unter Linux ja nicht gibt) erreicht man je nach Umdrehungszahl des Lüfters deutlich unter 26° Celsius; das hängt von der Umgebungstemperatur und in meinem Fall auch von den vorgegebenen Lüfterprofilen des UEFI-Bios ab). Bei leichtem Overclocking und Annäherung an Vollast ergab sich folgendes Bild: 8 CPU-Threads bei 99% führen zu maximal 70&deg Peaks bei ca. 1110 U/min; Celsius bei ca. 22° Raumtemperatur (erreicht durch x-faches Starten von glxspheres).

Der Kühler erfüllt seine Aufgabe also gut – auch wenn man, wie ich, nur die einfache Variante mit einem Lüfter wählt. Der Brocken 2 lässt sich bei Bedarf immer noch auf 2 Lüfter aufstocken.

Aber:
Der Kühler ist mit seinen physikalischen Dimensionen ein wahres Monster! Ich empfehle jedem, die Dimensionsangaben (http://www.alpenfoehn.de/images/Produkte/Abmessungen/AbmessungenBrocken2.pdf)vor einem Kauf genau zu studieren und mit dem Platz im Gehäuse zu vergleichen; die Bauhöhe von 16,5 cm ist mit der Breite des Gehäuses zu vergleichen – und bitte ab CPU-Oberfläche messen! Auch sollte man sich mit dem Abstand des ersten RAM-Steckplatzes vom CPU-Sockel befassen. Ebenso wichtig: Je nach Mainboard liegt der erste PCIE-Steckplatz so hoch, dass es zu einer Kollision mit dem Kühlkörper kommen kann.

Ich kann im Moment nur über das in den Kunden-PC verbaute Board reden: Ein AsRock Z170 Extreme7. Da sind die Abstände in Richtung RAM und PCI-E-Steckplatz gerade so ausreichend – wir reden aber in beiden Fällen über weniger als 1 mm. Das ist bei Platinen mit hohen Lötstellen am ersten PCI-E2.0 x1-Steckplatz bereits kritisch; die Rippen des Kühlkörpers sind da gefährlich nah. Ich habe den PCI-Slot freigelassen. Zwischen der Oberkante des ersten RAM-Moduls (G.Skill D464GB 3200-14 Ripjaws V Black K4 GSK) und dem Kühlkörper ist ein winziger Schlitz gerade noch zu erahnen.

20160930_190310_400

Aufzupassen sollte man auch bzgl. der Richtung des Luftstroms. In dem vom Kunden vorgegebenen Gehäuse wird Luft von vorne angezogen und nach hinten abgeführt. Der Lüfter sollte dann so verbaut werden, dass er nicht gegen den Luftstrom arbeitet – in unserem Fall musste der Lüfter wie auf der Alpenföhn-Webseite abgebildet ( siehe: http://www.alpenfoehn.de/images/Produkte/Bilder/Brocken2/Brocken2_91.jpg) montiert werden; mit der Blasrichtung in den Kühlkörper-Aufbau hinein.

20160930_190518_400

(Die gelbliche Farbe in dem von mir gemachten Bild ist nur ein Reflex einer Lampe; der Kühlkörper ist in Wirklichkeit silbern.)

Plus:

  •  + Sehr
    gute Kühlleistung.
  •  + Praktisch unhörbar – auch wenn der Lüfter mal auf Vollast drehen sollte. (Was ich aber bislang trotz Auslastung von 8 Threads bei normalem Luftstrom im Gehäuse und Standard-Lüfterprofil des BIOS noch nicht erzwingen konnte.)
  •  + Der Kühlturm ist gegenüber der CPU leicht nach hinten versetzt ausgerichtet, so dass zum Bereich der der RAM-Steckplätze in der Regel noch etwas Platz bleibt – minimal, aber es reicht.
  •  + Flexibilität im Bereich von etwa einem halben Zentimeters bzgl. der Höhe, in der der Lüfter am Kühlkörper angebracht werden kann (das kann einem bei hohen RAM-Modulen vor Kollisionsproblemen mit dem RAM schützen).
  •  + Aus meiner Sicht preiswert!

Minus:

  • – Die großen Dimensionen des Kühlkörpers sind ein Nachteil – das Teil passt mit seiner Bauhöhe sicher nicht in jedes Gehäuse. Auf manchen Mainboards mag es zu Platzproblemen in Richtung RAM oder PCIE-Steckplätze kommen.
  • – Der Einbau selbst ist ein wenig hakelig. Bzgl. des Anziehens der Schrauben für die Befestigung des tragenden Gerüsts am Mainboard sollte man ein wenig aufpassen. Im Gegensatz zu den Abbildungen in der Einbauanleitung gilt: Die Klemmen für den Lüfter sind seitlich (!) und nicht oben/unten am Kühlkörper zu befestigen!

Viel Spaß ansonsten mit diesem CPU-Kühler, der im Gegensatz zu einem Alpenföhn Wärme nicht zu- sondern abführt !