Author Archives: Bernhard Fröhlich

Personal story of a ports committer

You all know that sometimes you end up dealing with all the ugly stuff instead of doing useful work. Over the last few months I was kept busy at $dayjob got assimilated by portmgr and had to look after redports. All of those new challenges are nice on it's own and I really enjoyed being part of the FreeBSD community and ecosystem but then 11/11 happened.

At that day quite a lot has changed for me since redports was isolated as a precaution and all ports building clusters of portmgr were effectively shut down. That situation was quite a mess since all automated systems and clusters were gone. No INDEX builds, no QAT, no pointyhat so also no exp-runs anymore. Whenever someone broke the ports tree we didn't even knew. It proved to be quite hard to get back on track again after that incident. INDEX checks and a very very limited QAT are already running again but pointyhat and redports are still dead. :(

The daily frustration and dealing with all that strange decisions that are taken because of the need to get stuff done is hard sometimes. But It's almost Christmas and without redports I have much more spare time so I try to calm down and focus on stuff that I can hack on my own. And that worked out quite nice so far ...

I've noticed in the XBMC 12.0 release notes that they have included the PVR branch and thus support DVB-S2/C/T in XBMC. Well actually they only provide some backend configuration interfaces and rely on a backend like mythtv or tvheadend to handle the DVB stuff. Mythtv would be okay for that task but It's huge for such a small job. Tvheadend is a nice and small TV streaming server that suites perfectly and only does the bare minimum without a lot of dependencies. Configuration is done in a web based GUI or can be done in XBMC. So I started working on a tvheadend port. A few weeks later I'm at the point now where tvheadend compiles fine and also starts. I've just ripped out all that epoll stuff and linuxisms that I stumbled accross so it doesn't run properly yet. Adding kqueue support is the next step now.

Due to redports being unavailable the vbox work has also frozen. I tried to collect all that patches and complains in my inbox so that they don't get lost. Since the situation did not improve I temporary created a github repository for the virtualbox ports and committed all the accumulated patches there:

This includes almost all patches that were flying around on mailinglists and updates vbox to 4.2.6 / 4.1.24 but testing was very limited so take care if you give them a try. Testing will show us if we can commit it to the portstree by New Year's Eve.

Ports QAT functionality integrated into redports

We used to have a FreeBSD Ports QAT machine that did automatically build all affected ports after a commit. Well that machine is down since quite some time now because of an hardware defect I think. In my plans for I started quite early to think about integrating the QAT service so I talked to itetcu at BSDDay in 2011 about the current implementation of the QAT system. It works by parsing the ports CVS mails to find out which ports are affected by the commit. Then it updates the CVS tree from one of the tier1 CVS mirrors and hopes to have a consistent portstree. After that it schedules new jobs in the Ports Tinderbox and sends out mails to the committer if building failed. That worked fine most of the time but it had quite some weak spots which required to constantly look after the machine to keep it going.

The most important thing that I learned from that was that we need to migrate our ports repository from CVS to something that allows a consistent checkout. Now that beat is working on the cvs to svn migration and has a testing repository I used that to implement QAT functionality into the redports infrastructure. Instead of parsing CVS mails I can use svn info to find new commits and consistent repository checkout is also guaranteed by subversion. After all it took me about one working day to fully integrate the QAT functionality and test the new stuff.

There are a few benefits for the upcoming QAT system now that it is a part of the regular redports infrastructure:
  • access to all redports building machines (more power!)
  • parallel builds on multiple boxes
  • archived buildlogs
  • run QAT jobs for multiple FreeBSD versions/architectures
  • nice web frontend with RSS feeds and the usual modern stuff
  • you still get mails of course

DVB-S Live TV on FreeBSD with MythTV 0.23 and webcamd

It's not true anymore that FreeBSD does not support any DVB-S devices. Thanks to the work of Hans Petter Selasky on video4bsd there are now DVB-S/2 devices for USB that just work.

The work on MythTV to get this running only took me one evening and was just because nobody compiled mythtv with v4l support lately. It also helped a lot that Jürgen Lock already played with the same device and found and fixes a few things.

So what do you need to do now if you want to build your PVR on FreeBSD?

First you need a USB device for DVB-C/DVB-T/DVB-S/DVB-S2 that is supported by webcamd. I took an Pinnacle PCTV Sat HDTV Pro USB 452e that supports DVB-S2 because I talked to Jürgen Lock and knew he had success with it. I don't know if there is already a list with all devices that work but you could have a look at the Makefile of webcamd in svn to see what drivers and cards should be supported.

Now that you have a supported card follow the instructions on the video4bsd page and build webcamd from the svn repository because the current version in ports is too old already.

At last get the latest mythtv 0.23 port from the call for testers that enables v4l support. This will get committed when they have done their release.
Finally start mythtv-setup and configure your v4l device, scan for some channels and watch live-tv with your brand new PVR solution on FreeBSD!

FreeBSD 7.2 mit Huawei E220 in Österreich (drei)

Nachdem ich bei eBay ein Huawei E220 für grob 35.- Euro erstanden und mir jetzt noch eine Daten Simkarte von drei besorgt habe folgt der interessante Teil.
Diese Anleitung verwendet den u3g Treiber von FreeBSD 7.2 mit einem Huawei E220 im Österreichischen Netz von 3

u3g Treiber laden

Wie gewohnt mit kldload u3g laden und damit er nach dem nächsten Neustart gleich geladen wird in /boot/loader.conf eintragen.




Selbst zusammengesucht und durch trial and error so lange ausgebessert bis es das tut was ich will.

 set device /dev/cuaU0.0
 set speed 460800
 set timeout 0
 set authname
 set authkey

set crtscts on
set reconnect 3 90
set vj slotcomp off
set lqrperiod 600
disable shortseq
disable vjcomp
disable acfcomp
disable deflate
disable deflate24
disable pred1
disable protocomp
disable mppe
disable ipv6cp
enable lqr
enable dns
resolv writable
set ifaddr
add default HISADDR


Jedes mal wenn man das UMTS Modem ansteckt muss man erstmal die PIN eingeben. Das kann leider nicht in die ppp.conf weil es sonst bei jedem reconnect einen Fehler auslösen würde deshalb machen wir das auf der Kommandozeile.

echo AT+CPIN=1234 > /dev/cuaU0.0

Nun kann man wie gewohnt verbinden.

ppp drei > dial

Sollte die Verbindung abgebaut werden oder abbrechen kann man durch ein erneutes dial wieder neu verbinden.
Sollte irgendwas nicht auf Anhieb funktionieren kann man auch selbst mit dem Modem reden - in AT Kommandos versteht sich. ("AT", "ATI", "AT&V", ...)

cu -s 460800 -l /dev/cuaU0.0

Autoconnect mit devd

Man kann auch devd nutzen damit er beim anstecken dieses Modems automatisch die PIN eingibt und eine Verbindung aufbaut.


attach 100 {
 device-name "ucom[0-9]+";
 match "vendor" "0x12d1";
 match "product" "0x1003";
 action "sleep 5 && echo AT+CPIN=1234 > /dev/cuaU0.0 && ppp -ddial drei";

FreeBSD SLiM Themes

Kaum hab ich einmal Urlaub vergeude ich meine Zeit gleich mit Dingen die ich eigentlich garnicht kann. Dafür gibt es jetzt einen FreeBSD Theme für SLiM den ich seit Jahren zufrieden als Login Manager verwende.

Entpacken in /usr/local/share/slim/themes und danach in /usr/local/etc/slim.conf den Wert current_theme = freebsd-beastie oder freebsd-simple einstellen.

Stromsparender FreeBSD 1GBit Router

Vor 10 Monaten hab ich mit den ersten Vorbereitungen für diesen Router begonnen und in dieser Zeit viel über Effizienz, Stromsparen und Undervolting gelernt. Hier die kompakte Zusammenfassung für alle die ein ähnliches Vorhaben planen. 


Die Vorgaben sind für 2008 wohl relativ leicht nachvollziehbar. Ich brauch einen Router der wirklich 1GBit routen kann, mindestens 4x 1GBit Netzwerke bedient, möglichst wenig Strom verbraucht (weniger als 35W im Idle) und unter einem BSD läuft. Der Preis spielt natürlich auch eine Rolle aber bei den heutigen Hardwarepreisen war mir der Stromsparaspekt wichtiger.

Stromsparende Hardwareauswahl

Mit herkömmlicher x86 Hardware 1GBit zu routen ist wie ich bereits mit Benchmarks ermittelt habe kein großes Problem vorausgesetzt man verwendet ordentliche Netzwerkkarten. Nachdem ich mindestens 4 Netze haben will fällt die Wahl eindeutig auf eine Intel PRO/1000 PT Quad Server Karte denn Alternativen gibt es eigentlich keine.
Wenn es um die Motherboardauswahl für ein stromsparendes System geht führt momentan nichts an einem nForce 630a Chipsatz vorbei. Bei den Netzteilen geht der Trend in letzter Zeit immer mehr in Richtung Effizienz und 80Plus was es in Zukunft einfacher machen sollte ein gutes Netzteil zu finden. Derzeit hat man noch nicht viele Möglichkeiten aber ich hatte noch eine PicoPSU übrig und ein relativ gutes 65W Morex Steckernetzteil also habe ich die verwendet. Wenn man aber ein effizientes Netzteil sucht dann gibt es bei 80Plus eine Liste aller 80Plus zertifizierten Netzteile. Außerdem helfen einem die User im Meisterkü Forum gerne mit Rat und Tat weiter.


Eine gute Hardwareauswahl ist enorm wichtig, denn wenn man einen High-End Chipsatz oder eine zusätzliche Grafikkarte verwendet dann verbraucht das schnell einige 10 bis 100W mehr als notwendig. Das selbe gilt für alle die noch einen Pentium 4 irgendwo herumliegen haben - lasst ihn liegen! Mit so einem System ist es sinnlos zu versuchen noch 5W durch Undervolting einzusparen wenn man durch einfachere Maßnahmen 100W sparen kann.
Wenn man aber alles richtig gemacht hat und jetzt noch das letzte überflüssige Watt einsparen will dann kann man die Kernspannung der CPU reduzieren. Das ist prinzipiell gefährlich denn es kann zu Hardwareschäden führen aber die Gefahr ist bei richtiger Handhabung gering und führt maximal zu einem einfrieren des Systems.
Das ist die Theorie denn für Linux und Windows gibt es zwar einige solcher Tools aber leider bis dahin kein einziges unter BSD. Zum Glück habe ich einen Arbeitskollegen der aus unzufriedenheit mit einem der Linux undervolting Tools selbst ein solches Projekt namens cpupowerd gestartet hat. Das war die perfekte Gelegenheit für mich diesem Tool FreeBSD Unterstützung beizubringen denn wie oft hat man schon die Gelegenheit so direkten Kontakt mit dem Author zu haben? Das Resultat war ein Patch für cpupowerd 0.1.2 der FreeBSD 6.x und 7.x support für AMD K8 CPUs hinzufügt.


Es war einiges an Arbeit die für mich perfekte Lösung zu finden und dann auch umzusetzen aber das Resultat überzeugt. 31W im Idle und ca 50W unter Volllast für einen 5x 1GBit Router bekommt man auch mit Mobile Hardware kaum hin. Die 2 Wochen Arbeit um dem cpupowerd FreeBSD Support beizubringen haben sich auch gelohnt denn das Undervolting spart im Idle ca 5W und unter Volllast 9W. 



Vagalume 0.6 for FreeBSD


Mir ist der offizielle Client wegen seiner Abhängigkeiten zu QT4 wieder mal tierisch auf den Senkel gegangen denn das passt so garnicht in meinen schön gepflegten GTK/Xfce Desktop. Zum Glück hab ich dann aber Vagalume gefunden. Eine wirklich tolle Applikation die auch meine hochgeliebten Radios spielen kann doch leider ist der noch so neu, dass man ihn nicht in den Ports findet. Also die Fußballsocken hochgekrempelt und selber gemacht. Das Resultat nach knapp 2h sieht schon brauchbar aus.

cpupowerd FreeBSD Patch

Es hat zwar ein paar Tage länger gedauert als ursprünglich geplant aber jetzt ist mein FreeBSD Patch für cpupowerd vollständig und stabil. So wie es aussieht wird er in die nächste größere Version 0.2.0 integriert werden. Ich hätte auch gerne OpenBSD/NetBSD oder DragonflyBSD unterstützt aber leider sind die BSDs in diesem Bereich alle so unterschiedlich und bieten derzeit keine Möglichkeit auf die CPU MSR Register zuzugreifen, dass es sehr viel Aufwand wäre dafür erst einmal die nötige Infrastruktur zu schaffen. Auf FreeBSD ist dank Stanislav Sedov sysutils/devcpu vorhanden das als Kernelmodul einen Zugriff auf die MSR Register ermöglicht. Wenn sich jemand darum kümmert das Kernelmodul auf die anderen BSDs zu portieren oder einen anderen Weg kennt um auf die MSR Register zuzugreifen dann mache ich gerne den Rest der dafür nötig ist.

Undervolting mit cpupowerd

Es gibt Grund zur Freude denn seit gestern gibt es das erste Release von cpupowerd 0.1.0. Wofür das Teil gut ist? Einfach erklärt spart es Strom unter Linux und bald auch FreeBSD.

Die Details sind etwas komplexer denn das was die Betriebssystemkernel heute bereits machen und vielen unter Cool'n'Quiet, PowerNow! oder SpeedStep bekannt ist spart bereits viel Strom aber man kann eben noch etwas mehr rausholen. Standardmäßig halten sich alle an die Spezifikation und die ist natürlich für die schlimmsten Fälle gedacht. Damit man genau diese Reserven nutzen kann gibt es cpupowerd der einem beim Undervolten und somit stromsparen hilft.

Momentan werden nur AMD K8 CPUs und Linux unterstützt aber Intel Unterstützung und eine breitere Betriebssystem Unterstützung sind bereits in Arbeit.

So habe ich an den vergangenen 2 Tagen an FreeBSD support für cpupowerd gearbeitet und kann bereits den ersten funktionsfähigen Patch vorweisen. Natürlich muss er noch ausführlicher getestet werden und eine kurze Anleitung fehlt auch noch aber ich bin zuversichtlich, dass er in die nächste Version 0.2.0 integriert wird.

Update 25. MaiEine Anleitung wie man cpupowerd verwenden muss findet man im dazugehörigen Thread

Ganz unerwartet standen heute zu Mittag 2 Pakete vor mir - voll mit bereits vor Wochen bestellter Hardware für meinen zukünftigen Router. Wie ihr mich kennt kaufe ich natürlich keine 25 Euro SoHo Router sondern echtes Männerspielzeug.

Die Hardware habe ich basierend auf meinen Erfahrungen bei den 1GBit Routing Benchmarks ausgesucht und mich ein wenig von meinem Arbeitskollegen beeinflussen lassen der sich mit Stromspar PCs beschäftigt.

Er hat selbst erst vor einigen Monaten einen Desktop PC mit einem Idleverbrauch von 17W zusammengebaut und arbeitet momentan auch an einem Tool für einfaches und stabiles Undervolting. Natürlich hab ich ihn schon dazu überredet es auch FreeBSD kompatibel zu gestalten und mich als Betatester angeboten. Mehr dazu in den nächsten Wochen mit einem Prototypen - aber nun zurück zum eigentlichen Thema.

Einen stromsparenden Router zu bauen der 1GBit routen kann ist mit der richtigen Hardware kein großes Problem. Wichtig ist dabei die Größe des L1/L2 Cache der CPU und die Verwendung guter Netzwerkkarten. Dabei habe ich mich bewusst für die Sempron64 CPUs entschieden denn man kann beim Routing fast immer nur einen Kern vernünftig auslasten und der L1 und L2 Cache sind beim LE-1300 ebenfalls 64KB bzw 512KB also identisch zu den Athlon64 X2 Modellen. Bei den Netzwerkkarten war die Wahl einfach denn man kommt dabei unweigerlich zu Intel PRO/1000 PT Server Karten wo sich nur mehr die Frage stellt wie viele Ports man braucht. Als Netzteil kommt ein 110W Tischnetzteil samt PicoPSU zum Einsatz - nicht billig aber dem Stromverbrauch zuliebe. Standesgemäß verbaut man dann alles in ein 3HE 19" Gehäuse damit man alle PCI und PCIe Slots verwenden kann und fertig ist das Männerspielzeug.


GBit Routing with BSD [Part3]

So nun alles zurück zum Anfang und diesmal mit richtiger Hardware. Bei diesen Tests ist der Ablauf identisch aber diesmal werden beim Routing 2 Intel PRO/1000 PT Server Netzwerkkarten am PCI Express Bus verwendet. Die Auswirkungen auf den Durchsatz sind ordentlich aber viel erfreulicher ist die bei weitem geringere CPU Last.

Aus den Benchmarks habe ich wieder einiges gelernt:
  • billige NICs: 750MBit und 100% CPU Last; ordentliche NICs: 940MBit und 60% CPU Last
  • Intel PRO/1000 PT Server NICs brauchen um ca die Hälfte weniger CPU als die billigeren PT Desktop NICs
  • OpenBSD bevorzugt gute Hardware und läuft dann auch hervorragend



AMD Athlon64 3200+ 1GB DDR PC3200 Elitegroup ECS-nForce4-A939

em0: Intel(R) PRO/1000 PT Server Adapter (PCI-Express) em1: Intel(R) PRO/1000 PT Server Adapter (PCI-Express)
netperf (MBit/sec)iperf (MBit/sec)CPU usage
 em0 > em1em1 > em0em0 > em1em1 > em0
FreeBSD 7.0 BETA2 AMD6494194092793394694693794130%60%
Linux i686758-734-946-936-??
NetBSD 4.0 RC3 i386602574597573903792888763100%100%
OpenBSD 4.2 i38692792490389894694693693640%55%
OpenBSD 4.2 AMD6492892490389194694693793640%55%

GBit Routing with BSD [Part2]

Nachdem ich inzwischen das OpenBSD Kernel-Panic-Syndrom aufklären konnte (böse alte Festplatte) habe ich auch ein paar Linux und NetBSD Durchläufe gemacht und die Tests um iperf erweitert.

Netperf ist zwar ein tolles Tool aber läuft scheinbar bei OpenBSD 4.2 AMD64 auf ein interessantes Problem auf. OpenBSD AMD64 bremst dabei jede TCP Verbindung auf ca 180MBit ein. Da netperf nur genau einen TCP Socket aufbaut und dort so schnell wie möglich Daten draufpackt fällts das deutlich auf. In der Gegenrichtung ist hingegen alles okay … 710MBit!? Deshalb habe ich anschließend alle Tests mit iperf und 3 TCP Sockets wiederholt um meine Vermutung zu untermauern.

Aus den Benchmarks habe ich interessante Dinge gelernt:
  • Routern bringt es (fast) garnichts wenn man AMD64 statt i386 einsetzt
  • pf kostet bis zu ca 10% Performance
  • FreeBSD 7.0 wird ein grandioses Release
  • ich brauche ordentliche Netzwerkkarten für weitere Tests (sind schon bestellt)



AMD Athlon64 3200+ 1GB DDR PC3200 Elitegroup ECS-nForce4-A939

nfe0: NVIDIA nForce4 CK804 MCP9 Networking Adapter (onboard) re0: Realtek RTL8110SB (PCI 32Bit, 33Mhz)



 netperf iperf
OSnfe0 > re0re0 > nfe0nfe0 > re0re0 > nfe0
FreeBSD 7.0 BETA3 i386783-643-
FreeBSD 7.0 BETA2 AMD64782738646635
OpenBSD 4.2 i386576661564626
OpenBSD 4.2 AMD64180710602621
Linux i686687730605628
Linux i686661740591633
FreeBSD 6.2 i386657-651-
NetBSD 4.0 RC3 i386614655597602

GBit Routing with BSD [Part1]

Da ordentliche ordentliche GBit Router viel zu teuer für mich sind bin ich derzeit auf der Suche nach einer möglichst stromsparenden (da 24/7 Betrieb zuhause) Lösung die annähernd 1GBit routen kann.

Meine ersten Benchmarks haben mich deshalb dazu geführt erstmal alle GBit Karten auszuprobieren dir mir zur Verfügung stehen. Das Resultat ist recht eindeutig. Mit billigen PCI GBit Karten erreicht man meist um die 500MBit. Wenn man mehr will sollte man etwas Geld in Intel PRO/1000 Server Karten investieren (oder einen Blick auf Intel Server Boards werfen).

Der anschließende Routing Test mit pf und netperf hat gezeigt, dass der zusätzliche Overhead durch pf bei dieser Geschwindigkeit nur bei ein paar Prozent liegt. Bei 780MBit/sec konnte ich einen Athlon64 3800+ mit FreeBSD 7 und billigen GBit Karten trotzdem zu 100% mit Interrupts auslasten.

Der Vergleichstest mit OpenBSD 4.2 war eher ernüchternd. Scheinbar passen noch ein paar Einstellungen nicht denn bisher erreiche ich nur 180MBit/sec aber die CPU ist dabei zu 70% idle.

Ein Versuch auf OpenBSD 4.2 i386 zu wechseln scheiterte an verschiedensten Kernel Panics die völlig unmotiviert an unterschiedlichen Stellen beim start auftauchen. Wenn OpenBSD 4.2 AMD64 nicht so problemlos auf der selben Hardware laufen würde könnte man fast an einen RAM/CPU Defekt denken.

Update:Die Kernel Panics sind scheinbar durch die HDD ausgelöst worden denn nach einer Installation auf einer anderen Platte sind sie weg. Das Durchsatzproblem mit 180MBit ist aber weiterhin reproduzierbar allerdings nur in eine Richtung!?

Dell Latitude D830

Ich versuche bereits seit einigen Wochen ein passendes Notebook für mich zu finden. Es ist wirklich schwerer als erwartet wenn man nicht auf "Geiz ist Geil" Qualität steht. Die Anforderungen sind onboard Grafik mit einem (W)SXGA Display und eine Docking Station.

Meine erste Wahl war ein HP nc6320 aber die sind scheinbar in naher Zukunft nicht (mehr) lieferbar also kurzerhand den Preisrahmen etwas erhöht und jetzt ist es ein Dell Latitude D830 geworden. Der hat übrigens auch im letzten c't 17/2007 Notebook Vergleich sehr gut abgeschnitten.
Sobald ich das Notebook habe wird es natürlich erstmal mit FreeBSD-current getestet. Jetzt hoffe ich nur mehr, dass Dell die 5 Wochen Lieferzeit nicht ernst meint.

Update:DELL hat derzeit scheinbar massive Probleme seine Bestellungen rechtzeitig auszuliefern also bin ich wohl nicht der Einzige der wartet.
2. Update: (6.9.)Das Notebook ist laut Dell gerade an den Spediteur übergeben worden. Bestellt am 21.8. - heute um ca 11 Uhr auf Produktion gewechselt und gute 9 Stunden später die Bestätigung, dass es ausgeliefert worden ist. Respekt. Scheinbar läuft es bei Dell wieder. 4.0 setzt auf OpenSource

Nachdem ich Ende August bereits die meiste Hardware meines kleinen Netzwerks umgestellt hatte ist nun auch die Software fertig umgestellt.

Das wichtigste war mir dabei, dass ich möglichst unabhängig von ClosedSource Produkten werde. So laufen mitlerweilen alle Server und 2 Clients unter FreeBSD 6.1 sowie ein Router unter OpenBSD 4.0. Als Desktop-Umgebung kommt auf den Clients dabei das schlanke Xfce 4.2 zum Einsatz.

Mein WLAN Access Point läuft unter OpenWRT und ist somit ebenfalls frei von ClosedSource. Sogar mein IPod mini (1st Generation) läuft mit einer OpenSource Firmware namens Rockbox die sich nicht auf iTunes und MP3 versteift sondern einem die freie Codec Auswahl überlässt.

 Zugegeben es war viel Arbeit um ohne ClosedSource Produkte auszukommen aber das war es definitiv wert. Für Notfälle habe ich zwar noch einen Windows Rechner herumstehen da es leider immer wieder Kleinigkeiten gibt die unbedingt ein Windows verlangen aber er wird nur mehr sehr selten benötigt.

Die Belohnung dafür ist eine zuverlässige und vollkommen transparente Arbeitsumgebung die einem keine unnötigen Einschränkungen macht. Außerdem kann man sich selbst helfen wenn es mal irgendwo klemmt oder man muss eben auf Patches warten.