IPFire Hardware-Upgrade

ALIX.2D13 bei hoher Netzlast

ALIX.2D13 bei hoher Netzlast

Als ich letztes Jahr meinen IPCop 2.x nach IPFire 2.x migriert habe, hatte ich befürchtet, dass in absehbarer Zeit neue Hardware nötig sein wird. Dieses Jahr war mit einem langersehntem Upgrade meiner Internet-Leitung dieses Upgrade unausweichlich. Bei maximalem Datendurchsatz über die neue Leitung stiegen CPU-Last und Temperatur des Eigenbau-Routers sehr stark an – so stark, dass sämtlicher Netzwerk-Verkehr stark verlangsamt wurde.

APU-Produktserie

Seit 6 Jahren verrichtete ein ALIX.2D13-Board von PC Engines seinen Dienst als IPCop bzw. IPFire. Da ich mit der Hardware sehr zufrieden war, wollte ich beim gleichen Hersteller bleiben. Vor einiger Zeit hatte ich schon die APU.1D-Produktpalette entdeckt – gegenüber der ALIX-Serie verfügt diese über einige interessante Erneuerungen:

  • AMD Embedded G-Series T40E APUs – 64-bit Dual-Core
  • CF-Kartenslot wurde durch ein SD-Pendant ersetzt
  • 6 Gbit/s SATA- und mSATA-Anschlüsse
  • Gigabit Ethernet statt 100 Mbit/s-Netzwerk
  • Mini PCI-Express-Slots statt MiniPCI Card-Slots
  • SIM-Kartenslot für UMTS-Modems

Mit Begeisterung habe ich gesehen, dass es mit der APU.2-Serie bereits einen Nachfolger mit Quad-Core APUs, größerem Cache und sogar ECC-Speicher gibt. Allerdings genießen diese Produkte meiner Meinung nach einen Beta-Status, da die BIOS-Firmware noch nicht fertig gestellt wurde – es fehlen einige Funktionen:

  • Booten von SD
  • iPXE-Unterstützung
  • ECC-Speichersicherung

Darüber hinaus ergab eine kurze Google-Recherche, dass es bei einigen Linux-Distributionen Treiberprobleme gibt – also erstmal keine Option für mich, auch, wenn der preisliche Unterschied nicht groß ist.

 

Modell CPU Takt Kerne Cache RAM
ALIX.2D13 AMD Geode LX800 500 Mhz 2 128 KB 256 MB
APU.1D2 AMD G T40E 1 Ghz 2 512 KB 2 GB
APU.1D4 AMD G T40E 1 Ghz 2 512 KB 4 GB
APU.2B2 / 2C2 AMD GX-412TC 1 Ghz 4 2 MB 2 GB
APU.2B4 / 2C4 AMD GX-412TC 1 Ghz 4 2 MB 4 GB ECC

 

Letztendlich habe ich mich also für das APU.1D4 entschieden. Um das Setup abzurunden, habe ich beim Online-Shop meiner Wahl passend zum Bundle noch eine 802.11ac-fähige WLAN-Karte bestellt. Anstatt einer SD-Karte entschied ich mich für eine mSATA-SSD vom Typ Kingston SMS200S3/60G – das sollte auch für zusätzliche Aufgaben, wie Proxy-Server und Update-Accelerator ausreichen. 🙂

Installation auf mSATA-SSD

Normalerweise besteht eine Installation von IPFire auf eingebetteten Systemen durch die Übertragung eines Abbilds auf eine Speicherkarte. Bei einer mSATA-SSD gestaltet sich das etwas schwieriger, wenn man nicht gerade einen passenden Adapter hat. Glücklicherweise verfügen die APU-Boards über das CoreBoot-BIOS und können so auch über das Netzwerk oder von USB booten. Nach dem Einschalten des Geräts und einem Tastendruck auf F10 wird das Boot-Menü geöffnet. Sobald die IPFire-CD startet, muss im Menü „Serial console options“ der Punkt „Install IPFire (serial)“ gewählt werden, um die Installation auszuführen. Andernfalls wird die serielle Konsole nicht verwendet und die Installation kann nicht durchgeführt werden.

Wenn eine SSD zum Einsatz kommt, empfiehlt es sich, nicht mehr benutzte Blöcke in periodischen Abständen freizugeben. Das erfordert TRIM-Support, den der Linux-Kernel schon seit geraumer Zeit bietet. Durch das Freigeben wird einerseits die Langlebigkeit der SSD optimiert, andererseits wirkt es auch der Verlangsamung der Schreibzugriffe entgegen. Im IPFire-Forum gibt es ein Beispiel eines Cronjobs, den ich auf meinem System wöchentlich ausführen lasse:

# hdparm -I /dev/sda | grep TRIM
 * Data Set Management TRIM supported (limit 1 block)
