IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Kategorie: Persönliches & Offtopic (Seite 2 von 8)

Abseits der Technik — persönliche Gedanken, Erlebnisse und alles, was nicht in die anderen Kategorien passt.

Kodi auf dem Raspberry Pi 4: Ruckelfreie Wiedergabe einrichten

Der Raspberry Pi 4 , egal ob mit 4GB oder 8GB RAM, ist in der Kombination mit Kodi eine wunderbare Erweiterung am Fernseher. Leider sorgte die letzte Version Kodi v19.3 (Matrix) bei mir für ein paar Problemchen. So stockte oder ruckelte die Wiedergabe von Videos oder die Wiedergabe lief für einige Minuten gut, dann wurde gebuffert, nur damit sich dieses Spielchen alle paar Minuten wiederholte. Egal ob im WLAN oder direkt am LAN.

Folgende Änderungen haben bei mir für eine Lösung der Probleme gesorgt:

  1. Erstellen einer XML Datei, welche die default Einstellungen des Cachings überschreibt.

    Speicherort und Dateiname ist: /storage/.kodi/userdata/advancedsettings.xml
<?xml version="1.0" encoding="utf-8"?>
<advancedsettings>
        <cache>
                <memorysize>524288000</memorysize>
                <buffermode>1</buffermode>
                <readfactor>6</readfactor>
        </cache>
</advancedsettings>

Achtung… Bei XML Dateien, spielt das richtige „Einrücken“ schon mal eine Rolle.

2. Erweitern des Arbeitsspeichers für die GPU, sowie das Erzwingen des „Turbo“ Modus.
Dafür einfach die Datei /flash/config.txt um folgende Zeilen erweitern/einpassen:

# Default GPU memory split, 76MB are needed for H264 decoder
gpu_mem=256
force_turbo=1

Wer dieses gerne per SSH machen möchte, muss das Volume /flash einmal schreibfähig mounten:

mount -o remount,rw /flash

Die Option gpu_mem setzt recht einfach den, für die Grafikkarte, reservierten Arbeitsspeicher fest auf 256MB. Dieses macht selbst bei der 4GB Raspberry PI 4 Version kein Problem.

force_turbo deaktiviert das dynamische, lastabhängige takten der CPU, GPU und des Arbeitsspeichers, sowie der Spannungen. Alles läuft daher auf Maximum, aber ohne zu übertakten. Dieses hat weniger Auswirkungen auf die Probleme bei der Wiedergabe, sorgt aber für ein allgemein „flüssigeres“ Verhalten. Dafür steigt die Stromaufnahme und die Temperatur. Da wir hier über einen Raspberry sprechen, ist es wohl für die Meisten zu vernachlässigen.

3. Um Temperatur und Geräuschpegel im Zaum zu halten, empfiehlt sich ein gutes passiv gekühltes Gehäuse. Folgendes kann ich empfehlen: https://amzn.to/3qF61pe

Das mitgelieferte Netzteil hat ausreichend Power, man kommt noch an „alles“ ran, das Gehäuse ist sehr massiv und selbst bei großer Last/langem Betrieb, wird alles nur handwarm.


Update Februar 2026 — Kodi 21 (Omega) / LibreELEC 12.x

Seit Kodi 21 (Omega), das mit LibreELEC 12.x ausgeliefert wird, funktioniert die oben beschriebene Cache-Konfiguration über die advancedsettings.xml nicht mehr korrekt. Die <cache> Sektion wird zwar noch eingelesen und im Log angezeigt — die tatsächlich aktiven Werte kommen aber aus den GUI-Settings (guisettings.xml). Im Kodi-Log erkennt man das an dieser Zeile:

New Cache GUI Settings (replacement of cache in advancedsettings.xml) are:
    Buffer Mode: 4
    Memory Size: 20 MB
    Read Factor: 4.00 x

Das bedeutet: Trotz konfigurierter 500 MB in der advancedsettings.xml läuft Kodi mit nur 20 MB Puffer — dem Default. Nicht gerade ideal.

Die neue Methode

Die Cache-Werte müssen jetzt direkt in /storage/.kodi/userdata/guisettings.xml gesetzt werden. Dafür Kodi stoppen, Datei bearbeiten, Kodi starten:

systemctl stop kodi
sleep 3

In der guisettings.xml diese drei Zeilen suchen und anpassen. Wichtig: Das default="true" muss entfernt werden, damit Kodi die Werte als benutzerdefiniert erkennt.

Vorher:

<setting id="filecache.buffermode" default="true">4</setting>
<setting id="filecache.memorysize" default="true">20</setting>
<setting id="filecache.readfactor" default="true">400</setting>

Nachher (Beispiel für 8 GB RAM):

<setting id="filecache.buffermode">1</setting>
<setting id="filecache.memorysize">500</setting>
<setting id="filecache.readfactor">600</setting>

Dann Kodi wieder starten:

systemctl start kodi

Was die Werte bedeuten

buffermode = 1

Legt fest, welche Quellen gepuffert werden:

WertBedeutung
0Nur Internet-Streams (HTTP, FTP…)
1Alles (Internet + LAN + lokal) ← empfohlen
2Nur „echte“ Internet-Streams
3Kein Puffer
4Alle Netzwerk-Quellen (Default in Kodi 21)

Wir setzen 1 statt 4, damit NFS-Quellen garantiert gepuffert werden — egal wie Kodi die Quelle intern klassifiziert.

memorysize = 500 (bzw. 250)

Die Größe des Puffers in MB. Das ist der Speicher, den Kodi im RAM reserviert, um Film-Daten vorauszulesen.

Praktisches Beispiel: Ein typischer 4K-Film hat ~80 Mbit/s Bitrate (ca. 10 MB/s).

  • 20 MB (Default): Nur ~2 Sekunden Film im Puffer. Wenn das Netzwerk kurz schwankt, stockt die Wiedergabe sofort.
  • 500 MB: Ca. 50 Sekunden Film im Puffer. Selbst wenn NFS mehrere Sekunden hängt, läuft die Wiedergabe weiter.

Empfohlene Werte nach verfügbarem RAM:

  • 8 GB RAM: memorysize = 500
  • 4 GB RAM: memorysize = 250

readfactor = 600 (= 6×)

Der Wert wird intern durch 100 geteilt, also 600 = 6,0×. Kodi liest Daten mit der 6-fachen Geschwindigkeit der benötigten Bitrate voraus. Bei einem 80 Mbit/s Film liest Kodi also mit ~480 Mbit/s vom NFS, bis der Puffer voll ist. Danach drosselt es auf die tatsächlich benötigte Rate. Das sorgt dafür, dass der Puffer sich schnell füllt und möglichst voll bleibt.

Verifizierung

Nach dem Neustart im Kodi-Log prüfen, ob die neuen Werte aktiv sind:

grep "New Cache GUI Settings" -A4 /storage/.kodi/temp/kodi.log

Hinweis zum Raspberry Pi 5

Die config.txt Anpassungen (gpu_mem=256 und force_turbo=1) gelten weiterhin für den Raspberry Pi 4. Beim Raspberry Pi 5 sind diese nicht nötig — er nutzt eine andere GPU-Architektur (VideoCore VII) und gpu_mem hat dort keine Wirkung.

Lieber Thorben,

Lieber Thorben,

vielen Dank, dass du uns so lange ertragen hast. Du hast unsere Arbeit leichter und bunter gemacht. Ohne dich hätten wir sicher schon die Raufasertapete mehr als einmal von der Wand gefressen.
Vielen Dank für deine Unterstützung in technischer und menschlicher Weise! Wir werden dich NIE vergessen!

Liebe Grüße
Die zwei „Dicken“

Dominos´s Goldcard

