bitfenix aegis case-display mit Debian verwenden

Bei bitfenix gibt es PC Gehäuse mit eingebautem Display
(BitFenix ICON Display) Da diese Displays hinter der Frontblende eingebaut sind, sehen diese Dinger echt cool aus. Mit Linux kann das Display auch angesteuert werden, bedarf aber (wie meistens unter Linux) etwas Zusatzarbeit.

Hier gibt es den SourceCode
und mit folgenden Zeilen funktioniert das Display auf unter Debian 10.

tar xvzf bitfenix-icon-src.tar.gz
cd bitfenix-icon/
sudo apt install build-essential
sudo apt install libhidapi-dev libpng-dev libturbojpeg0-dev libjpeg62-turbo-dev
g++ -w -lhidapi-hidraw -ljpeg -lpng jpegdecode.cpp pngdecode.cpp hidtest.cpp -fpermissive -o bitfenix-icon
sudo ./bitfenix-icon /path/to/image.png

SanDisk ioDimm3 als writeback Cache

Ich habe heute alle meine virtuellen (test) Maschinen von meiner ExHana Maschine entfernt und mich mit LVM (Logical Volume Manager) beschäftigt.

Im Thomas-Krenn Wiki habe ich eine gute Anleitung gefunden, wie man SSDs als Cache in einem LVM für ein langsameres Storage verwenden kann.

Mit ein paar kleinen Anpassungen funktionieren nun meine SanDisk ioDimm3 als writeback Cache für meinen Raid-Speicher.

Die SanDisk ioDimm3 wurden in einen Raid 1 -Verbund zusammen geschaltet. Der langsamere Storage wird in meinem Setup nicht als Linux Software-Raid zur Verfügung gestellt, sondern direkt vom Smart-Array-Controller als Raid betrieben.

Alle anderen Einstellungen habe ich wie im Wiki beschrieben umgesetzt.

Jetzt geht’s an’s TESTEN.  (Natürlich auch mit LVM Snapshots)

 

Debian Mass storage controller: SanDisk ioDimm3 (rev 01)

In meiner Hana-Test-Maschine sind 2 Mass storage controller: SanDisk ioDimm3 (rev 01) verbaut.

Hier eine kurze Anleitung, wie ich diese Dinger unter Linux Debian 9 installiert habe.

Bei Sandisk registrieren und Sourcecode herunterladen, entpacken und installieren funktioniert bei mir nicht. Fehler beim Compilieren…

Aber auf  GitHub habe ich jemanden gefunden, der die Sources patcht, so dass diese auch mit  aktuellen Debian Kerneln verwendet werden können.
(getestet mit 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux)

 

git clone https://github.com/snuf/iomemory-vsl.git
(stand 1.2.2018 branch master)

cd iomemory-vsl/root/usr/src/iomemory-vsl-3.2.15

make modules

sudo make modules_install

 

Von der SanDisk – Seite im Bereich Ubuntu 16.04 folgende Pakete downloaden

fio-common_3.2.15.1700-1.0_amd64.deb
fio-preinstall_3.2.15.1700-1.0_amd64.deb
fio-sysvinit_3.2.15.1700-1.0_all.deb
fio-util_3.2.15.1700-1.0_amd64.deb
fusion_3.2.11-20150618.fff

und installieren

sudo dpkg -i fio*

sudo depmod

sudo modprobe iomemory-vsl

ls -l /dev/fio* sollte nun devices anzeigen

genau so wie lsblk

sudo update-rc.d iomemory-vsl defaults

sudo nano /etc/sysconfig/iomemory-vsl
ENABLED=1

…und schon kann man die Dinger wie Festplatten verwenden.

Im UserGuide stehen einige interessante Informationen über Performance drinnen…

So zeigt mein System im Leerlauf folgende Messwerte:

wenger@flo-hana-test:~$ for i in sda sdb fioa fiob fioc fiod ; do sudo hdparm -tT /dev/$i ; done

/dev/sda:
 Timing cached reads: 13788 MB in 1.99 seconds = 6924.94 MB/sec
 Timing buffered disk reads: 3222 MB in 3.00 seconds = 1073.57 MB/sec

/dev/sdb:
 Timing cached reads: 13628 MB in 1.99 seconds = 6844.02 MB/sec
 Timing buffered disk reads: 828 MB in 3.00 seconds = 275.87 MB/sec