# vi /etc/fcron.weekly/batched_discard
#!/bin/sh
LOG=/var/log/batched_discard.log
echo "*** $(date -R) ***" >> $LOG
fstrim -v / >> $LOG
fstrim -v /boot >> $LOG
fstrim -v /var >> $LOG

ESC ZZ
# chmod 0755 /etc/fcron.weekly/batched_discard
# /etc/init.d/fcron stop ; /etc/init.d/fcron start

WLAN

Nach erfolgter Installation fiel mir auf, dass in der Netzwerk-Konfiguration des IPFire keine WLAN-Karte zur Auswahl stand. Erkannt wurde sie jedoch:

# lspci|grep Qualcomm
05:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter

Der Grund hierfür war, dass der für diese Karte benötigte Treiber (ath10k) eine benötigte Firmware nicht nachladen kann, das kann auch im Boot-Protokoll nachgelesen werden:

# less /var/log/bootlog
...
[   12.095632] ath10k_pci 0000:05:00.0: irq 47 for MSI/MSI-X
[   12.095723] ath10k_pci 0000:05:00.0: pci irq msi interrupts 1 irq_mode 0 reset_mode 0
[   12.372230] ath10k_pci 0000:05:00.0: Direct firmware load failed with error -2
[   12.372240] ath10k_pci 0000:05:00.0: Falling back to user helper
[   12.374067] ath10k_pci 0000:05:00.0: could not fetch board data 'ath10k/QCA988X/hw2.0/board.bin' (-2)
[   12.374321] ath10k_pci 0000:05:00.0: Direct firmware load failed with error -2
[   12.374326] ath10k_pci 0000:05:00.0: Falling back to user helper
[   12.376061] ath10k_pci 0000:05:00.0: could not fetch firmware file 'ath10k/QCA988X/hw2.0/firmware-2.bin': -2
[   12.376093] ath10k_pci 0000:05:00.0: Direct firmware load failed with error -2
...

Abhilfe schafft das Bereitstellen der benötigten Firmware – diese ist auf GitHub zu finden. Im IPFire-Wiki ist eine Auflistung der benötigten Firmware-Dateien je nach Hardware zu finden. In meinem Fall waren die folgenden Kommandos notwendig, um die WLAN-Karte zur Kooperation zu zwingen:

# mkdir -p /lib/firmware/ath10k/QCA988X/hw2.0/ ; cd $_
# wget https://github.com/kvalo/ath10k-firmware/raw/master/QCA988X/board.bin
# https://raw.githubusercontent.com/kvalo/ath10k-firmware/master/QCA988X/10.2/firmware-3.bin_10.2.2.39.6-1 -O firmware-3.bin

Nach einem Rebot stand die Karte dann zur Verfügung – allerdings habe ich bisher noch keinen Weg gefunden, den 802.11ac-Standard zu verwenden.

Sharing is caring


Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInShare on XingShare on RedditPrint this pageEmail this to someone