Es gibt Momente im Leben eines Sysadmins, in denen man kurz innehalten und sich fragen sollte, ob alles noch so läuft wie geplant. Einer dieser Momente war, als mir der Typ an der Domino’s Theke eine Goldcard in die Hand drückte.

Nachtschichten und Pizza

Wer regelmäßig Nachtschichten im Serverraum schiebt, kennt das Dilemma. Es ist 23 Uhr, der Storage-Umbau läuft, die Migration zieht sich und der letzte vernünftige Bissen war irgendwann mittags. Döner hat zu, der Kühlschrank im Büro gibt maximal eine traurige Käsescheibe her. Aber Domino’s liefert. Immer. Egal ob Mitternacht oder drei Uhr morgens.

Irgendwann kennen die einen. Erst am Telefon („Ach, Sie schon wieder, das Übliche?“), dann an der Theke. Man wird Stammkunde, nicht weil man Domino’s so wahnsinnig toll findet, sondern weil die halt offen haben wenn sonst niemand mehr offen hat. Pragmatismus schlägt Kulinarik, vor allem um zwei Uhr nachts mit einer Hand am Terminal.

Die Goldcard

Jedenfalls drückte mir eines Abends der Filialleiter kommentarlos eine goldene Plastikkarte in die Hand. Domino’s Goldcard. Heißt im Klartext: Ab sofort gibt es auf jede Bestellung Rabatt. Weil man so oft da war. Weil man so viel bestellt hat. Weil man offenbar zu den besten Kunden der Filiale gehört.

Dominos Goldcard, Stammkunde durch Nachtschichten im Serverraum

Da steht man dann mit seiner Goldcard und fragt sich: Ist das jetzt eine Auszeichnung oder eher ein Hilferuf? Wahrscheinlich beides. Aber immerhin, die Server liefen am nächsten Morgen und die Pizza war warm. Prioritäten.

Falls du auch regelmäßig dein Rechenzentrum mit Pizza am Laufen hälst und Fragen hast, kannst du mich gerne fragen. Zur Pizza kann ich leider nicht mehr viel sagen, die Filiale hat inzwischen zugemacht. Wahrscheinlich nachdem ich weggezogen bin.

Ausfall bei Telekom SmartHome

Das Telekom SmartHome System hat seit gestern am Morgen Probleme. Die automatischen Regeln tun was sie sollen und lokal kann man sich ebenfalls noch mit der Box verbinden und fast wie gewohnt steuern. Online ist aber kein Stich zu machen. Ebenfalls die Anbindung mit anderen Onlineservices ist damit tot.

https://community.qivicon.de/questions/ausfall-im-qivicon-rechenzentrum-homebases-aktuell-nicht-online

Ausfällt und Probleme kann es immer mal geben. Vor allem dieses Qivicon / Telekom „Ding“ ist mäßig stabil, tat aber in den letzten Monaten recht brauchbar seinen Dienst. Ein Ausfall von nun knapp 24Stunden ist dennoch echt heftig. Ich kann mir nicht viele Dinge vorstellen bei denen es zu so einem langen Ausfallen kommen kann, vor allem das die Herren so ja keinen besonderen Peak haben dürften. Hier hat wohl jemand echt massiv verkackt, sofern nicht gerade jemand die Jungs mit einem DDoS „warm“ hält. Das hätte man sicher schon über andere Wege erfahren.

Ob da wohl jemand die Datenbank kaputt gemacht hat? Vielleicht ist hier ja was out of sync, das wieder zusammen zu bekommen kann schon mal echt lange dauern. Fast alles andere ist: An der falschen Stelle gespart oder halt epic fail.

Samstag am Morgen hat es angefangen, na da werden wohl jetzt ein paar Bereitschaftsadmins und Devs um ihr Wochenende gebracht. Na dann….

Siehe auch: QIVICON Home Base 2.0 Migration, Telekom SmartHome im Test: Erfahrungen mit QIVICON und Home Base​, Telekom SmartHome: Firmware-Updates für HomeMatic-Geräte über die CCU2

Fragen? Einfach melden.

Topf Secret

Das Projekt FragDenStaat kennt ja inzwischen fast jeder und die meisten werden es schon mal genutzt haben. Etwas übersehen habe ich Topf Secret. Kommt aus dem gleichen Projekt, dreht sich dabei aber speziell um das Thema Lebensmittelhygiene.

https://fragdenstaat.de/blog/2019/01/15/neue-kampagne-topf-secret/

Ich habe ein paar Anfragen gestellt, bin mir nur noch nicht ganz Sicher ob ich es wirklich wissen möchte. Ein Kollege hat mir mal gesagt: „Wer viel fragt; bekommt viele Antworten!“ :-/ Was meint ihr dazu?

Fragen? Einfach melden.

E-Mail Adressen

Das ist eine Kontaktliste mit E-Mail Adressen, an welche man unbedingt Angebote schicken muss. Wer fragen zur Kontaktliste hat, bitte einfach melden!

wurstmann@kernel-error.org

kleinmann@kernel-error.org

hundebauch.balem@kernel-error.org

info@kernel-error.org

buchhaltung@kernel-error.org

management@kernel-error.org

ceo@kernel-error.org

wurstmann@tagesmutter-rheinbach.de

kleinmann@tagesmutter-rheinbach.de

hundebauch.balem@tagesmutter-rheinbach.de

info@tagesmutter-rheinbach.de

buchhaltung@tagesmutter-rheinbach.de

management@tagesmutter-rheinbach.de

ceo@tagesmutter-rheinbach.de

wurstmann@van-alst.de

kleinmann@van-alst.de

hundebauch.balem@van-alst.de

info@van-alst.de

buchhaltung@van-alst.de

management@van-alst.de

ceo@van-alst.de

wurstmann@linux-rheinbach.de

kleinmann@linux-rheinbach.de

hundebauch.balem@linux-rheinbach.de

info@linux-rheinbach.de

buchhaltung@linux-rheinbach.de

management@linux-rheinbach.de

ceo@linux-rheinbach.de

wurstmann@kindertagespflege-sprockhoevel.de

kleinmann@kindertagespflege-sprockhoevel.de

hundebauch.balem@kindertagespflege-sprockhoevel.de

info@kindertagespflege-sprockhoevel.de

buchhaltung@kindertagespflege-sprockhoevel.de

management@kindertagespflege-sprockhoevel.de

ceo@kindertagespflege-sprockhoevel.de

wurstmann@geekbundle.de

kleinmann@geekbundle.de

hundebauch.balem@geekbundle.de

info@geekbundle.de

buchhaltung@geekbundle.de

management@geekbundle.de

ceo@geekbundle.de

Fragen? Einfach melden.

Bosch Schlagbohrmaschine war def.

Mitten im Einsatz ist mir meine Schlagbohrmaschine von Bosch „explodiert“ 🙁 Zum Kauf habe ich direkt für die erweiterte Garantie auf drei Jahre gesorgt daher war mein Ärger überschaubar.

Mitten im Bohren eines einfachen Loches hat es erst hinten in der Maschine geknallt, dann geblitzt und im Anschluss rauchte es. Über die Hotline habe ich einen Abholauftrag erstellt um das Gerät einfach auf der Arbeit abholen zu lassen. Dieses erledigte sich am 16.01.2019 fast von alleine. Heute am 21.01.2019 habe ich das Teil schon wieder zurück. Im Reparatur-Lieferschein stehen 1,5h Arbeit. Ein neuer Anker, neuer Polschuh und ein neuer Bürstenhalter. Damit ist klar was da explodiert ist! Kostet 0€ und am 18.01.2019 war die Schlagbohrmaschine schon wieder repariert.

In der Regel wundere ich mich ja erst darüber, dass ich noch nichts gehört habe und bekomme als Antwort auf meine Nachfrage: „Bitte noch etwas Geduld“. Aber das funktioniert hier spitze. Vor ein paar Jahren war schon einmal eines meiner Bosch Werkzeuge def. da hat die Reparatur ebenfalls ohne jedes Problem funktioniert. Dieses scheint wohl noch immer so zu sein. Ich stoße in der Regel eher an meine Grenzen als an die meiner Werkzeuge, daher passt es für mich. Haltbarkeit und Service/Support sind noch immer Top. Ich bleibe also Bosch ganz sicher ebenfalls bei den nächsten Werkzeugen wieder treu!

Für genau das Gefühl bin ich immer wieder bereit mehr Geld zu bezahlen! Danke Bosch!

Fragen? Einfach melden.

OpenPOWER-Testsystem mit POWER8-CPU von Thomas-Krenn im Detail

Die netten Leute von Thomas Krenn haben uns ihr OpenPOWER-Testsystem zur Verfügung gestellt. Wir wollten dieses System schon länger in die Finger bekommen. Jetzt hat es endlich geklappt.

Die Hardware

Der Server zieht mit seinen zwei 1200-Watt-Netzteilen in der Spitze etwa 370 Watt (im Normalbetrieb um die 230 Watt) und soll laut Thomas Krenn 1.325 BTU/h produzieren. Verbaut sind 128 GB RAM und eine POWER8-CPU:

root@ubuntu:~# lscpu
Architecture:          ppc64le
Byte Order:            Little Endian
CPU(s):                64
Thread(s) per core:    8
Core(s) per socket:    8
Socket(s):             1
Model name:            POWER8 (raw), altivec supported
CPU max MHz:           3857.0000
L1d cache:             64K
L1i cache:             32K
L2 cache:              512K
L3 cache:              8192K

64 Threads auf 8 Cores, SMT8. Das Betriebssystem war ein Ubuntu 16.04 LTS (ppc64le).

Storage-Anpassung

Die mitgelieferten Festplatten (3,5″ Nearline SAS mit 7,2k) waren für unseren Datenbanktest zu langsam. Also haben wir ein paar ältere 15k-SAS-Platten aus dem Lager verbaut und in ein RAID 10 geworfen. Damit war das lokale Storage laut pg_test_fsync vergleichbar mit unseren anderen Testsystemen. Wir wollten ja CPU-Leistung vergleichen, nicht Festplatten.

Alltagsvergleich

Als Erstes ein paar alltägliche Operationen im Vergleich mit Intel-Systemen:

CPUSHA256 500 MBbzip2 500 MBAES 500 MB
2× Xeon E5-2665 @ 2.40 GHz3,859 s5,445 s1,337 s
1× POWER8 @ 3.86 GHz3,803 s7,868 s0,866 s
1× Core i7-6700 @ 3.40 GHz2,370 s4,207 s0,831 s
2× Xeon E5-2650 v4 @ 2.20 GHz2,652 s5,413 s1,585 s
2× Xeon E5-2650 v3 @ 2.30 GHz2,484 s5,217 s1,500 s

AES-Verschlüsselung: POWER8 vorn. SHA256: gleichauf. bzip2: Intel deutlich schneller. Ein gemischtes Bild.

UnixBench

Das OpenPOWER-System gegen ein Dell-System mit zwei Intel Xeon E5-2665 (nur CPU/RAM relevant):

Benchmark2× Xeon E5-26651× POWER8
Dhrystone 234.551.077 lps27.167.564 lps
Double-Precision Whetstone4.082 MWIPS4.092 MWIPS
Execl Throughput2.124 lps2.776 lps
Pipe Throughput2.067.851 lps465.884 lps
Process Creation4.278 lps7.391 lps
Shell Scripts (1 concurrent)5.543 lpm7.085 lpm
Shell Scripts (8 concurrent)6.090 lpm4.357 lpm
System Call Overhead4.186.840 lps344.157 lps
Index Score1.629,6851,8