/dev/fioa:
 Timing cached reads: 13664 MB in 1.99 seconds = 6862.95 MB/sec
 Timing buffered disk reads: 1472 MB in 3.00 seconds = 490.39 MB/sec

/dev/fiob:
 Timing cached reads: 13588 MB in 1.99 seconds = 6825.05 MB/sec
 Timing buffered disk reads: 1484 MB in 3.00 seconds = 494.26 MB/sec

/dev/fioc:
 Timing cached reads: 13646 MB in 1.99 seconds = 6854.43 MB/sec
 Timing buffered disk reads: 1444 MB in 3.00 seconds = 481.06 MB/sec

/dev/fiod:
 Timing cached reads: 13604 MB in 1.99 seconds = 6832.86 MB/sec
 Timing buffered disk reads: 1482 MB in 3.00 seconds = 493.53 MB/sec

und unter Last (… moment; erzeug mal auf so einer Maschine etwas Last…)

also unter Last (load1 = 55.54) ergeben sich diese Messwerte

wenger@flo-hana-test:~$ for i in sda sdb fioa fiob fioc fiod ; do sudo hdparm -tT /dev/$i ; done

/dev/sda:
 Timing cached reads: 10900 MB in 1.99 seconds = 5470.36 MB/sec
 Timing buffered disk reads: 2882 MB in 3.00 seconds = 960.07 MB/sec

/dev/sdb:
 Timing cached reads: 9990 MB in 1.99 seconds = 5013.43 MB/sec
 Timing buffered disk reads: 844 MB in 3.01 seconds = 280.47 MB/sec

/dev/fioa:
 Timing cached reads: 11134 MB in 1.99 seconds = 5586.12 MB/sec
 Timing buffered disk reads: 2420 MB in 3.00 seconds = 806.38 MB/sec

/dev/fiob:
 Timing cached reads: 10940 MB in 1.99 seconds = 5489.71 MB/sec
 Timing buffered disk reads: 2444 MB in 3.00 seconds = 814.11 MB/sec

/dev/fioc:
 Timing cached reads: 10912 MB in 1.99 seconds = 5478.23 MB/sec
 Timing buffered disk reads: 2436 MB in 3.00 seconds = 811.90 MB/sec

/dev/fiod:
 Timing cached reads: 11116 MB in 1.99 seconds = 5581.95 MB/sec
 Timing buffered disk reads: 2454 MB in 3.00 seconds = 817.45 MB/sec

Erklärung:
sda = Raid50 mit 25 Festplatten
sdb = Raid1 mit 2 Festplatten
fioa-fiob = SanDisk ioDimm

Mir ist schon klar, dass hdparm -tT nicht unbedingt ein gutes Messwerkzeug für diese Tests darstellt, aber es zeigt doch ganz deutlich was DVFS (Dynamic Voltage and Frequency Scaling) also die Energiesparfunktionen für Auswirkungen auf die Geschwindigkeit haben.

Electric Vehicle Charging Stations / Schnarchlader mit Handbremse

variable Elaktroauto – Ladung

Ich fahre seit ca. 3 Jahren elektrisch (E-Auto).
Ich möchte möglichst viel meiner erzeugten Energie (PV-Anlage) verbrauchen.
So war es nur eine Frage der Zeit, bis ich meine OpenEVSE irgendwie fern steuere.

Mein SMA – EM liefert mir jede Sekunde genaue Werte zu Verbrauch und Überschuss.
Was noch fehlte war eine Verbindung zur OpenEVSE. Klar kann man die OpenEVSE direkt mit einem FTDI Adapter an einen PC oder RaspberryPi anschließen und damit fern steuern.
Ich wollte aber keinen RaspberryPi im Carport platzieren, oder ein Serielles- oder USB-Kabel verlegen.

Das muss doch auch über WLAN möglich sein.
Ein ESP8266 schien mir dafür gut geeignet.

Ich habe mir dann eine kleine Platine zur Programmierung des ESP8266 gebaut.
Ein bisschen gegoogelt und recht schnell mit der Basis von (link nicht mehr verfügbar) einen Webserver am ESP8266 eingerichtet.

Nun kann ich OpenEVSE Fernzugriffskommandos in einer URL direkt an meine Ladestation senden.

JA-Quick und Diry, aber es geht.
Dafür, dass ich das erste mal einen solchen ESP-8266 verwende bin ich ganz zufrieden.

Da ich sicher öfter neue Versionen oder Features einbauen werde, musste das DING in der Ladestation einfach zu tauschen sein.