14 Kommentare Schreibe einen Kommentar

  1. Ich bin auch sehr gespannt auf die APU2-Boxen. Aktuell hab‘ ich auch 2x APU1 im Einsatz und bin sehr zufrieden mit den kleinen Boxen. Haben bei mir einige Soekris abgelöst. Verwende sie sogar als HA-Firewall mit Proxmox in einem größeren Cluster.

    Danke für den Link der zum Varia-Store, wusste nicht, dass man auch 19“ Rack-Einschübe in Deutschland kaufen kann.

    • Hey Andreas,
      das klingt nach einem interessaten Setup! Die Soekris-Teile sind leider echt teuer – und mit Intel Atom-Prozessoren und DDR2-Speicher auch ziemlich betagt. Da ist mal dringend ein Update nötig. 🙂

      Wo hast Du denn deine APUs gekauft?

      Das Rack-Gehäuse sieht echt interessant aus – bin am Überlegen, ob ich mir nicht auch eins zulegen sollte.. 😀

      • Hi Christian,

        bei http://www.apu-board.de/ – Soekris hat leider ein Update abgekündigt, daher sind wir zu APU gewechselt. Man hat leider nur „3“ NICs, die Soekris mit 4-Portkarte hat insgesamt 8 NICs und man hat auch Dual-mSATA, aber ja, sehr teuer. 2 APUs waren billiger als eine Soekris und mit HA-Lösung fährt man auf jeden Fall besser.

      • Gut zu wissen, danke für die Info!
        So viel NICs brauche ich privat natürlich nicht – aber für den professionellen Einsatz ist das natürlich wichtig. Da fehlt noch was im Petto von PC Engines. Aber vielleicht kommt ja auch das bald mal. Sollte sich technisch eigentlich gut an die APU.2x anbinden lassen. 🙂

        Grüße!

  2. Sagen dir die Begriffe „wear levelling“ und „TRIM“ etwas?

    Seit 8 Jahren beherrschen SSD-Controller Wear-Levelling, dh. der Controller verteilt die logischen Schreibvorgänge so auf die physikalischen Speicherblöcke, dass alle statistisch gleich oft beschrieben werden. Bei Bedarf wird der Inhalt eines beschriebenen Blocks auf einen nicht beschriebenen kopiert und die logische Zuordnung vertauscht.

    Das heißt, seit 8 Jahren ist die Lebensdauer von SSDs HÖHER als die von magnetischen Festplatten, bei denen Metadaten zig tausend Mal am Tag auf denselben physischen Sektor geschrieben werden. Seit 6 Jahren gibt es SATA-TRIM (Option discard), womit das Filesystem dem Controller sagen kann, welche Blöcke es nicht mehr benötigt, sie für den Controller also wieder leer und somit frei verfügbar sind, was das frühere Immer-langsamer-Werden „alter“ SSDs verhindert. (Da irgendwann aus Sicht des Controllers alle Blöcke belegt sind und somit oft bei Schreibvorgängen umkopiert werden müssen, was auch die Anzahl der Schreibvorgänge erhöht.)

    Es gibt sinnvolle Maßnahmen, um die Anzahl der Schreibvorgänge zu verringern, und zwar sinnvoll für alle Datenträger. Dazu gehörten: höhere Commit-Zeiten, noatime, größere Caches (sysctl), /tmp im RAM, ev. /var/log im RAM usw. Auf das Transaction-Log zu verzichten, ist nicht sinnvoll. Denn während das im Falle eines Fehlers mit vorhandenem Log e2fsck das in 2 Sekunden erledigt hat, ist im schlimmsten Fall ohne Log das Dateisystem nur mehr Schrott.

    • Hallo Gerald,

      danke für das Feedback! Ich muss zugeben, meine letzten native Linux-Installation auf SSD-Speicher ist schon zahlreiche Jahre her – daher hatte ich mich im ersten Schritt gegen das Journal entschieden.
      Natürlich hast Du Recht, dass ein Ausfall ohne Journal katastrophale Folgen haben kann.
      Eine Recherche hat ergeben, dass IPFire TRIM schon seit langer Zeit (bzw. der Kernel tut es) – habe somit das Journal wieder aktiviert und gebe nicht mehr benutzte Blöcke periodisch frei.

      Habe den Artikel entsprechend angepasst!

      Beste Grüße,
      Christian!

    • Hey DaHans,
      gute Frage – ist schwer zu sagen. Wenn ich mir die Auslastung meines APU-Systems anschaue, kann ich mir gut vorstellen, dass das System auch bei 100 Mbit/s ausreichen sollte. Wirklich testen und nachstellen kann ich das allerdings nicht – habe hier „nur“ 50 Mbit/s.
      Wie hoch ist den Budget? 🙂

      Beste Grüße,
      Christian!

      • Hey Chris,

        danke für deine Antwort. Am besten so wenig wie möglich :), ich möchte ja eigentlich nur ein Router mit etwas (oder viel) mehr Konfigurationsmöglichkeiten aber er sollte halt schon mind. 100Mbit Durchsatz können bzgl. Zukunft 🙂

    • Also die Soekris 5501 mit Geode von 2007 war locker in der Lage 100mbit zu schaffen. Die APU schafft das locker … ich erreiche 65 MebiBytes/s – also ca. ein halbes GBit beim Lesen von der APU. Iperf meldet 929 Mbit/s.

  3. Moin Moin,
    Kannst du mittlerweile das APU.2 Board empfehlen?
    Möchte dieses Jahr meine Provider Box mit diesem Board+VDSL Modem ersetzten.

    • Guten Morgen!
      Wenn ich es richtig sehe, hat sich hinsichtlich der Firmware in der Zwischenzeit etwas getan – zumindest habe ich auf die Schnelle keine Hinweise mehr auf fehlende ECC-Unterstützung gefunden (wie das vor einem Jahr der Fall war). Ich selbst habe keine Erfahrungen mit dem Board – ich würde es einfach mal auf einen Versuch ankommen lassen. Zur Not hast Du ja die 14 Tage Umtauschrecht. 🙂

      Beste Grüße!

  4. Hallo,
    sehr interessanter Artikel. Hben die Realtek-Netzwerkkarten des APU.1D2 bei dir kein Problem gemacht? Ich hab diese nicht zum laufen bekommen. Benutze aktuell pfsense, möchte jedoch weg vom FreeBSD, da hier Wlan immer wieder Probleme macht. MitFreeBSD wurde es schon deutlich besser, stellt mich aber immer noch nciht zufrieden. Grüße

    • Hey Micha,
      danke für das Feedback! Ich hatte gar keine Probleme mit den Netzwerkkarten – auch WLAN funktioniert seit der Installation sehr zuverlässig. Mit welcher Version hast Du denn deine Tests durchgeführt?
      Habe seit letztem Jahr keine Neuinstallation durchgeführt, kann mir aber nicht vorstellen, dass neue Versionen fehlerhafte Module mitliefern.

      Beste Grüße,
      Christian!

Schreibe einen Kommentar