Process Creation und Shell Scripts (single): POWER8 vorn. System Calls und Pipe Throughput: Intel massiv besser. Der Index-Score geht klar an Intel, wobei der Vergleich nicht ganz fair ist (Dual-CPU gegen Single-CPU).

PostgreSQL-Restore

Die hohe Thread-Anzahl und die breite Speicheranbindung machen die POWER8 theoretisch zum guten Datenbankprozessor. Wir arbeiten viel mit PostgreSQL, also haben wir unsere Testdatenbank restored:

CPURestore-Zeit
2× Xeon E5-2650 v3 @ 2.30 GHz129 min 34 s
1× POWER8 @ 3.86 GHz120 min 43 s

Knapp 9 Minuten schneller als das Dual-Xeon-System. Bei Datenbank-Workloads macht sich die Speicheranbindung bemerkbar.

Fazit

Die POWER8 ist ohne Zweifel leistungsstark. Die Speicheranbindung und die 64 Threads merkt man bei Datenbank-Workloads. Im Single-CPU-Vergleich macht das System bei Datenbanken den Stich. Aber: Das OpenPOWER-System von Thomas Krenn gibt es nur mit einem CPU-Socket, preislich liegt es aber auf dem Niveau eines Dual-Xeon-Systems. In diesem Vergleich hat Intel die Nase vorn.

IBM hat die POWER8 2013 vorgestellt, unser Test war 2018. Die Vergleichssysteme waren ebenfalls nicht brandneu. Unterm Strich: Tolle CPU, aber im Preis-Leistungs-Verhältnis für einen Datenbankserver gegenüber Intel der Verlierer. Im HPC-Bereich oder bei der Anbindung von Nvidia-Beschleunigern sieht das sicher anders aus. Dual-CPU-Systeme oder direkt POWER9 (mit einem Hardware-GZIP-Accelerator und erweiterten Crypto-Instructions, AES gab es in POWER8 allerdings schon in Hardware) wären spannend gewesen. Da IBM von diesen CPUs im Vergleich zu Intel nur geringe Stückzahlen verkauft, bleibt der Preis hoch.

Update 2026: was sich seitdem getan hat

Der Test ist von 2018, die Server-Landschaft hat sich seitdem gedreht. IBM hat 2021 die POWER10 vorgestellt (Power E1080, S1014, S1022), inklusive Matrix Math Assist Instructions für AI-Inferenz. Die OpenPOWER-Foundation ist seit 2019 unter dem Dach der Linux Foundation, und für Workstations jenseits der reinen IBM-Welt ist RaptorCS mit den Talos-II-Boards (POWER9) die Community-Anlaufstelle geblieben. ppc64le-Linux lebt ebenfalls, Debian, Fedora, NixOS und diverse andere Distributionen pflegen die Architektur weiter.

Die größere Veränderung kommt allerdings aus der Konkurrenz. AMD EPYC (Genoa, Turin) dominiert heute im x86-Server-Bereich, Intel hat mit Sapphire Rapids und Granite Rapids nachgezogen, und vor allem ARM ist im Rechenzentrum angekommen: Ampere Altra und AmpereOne, AWS Graviton in der dritten und vierten Generation, NVIDIA Grace für HPC und AI. Die Nische für POWER liegt damit 2026 eher bei AIX-Legacy, HPC mit NVLink-Integration und bei Projekten, denen Architektur-Unabhängigkeit wichtig ist. Für den klassischen Datenbank- oder Webserver-Einsatz ist ppc64le ein Exot geworden.

Wer FreeBSD auf anderer Hardware ausprobieren will: FreeBSD auf dem Desktop beschreibt die Grundinstallation mit MATE. Und mit bhyve und vm-bhyve lassen sich Windows-VMs auf FreeBSD betreiben.

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