Nun kann ich mit einem kleinen Schlitzschraubendreher die Abdeckung entfernen, den ESP8266 – SOC entfernen, neu programmieren und wieder problemlos einsetzen.

Nächste Schritte: Meinem SMA-EM-Daemon eine Logik beibringen, die eine sinnvolle Autoladung ermöglicht.

Ach Ja. Sollte ich mal wollen, dass das Auto geladen wird, unabhängig davon ob ich ausreichend Energie produziere, so kann die Remote-Steuerung deaktiviert werden. Es werden danach keine Daten an OpenEVSE weitergegeben.

 

V2 braucht unbedingt zusätzliches – reconnect – feature

Leider legt sich mein Elektroauto „schlafen“, wenn ich die Ladung stoppe. (Ich habe auch schon davon gelesen, das andere Modelle das auch machen.)

Dauert ein Ladestopp länger als ca. 30 Sekunden, ignoriert das Auto spätere Informationen über Lademöglichkeiten.

V2 wird daher noch 2 Relais bekommen, welche kurz PP und Pilot unterbrechen kann. Dann glaubt das Auto, dass ich den Stecker gezogen habe und gleich wieder eingesteckt habe. Dann beginnt das Auto auch wieder zu laden…

Warum Schnarchlader mit Handbremse:
In der ELEKTRO-Auto-Szene wird eine Ladeleistung unter 11kW als Schnarchlader bezeichnet; weil es einfach lange dauert.

Wenn ich nun diese Ladeleistung noch weiter reduziere… 😉

 

Coding

NAS 12TB (Eigenbau)

Die Idee:

Mein altes NAS (Dlink DNS323) genügte schon lange nicht mehr meinen Anforderungen.
Da auch immer mehr Dienste in meinem Netzwerk dauernd zur Verfügung stehen sollten, war schnell klar,
dass ein neues System sehr modular (wie ein echter PC/Server [SOHO -small office home office – NAS]) aufgebaut sein sollte.
Als mein Arbeitgeber dann auch noch Teile eines WORM-Speichers austauschte (und mir zur Verfügung stellte)
war die Idee geboren, einen Linux Server mit möglichst wenig Stromverbrauch in diesen Würfel zu bauen.

Die Ausganssituation:

Ein Speicherwürfel eines WORM-Speichers einer Langzeitarchivierungslösung. (keine Ahnung ob ich den Namen nennen darf.)
In diesem Speicherwürfel finden 12 Stück 3,5″ Festplatten Platz.
Die Netzteile wurden aus der Basis ausgebaut und die Systemplatine entfernt.

Worm-Speicherwürfel

Worm-Speicherwürfel

Die Hardware:
Meinem Kollegen verdanke ich die Realisierung des Projektes.
Ohne ihn hätte ich vermutlich nie ein passendes Mainboard gefunden.
Das ASRock C2550D4I passt perfekt in den Sockel des Speicherwürfels.

(Test)Plazierung des Mainboardes

(Test)Platzierung des Mainboardes

Dieses Mainboard hat 12 SATA-Anschlüsse, QuadCore CPU und DDR3 Bänke (hier kann ich auf meinen Fundus zurückgreifen)

Im Worm-Speicherwürfel erzeugten die Lüfter einen Luftstrom von Unten über die Netzteil-Komponenten, zwischen den Festplatten hindurch
bis der Luftstrom am oberen hinteren Rand das Gehäuse wieder verließ.
Die Festplatten sollen auch weiterhin mit diesem Luftstrom gekühlt werden.
Daher werden die Lüfter einfach etwas weiter oben montiert.

Lüfter

Lüfter

Refurbished Gehäuse

refurbished

refurbished

Das Projekt scheint machbar zu sein… Ein Testaufbau soll erste Ergebnisse liefern.

Test-Aufbau

Test-Aufbau

Der Testaufbau scheint vielversprechend, aber bringt auch die Erkenntnis, dass der Einschaltstrom in keinem Verhältnis zur normalen Leistungsaufnahme steht. Um dieses Problem kümmere ich mich später.
So sieht der Standfuß / Sockel des Speicherwürfels mit dem Mainboard aus.

Base-mit-Mainboard

Base-mit-Mainboard

Base-mit-Mainboard

Base-mit-Mainboard

Base-mit-Mainboard

Base-mit-Mainboard

