S100 Revival

Kürzlich ergab sich der Bedarf nach einer möglichst günstigen Printserver-Lösung. Nach dem Durchschauen mehrerer USB-Ethernet-Adapter, die meist nur “mit ausgewählten Druckern voll kompatibel” sind, viel mir die gute alte S100 wieder ein, die in einer Hardware-Kiste im Keller eingemottet ihr Dasein fristete.

Da ich sowieso noch auf der Suche nach einem Backup-Target für zwei Server war habe ich das Teil also herausgekramt, mit einer Transcent IDE-SSD versehen (32GB, mittlerweile bezahlbar) und neu aufgesetzt – diesmal auf Debian-Basis.

Sie werkelt nun seit ein paar Wochen brav vor sich hin und ist mittlerweile Printserver, Munin-Node und -Master, Backup-Relay, SSH-Gateway und Mailserver für die lokale Domäne. Möglich wird das trotz des sehr knapp bemessenen Speichers des Geräts (128 MB, von denen noch Grafikspeicher entfällt) durch exzessiven Gebrauch von xinetd:

micro-httpd:

service http
{
	port            = 80
	socket_type     = stream
	wait            = no
	user            = root
	cps		= 100 5
	server		= /usr/sbin/micro-httpd
	server_args	= /var/cache/munin/www
	disable		= no
}

vsftpd:

service ftp
{
         socket_type    = stream
         wait           = no
         user           = root
         server         = /usr/sbin/vsftpd
         nice           = 10
         disable        = no
}

dovecot IMAPS:

service imaps
{
       disable         = no
       socket_type     = stream
       protocol        = tcp
       wait            = no
       user            = root
       server          = /usr/lib/dovecot/imap-login
       flags           = IPv4
       server_args     = --ssl
}

Außerdem helfen die üblichen Maßnahmen: nicht genutzte Dienste des Standard-Setups deaktivieren (portmap, dbus, etc.), statisches Networking verwenden (spart einen DHCP-Client – jeder Prozess zählt! ;) ), nicht benötigte Kernelmodule blacklisten.

Die Kiste swapt zwar trotzdem regelmäßig und bei den meisten Druckaufträgen wird nach jeder Seite eine Gedenkpause von gut 10 Sekunden fällig, aber eine Embedded-Lösung mit Rums von der Stange macht doch nur halb so viel Spaß ;)

Einen neuen Anstrich bekam das Gehäuse dann auch noch – passt so besser ins HiFi-Rack.

Update: Die xinetd-config für munin-node scheint nur bei einer gepatchten Version für OpenWRT funktioniert zu haben, daher entfallen.

Update 2: Mailserver hinzugefügt.

Temperatur > Tuning

Meinen Core i7-920 (2.67GHz Standardtakt) hatte ich bis vor kurzem noch per BCLK auf 3.6GHz übertaktet, was bei den 2009er Modellen erfreulicherweise recht zuverlässig funktioniert – ambitioniertere Tuner jagen die Dinger sogar permanent auf über 4GHz hoch. Negativer Nebeneffekt der Sache: Hitze. Der (alte) Core i7 hat mit 130W TDP auf Standardtakt schon eine recht hohe Verlustleistung; übertaktet entwickelt er sich dann endgültig zum Hitzkopf.

Trotz Wasserkühlung knackte mein Exemplar so nicht selten die 70°C – Marke, was mir im Hinblick auf den Sommer einige Sorgen bereitete. Zugegeben, mein System hat in Punkto Kühlungsdesign zwei entscheidende Defizite: 1.) Im Kreislauf hängt neben CPU auch eine GTX 280 als GraKa, die nicht unerheblich zur Hitze beiträgt. 2.) Der Rechner steht eingekeilt zwischen Schreibtisch-Seitenteil, Schrank und Tischplatte, sodass nur nach vorne Luft zu- und wegströmen kann.

Das alles veranlasste mich kürzlich zu einem konkreten Benchmark mit linpack:

Intel(R) LINPACK data
 
Current date/time: Fri May  7 19:49:37 2010
 
CPU frequency:    3.610 GHz
Number of CPUs: 8
Number of threads: 8
 
Parameters are set to:
 
Number of tests                             : 1
Number of equations to solve (problem size) : 21000
Leading dimension of array                  : 21000
Number of trials to run                     : 100  
Data alignment value (in Kbytes)            : 4    
 
Maximum memory requested that can be used = 3528424096, at the size = 21000
 
============= Timing linear equation system solver =================
 
Size   LDA    Align. Time(s)    GFlops   Residual     Residual(norm)
21000  21000  4      252.846    24.4215  3.959026e-10 3.178913e-02
21000  21000  4      252.587    24.4466  3.959026e-10 3.178913e-02
21000  21000  4      252.602    24.4451  3.959026e-10 3.178913e-02
21000  21000  4      252.614    24.4439  3.959026e-10 3.178913e-02
21000  21000  4      252.531    24.4520  3.959026e-10 3.178913e-02
21000  21000  4      252.550    24.4501  3.959026e-10 3.178913e-02
21000  21000  4      252.500    24.4549  3.959026e-10 3.178913e-02
21000  21000  4      252.466    24.4583  3.959026e-10 3.178913e-02
21000  21000  4      252.481    24.4568  3.959026e-10 3.178913e-02
21000  21000  4      252.489    24.4560  3.959026e-10 3.178913e-02
21000  21000  4      252.467    24.4582  3.959026e-10 3.178913e-02
21000  21000  4      252.475    24.4574  3.959026e-10 3.178913e-02
21000  21000  4      252.482    24.4567  3.959026e-10 3.178913e-02
21000  21000  4      252.477    24.4573  3.959026e-10 3.178913e-02
Intel(R) LINPACK data
 
Current date/time: Mon May 10 20:33:50 2010
 
CPU frequency:    2.670 GHz
Number of CPUs: 8
Number of threads: 8
 
Parameters are set to:
 
Number of tests                             : 1
Number of equations to solve (problem size) : 21000
Leading dimension of array                  : 21000
Number of trials to run                     : 100  
Data alignment value (in Kbytes)            : 4    
 
Maximum memory requested that can be used = 3528424096, at the size = 21000
 
============= Timing linear equation system solver =================
 
Size   LDA    Align. Time(s)    GFlops   Residual     Residual(norm)
21000  21000  4      342.691    18.0188  3.959026e-10 3.178913e-02
21000  21000  4      342.756    18.0154  3.959026e-10 3.178913e-02
21000  21000  4      342.765    18.0149  3.959026e-10 3.178913e-02
21000  21000  4      342.770    18.0146  3.959026e-10 3.178913e-02

Summa summarum also ~25% Performance-Einbuße, genau der linearer Weise erwartete Wert. Nun zu den Auswirkungen auf die Temperaturen:

CPU idle CPU Last Case Wasser
OC’ed 47°C 75°C 38°C 43°C
norm. 42°C 53°C 31°C 33°C

Alle Werte außer “CPU Last” beziehen sich auf eine Uptime von ca. 4h bei normalem Office-Workload und einer Raumtemperatur von ca. 23°C.

Fazit: 25% weniger (theoretische) CPU-Performance für 30% bessere Temperaturwerte – für den Sommer ein wie ich finde fairer Tausch. Zumal bei den einzigen wirklich Rechenintensiven Anwendungen (Games!) hauptsächlich GPU und weniger CPU belastet wird.

Hier noch die relevanten Settings für beide Modi:

BCLK Multipl. DRAM Freq. VCore
OC’ed 180.0MHz 20.0 DDR3-1443MHz 1.18750V
norm. 133.0MHz 20.0 –* –*

Die *-Werte werden noch nachgeliefert. Am VCore könnte man sicher noch etwas Undervolting betreiben, hier heißt das Ziel <1.0V :)

Preloading

Angesteckt durch den derzeit herrschenden SSD- und Fast-boot-Wahn beschäftigte ich mich die vergangenen Tage mit diversen Möglichkeiten, den System- und Anwendungsstart zu beschleunigen – ohne SSD ;)   Hier meine Ergebnisse:

Einen sehr guten Überblick über den Status Quo liefern Bootchart und Bootgraph. In meinem Fall ergab sich eine Bootzeit von ca. 31s (Kernel bis Xorg) und eine Kernel-time von 1,8s. Da an letzteren wohl eher kein Spielraum für spürbare Optimierungen bestand, konzentrierte ich mich auf den Bootvorgang.
Schon das Umordnen und Forken einiger init-Scripts brachte gute 3s. Weitere Verbesserungen sollte eigentlich das Tool readahead-list bewirken, erwies sich aber aufgrund meines Setups (/, /usr, /var u.A. aufgeteilt, LVM, verschlüsselte Dateisysteme) als nahezu wirkungslos – adé, Bootbeschleunigung.
Einen weiteren Versuch startete ich mit preload. Preload arbeitet nach dem gleichen Prinzip wie readahead-list, konzentriert sich aber auf den laufenden Betrieb, d.h. es protokolliert periodisch geladene Anwendungen und lädt häufig genutzte künftig vor – ohne direkte Eingriffsmöglichkeit für den user. Leider wirkt die config an mehreren Stellen (memory management) sehr esotherisch, weshalb ich noch keinen zuverlässigen Wert für die Beschleunigung ermitteln konnte.