Im Admin Panel war zu erkennen, dass in dem Schritt ‘Front End user initialized’ die gesamte Zeit verloren ging. Leider konnte ich über Typo3 das ganze nicht weiter aufschlüsseln, sodass ich mich daran machte Debug Kommentare in den Sourcecode einzubauen. Nach etlichen Reloads der Seite hatte ich es geschafft das Ganze Problem auf die PHP Funktion uniqid(), welche zur Erzeugung einer eindeutigen SessionID innerhalb von Typo3 verwendet wird einzugrenzen.

Aus dem Typo3 Problem wurde somit ein PHP Problem. Etwas Googlen brachte zu Tage, dass andere das Problem auch kennen und die PHP Entwickler der Meinung sind, dass es kein Bug sei.Dennoch habe ich ein kleines Testskript verfasst, welches uniqid() ausführt und siehe da: manchmal ging es ruckzuck, manchmal (etwa jeden fünften Aufruf) brauchte es 10 Sekunden.

uniquid() verwendet unter Linux intern die Userspace Funktion usleep() der glibc. Für diese Funktion gibt es auch ein Äquvivalent auf der Kommandozeile. Der Aufruf von ‘usleep 1′ sollte eigentlich nur 1 usec andauern, bei mir blieb er ab und zu allerdings bis zu 10 Sekunden beschäftigt, eben analog zu der PHP Funktion in meinem Testskript.

Also ein Problem der libc? Daran mochte ich nicht glauben. Abgesehen davon, dass die Funktion als deprecated gekennzeichnet ist, ist sie doch schon recht lange präsent und von zentraler Verwendung – ein Bug erschien mir nicht sehr naheliegend.

Weiteres Googeln brachte mich zum Kernel und seinen verschiednen Clocksources. Der Linuxkernel bietet im Allgemeinen drei mögliche Quellen für 32Bit Systeme an: HPET, TSC und PIT. Die installierte CentOS 5.4 Distribution selektiert beim Booten  automatisch TSC als Clocksource, weil diese performant und zuverlässig ist. Leider funktioniert diese nicht so sehr zuverlässig mit AMD Prozessoren, was eine kleine Recherche im Internet zu Tage brachte. Es gibt von AMD einen kleinen Artikel (allerdings zu RHEL4) bezüglich dieses Problems.

Darin wird beschrieben, dass es bei K8 Kernen zu Problemen mit dem Powermanagement und TSC kommt, da die CPU Taktrate variiert und TSC auf Basis dieser arbeitet. Bei SMP soll es wohl auch Probleme mit TSC und K8 Kernen geben. Das Ganze hat nicht zu 100% auf mein Szenario gepasst, schließlich habe ich CentOS 5.4 (analog RHEL 5.4) im Einsatz und eine Opteron 1212 HE CPU ohne erkennbares Powermanagement, aber ich dachte ein Versuch schadet nicht.

In meinem ersten Schritt habe ich notsc als Kernelparameter angefügt und rebootet. Leider hatte das nicht den gewünschten Effekt. Der Kernel wurde mit der Option CONFIG_X86_TSC kompiliert, weshalb sich tsc laut dmesg nicht abschalten ließ. In meinem zweiten Versuch habe ich notsc durch hpet ersetzt. hpet ist die nicht so performante Clocksource Alternative. Da der Server nun nicht unter enormer Last steht sehe ich hier aber kein großes Problem.

Nach dem Reboot konnte ich erfreut feststellen, dass mein Problem verschwunden war. usleep, wie auch uniqid() funktionierten wieder in einer normalen Geschwindigkeit und auch die Website reagiert nun wieder akzeptabel schnell.

Wer ein ähnliches Verhalten feststellt (uniqid() oder usleep() ist langsam, Typo3 benötigt lange die SessionID zu erzeugen) und eine AMD CPU hat sollte mal Versuchen ‘hpet’ an die Kerneloptionen anzuhängen. Vielleicht hilft es ja.

Also auf zur nächsten ‘Saubillig und noch viel mehr’ Apotheke und eine Webcam nebst Headset eingepackt. Bei der Auswahl habe ich mir nicht viel Gedanken gemacht und einfach ein Paket von Philips geschnappt. Dabei hab ich gar nicht mal so daneben gegriffen. Für ca. 40 Euro hatte ich eine Webcam SPC520NC/00 mit einem Headset SHM2000 erwischt. Das Headset barg keine Stolpersteine, da es lediglich 3.5mm Klinkenstecker bot und keine Extras wie etwa integrierte USB Soundkarten oder ähnliche Späße mit sich brachte. Bei der Cam hatte ich in so fern Glück, dass sie mit dem linux-uvc Treiber funktionierte, der den USB Video Class Standard unter Linux realisiert. Der Treiber ist in einem relativ frühen Stadium, unterstützt aber Webcams nach UVC 1.0 oder 2.0 Standards mehr oder weniger gut. Bei der Philips liegt die Wahrheit irgendwo in der Mitte. Es gibt Bild, aber nur in einer misserablen Auflösung von 160×120 (1/4 VGA). Da die Kamera einen VGA CMOS Sensor hat, sollte da deutlich mehr drin sein, aber auch mit der SVN Version des Treibers war nicht mehr aus der Cam zu holen.

Nachdem ich mich einige Zeit mit der schlechten Qualität begnügt hatte und keine Besserung in Sicht war habe ich mich nach ausgiebigen Studium einschlägiger Seiten, bewaffnet mit einer Liste von Produktnamen wieder auf den Weg zum nächsten Elektronik Markt begeben. Dort habe ich aber keine einzige Webcam von der Liste finden können. Offensichtlich wechseln die Hersteller ihre Produkte und deren Innenleben mit hoher Frequenz, sodass mir nicht viele Chancen blieben. Auf gut Glück habe ich dann eine Creative Live! Cam Video IM Pro (VF0410) für ca. 40 Euro entschieden. Zu Hause angekommen habe ich sie auch relativ schnell mit dem uvc Treiber zum laufen bekommen, sogar in VGA Auflösung (640×480) und mit einem tollen Bild. Zwei akute Probleme fielen mir sofort ins Auge – einmal startet die Wiedergabe nur manchmal und es erforderte mehrere Versuche bis die Cam überhaupt ein Bild lieferte, zum anderen war die Ausgabe sehr zäh. Der größte Hammer war dann aber, dass mit Skype die Cam gar nicht arbeitete.

Die Recherchen bzgl. der Verweigerungshaltung von Skype ergab, dass Skype keine Videoquellen im MJPEG Format akzeptiert. Nun gibt es aber einige Cams, die ausschließlich MJPEG liefern, was die Auswahl weitereinschränkte – in meinem Fall die Unsicherheit, denn auf keiner Webcam steht welches Format sie liefert, oder die USB Vendor und Product ID, was einem Linux User doch erheblich helfen würde. Ich meine ich erwarte ja nicht, dass Sie draufschreiben ‘Läuft auch mit Linux’, aber die USB ID sollte ja keinen Riesenaufwand erzeugen und man kann dann relativ schnell bestimmen, ob eine Cam unter Linux läuft oder nicht. Ganz toll wäre es ja den Treiber zu vermerken, wenn das Ding unter Linux tut. Ich gebe zu: das ist etwas zu sehr Kundenfreundlich.

Nach diesen zwei Tagen exzessiven Testens habe ich mich also erneut aufgemacht und den ‘Saubillig’ Markt aufgesucht. Diesmal habe ich lieber keine aus dem Regal genommen, denn es war keine da, die auf meinen Listen als 100% funktionsfähig verzeichnet waren. Kurz vor dem Ausgang entdeckte ich dann in der Krabbelkiste die Hercules Classic Webcam für 11 Euro. Die hab ich dann doch noch eingepackt, trotz schlechter Vorahnung.

Diese Vorahnung wurde jedoch nur teilweise erfüllt, denn auch diese Cam liefert eigentlich nur MJPEG. Jedoch haben sich ein paar Jungs hingesetzt und den Treiber um einen Videoconverter für diverse Formate aufgebohrt. Der Treiber erhielt den Namen ov51x_jpeg. Mit einem kleinen Patch funktioniert damit dann auch Skype damit – endlich auch mit VGA Auflösung. Da der Treiber im Kernelspace Videokonvertierung durchführt ist er natürlich in der Community nicht gerne gesehen, aber er funktioniert und erfüllt seinen Zweck. Skype erzeugt bei mir etwa 10% CPU last auf einem Athlon64 3000+, was verschmerzbar ist. Der Treiber ist mir bisher nur einmal mit einem Kernel Oops ausgestiegen – man kann wohl nicht alles haben. Was an der Kamera jedoch massiv stört ist, dass man das Hilfslicht nicht deaktivieren kann. Diese schaltet sich ab einer gewissen Helligkeit zu und lässt sich zumindest unter Linux nicht abschalten. Ich werde die Cam mal unter Windows test und prüfen ob es dort geht. Wenn ja lassen sich die entsprechenden USB Kommandos sicherlich herausbekommen und in den Treiber einbauen lassen. Die Cam macht auch insgesamt einen guten Eindruck. Sie hat ein Metallgehäuse, ein anständiges Gewicht und eine richtig gute Klammer, die auch als Standfuß fungieren kann.

Fazit: Nicht immer ist die teuerste Cam die Beste – die billigeren Versionen mit vermeindlich veraltetem Innenleben haben evtl. die größeren Chancen Support unter Linux zu haben. Mit der Hercules bin ich einigermaßen zufrieden, zumal sie für den Preis eine ausgesprochen gute Verarbeitung bietet.

UPDATE: Ein erneuter Versuch mit der Philips Kamera an einem anderem System verlief erfreulicher. Dort liefert der UVC ein Bild mit 640×480 Pixel, was der nativen Auflösung des Sensors entspricht. Warum die  Kamera an meinem System nicht korrekt funktioniert bleibt ersteinmal unklar. Nach einigem Hin und Her habe ich auch das USB Audio Device der Philips (sprich das Mikrofon) zum Laufen gebracht, allerdings nur theoretisch. praktisch kommt keine Aufnahme in Skype damit zustande. Damit zieht die Philips gleich mit der Hercules Kamera, ja ist sogar eine Idee besser, da sie keine zusätzlich MJPEG zu YUVY Konvertierung benötigt und direkt mit Skype arbeitet.

Solangsam glaube ich sogar, dass es gar nicht geht.

das ganze war mit top schnell gefunden – der rpc.mountd belegte ca. 500MB und damit fast den gesamten speicher. ursache ist ein memleak in den aktuellen gentoo stable ebuilds von net-fs/nfs-utils-1.0.12 und sys-fs/e2fsprogs-1.39. laut gentoo bug id 172014 und 171844 sind die entsprechenden patches in die ebuilds net-fs/nfs-utils-1.0.12-r3 und sys-fs/e2fsprogs-1.39-r2 eingeflossen.

diese packages sind allerdings noch als unstable gekennzeichnet. ich hab die neuen versionen nun am laufen und hoffe das leck jetzt gestopft zu haben.