2 LEDs für Power und HDD-Zugriff (für 12 HDDs nur eine LED; mehr gibt das Mainboard nicht her)
und 2 Taster für Power und Reset wurden auf einer Lochplatine angelötet.

LED-Power-Button

LED,Power,Button

Verkabelung:
Aus einem alten ATX-Netzteil und einem alten ATX-Mainboard habe ich mir eine Verlängerung für die Stromversorgung des Mainboards gebastelt.
Die Lötkontakte des ATX-Steckers wurden mit Heißkleber „isoliert“. Silikon kann dafür auch verwendet werden.

Mainboard-Power-Verlängerung

Mainboard-Power-Verlängerung

Die 12 SATA- Anschlusskabel wurden sauber verlegt.

SATA-Kabel

SATA-Kabel

SATA-Kabel

SATA-Kabel

Die Enden der SATA Kabel wurden sorgsam an die Platinen gelötet, welche dann auf die Festplattenbläcke gesteckt werden. (Eine sch….öne Arbeit)

Mainboard-mit-SATA-Verbindungen

Mainboard-mit-SATA-Verbindungen

Die Festplatten wurden zu 2 Festplattenbläcken verschraubt.

Festplatten-Blöcke

Festplatten-Blöcke

Die Festplattenblöcke wurden auf den Sockel montiert (Steckverbindung)

Festplattenblock 1

Festplattenblock 1

Festplattenblock 2

Festplattenblock 2

Einschaltstromproblematik:
Der Testaufbau zeigte, dass dieses NAS im „normalen“ Betrieb relativ wenig Leistung verbraucht. (siehe unten)
Die Stromaufnahme von 12 startenden Festplatten ist aber nicht zu unterschätzen.
Meine Tests Zeigten, dass es keine Probleme gibt, wenn 6 Festplatten mit einer Verzögerung von ca.3 Sekunden starten.
Durch eine kleine Platine wird der zweite Festplattenblock erst Zeit verzögert mit Strom versorgt.
Dadurch sinkt der Einschaltstrom so weit ab, dass ich mein altes Netzteil mit 350W max. weiterverwenden kann.

Einschaltverzöegerung

Einschaltverzögerung

In der Zwischenzeit wurde noch ein alter USB-Stick neben dem Mainboard im Sockel eingebaut.
Auf diesem USB-Stick wurde das Betriebssystem installiert. Dadurch ist es möglich alle Festplatten schlafen zu legen.
Das spart nicht nur Energie, sondern senkt auch den Geräuschpegel des Speichers.

ein neues Gehäuse:
Das Original-Gehäuse ist leider zu wenig hoch.
Hier noch ein letzter Blick auf mein NAS bevor es neu eingekleidet wird.

Gehäuse

Gehäuse

Gehäuse

Gehäuse

Leistungsdaten:

  • Intel Avoton C2550 Quad-Core Processor
  • 4GB DD3 RAM (1 von 4 Bänken belegt) max. 64GB RAM
  • 2x 1GBit LAN
  • 1x Management LAN
  • Formfaktor Mini ITX
  • 12 x 1TB SATA (Das Mainboard wurde auch schon erfolgreich mit 4TB Festplatten betrieben)

Abmessungen:
25cm x 26cm x 42cm
12x 3,5″ Festplatten auf 27 300cm² oder 0,0273m² oder 27,3l.
12TB auf 27,3l

Leistungsverbrauch: (ab Steckdose)
Ich habe mir nun doch ein neues Netzteil eingebaut. Das alte ist doch schon ca. 10 Jahre alt, und so ein Billigteil.
Die folgenden Werte wurden mit dem neuen Netzteil (Super Flower Golden Green HX Series 350W 80PlusGold) gemessen.
Einschaltzeitpunkt: 180W max.
Alle 4 CPU Kerne aktiv; alle 12 Festplatten eingeschaltet, alle 4 Lüfter 100%: 95W
Wenn sich das NAS langweilt (alle Festplatten spindown, nur eine CPU aktiv) zwischen 50 und 60W.

Gewinnspiel:TK
Die Thomas-Krenn.AG veranstaltete ein Gewinnspiel zum Thema „Kreativ mit Servern“.
Da ich scheinbar der einzige Teilnehmer war, kann ich nun eine neue SSD mein eigen nennen.
Facebook-Post von TK

Thomas Krenn

Diese SSD ersetzt eine der HDDs, und ist für das Betriebssystem zuständig. (Ist doch um einiges schneller als ein USB2.0 – Speicherstick)

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen