Daily Archives: 6. October 2007

OX5 – Login Problem mit Konqueror – Nachtrag II

Posted on by

Es ist nun schon einige Zeit ins Land gegangen, seit das zuletzt beschriebene Login-Problem unter dem Browser Konqueror aufgetreten ist. Es gab auch einen erfreulich regen Austausch mit einem der KDE-Entwickler.

Leider haben die bisherigen Korrekturen zum korrekten Parsing von HTTP-Headern das Problem nicht behoben. Im Moment steht nur soviel fest:

1) Meine eigenen Tests in unserem Firmennetzwerk (mittels einiger PHP-Programme und einer Paketanalyse mit Wireshark) zur Interpretation von HTTP Redirect-Anforderungen (Refresh, Location – Direktiven) durch den Browser Konqueror sind alle positiv verlaufen. Daran scheint es also nicht zu liegen.
2) Die vom OX5-Server im Redirect angeforderten Cookies werden korrekt gesetzt. Der xhtml-Inhalt der HTTP – Refresh-Anforderung an den Browser wird korrekt dargestellt – der Refresh wird jedoch nicht mehr durchgeführt. Es wird kein entsprechendes HTTP GET – Paket an den Server zurückgesandt.
3) Das Problem tritt definitiv erst nach der ab Version 3.5.7-64.1 des kdebase3- bzw. des kdelibs3-Paketes auf. Nachweislich nicht nur auf meiner Installation. Es hat auch nichts mit der bei uns eingesetzten 64Bit Architektur zu tun.
4) Es ist unklar, wie Konqueror mit “chunked” Inhalt der HTTP-Pakete umgeht (“Transfer-Encoding: chunked”). Interessanterweise versendet der OX5 Server seine Mitteilungen an den Browser auf diese Weise. Mir drängt sich ein wenig der Verdacht auf, dass es evtl. ein Konqueror-Problem geben könnte, wenn die vorgegebenen “chunks” alle in einem einzigen IP-Paket Platz finden. Aber das müssen die KDE-Leute herausfinden.

Zusatzanmerkung:
Angesichts der seit 11. August geltenden Rechtslage (Strafrecht §202c) möchte ich betonen, dass eine gründliche Analyse des Problems eigentlich nur unter Beobachtung des Paketaustausches zwischen Client und Server möglich ist. Ich habe mir deshalb wegen der neuen Gesetzgebung als Inhaber der Firma selbst und höchst offiziell die Erlaubnis erteilt, in meiner zweiten Rolle als Administrator die Paketverfolgung in unserem firmeneigenen Netzwerk temporär und auf 2 Rechner begrenzt durchzuführen und danach alle eingesetzten Hilfsmittel wieder von den Systemen zu entfernen.

Wer das für schwachsinnig hält, hat zwar irgendwie Recht, möge sich aber bitte mal mit der neuen Rechtslage auseinandersetzen – danach stellt womöglich allein der Besitz von solchen Analyse-Tools ein Gesetzesvergehen dar (siehe etwa entsprechende Artikel in den letzten Ausgaben des Linux-Magazins oder aber aktuelle Artikel im PC Magazin) .

Diesem Wahnsinn haben übrigens alle Parteien außer der PDS im Bundestag zugestimmt. Wer also gegen die völlig diffuse Ausformulierung des §202c noch nicht beim Bundestagsabgeordneten seines Vertrauens protestiert hat, sollte dies nachholen. Hier ist insgesamt eine sehr ungute Entwicklung im Gang, die man als IT-Fachfrau oder -mann und als Demokrat nur mit allergrößtem Misstrauen beobachten kann. Hierzu schreibe ich aber bei Gelegenheit einen separaten Beitrag.

VMware und Athlon Dual Core Prozessor – Tipp 1

Posted on by

VMware und Athlon Dual Core Prozessoren – Teil 1: Nutze nur einen (virtuellen) Prozessor !

Ich gebe hier meine Erfahrungen mit der Installation von VMware (Workstation Versionen 5 und 6) auf einem Athlon X2 4800+ Prozessor unter Linux (Opensuse) wieder. Linux ist dabei also das sog. VMware “Host”-System”. Als “Gast-System” kam Windows XP SP2 zum Einsatz.

Wenn man eine virtuelle Maschine unter VMware aufsetzt, hat man auf einem Host-System mit einem Dual Core Prozessor die Möglichkeit, dem Gast-System 1 oder 2 (virtuelle) Prozessoren zuzuordnen. Nach etlichen Versuchen mit der Auswahl von 2 (virtuellen) Prozessoren bleibt festzuhalten:

Finger weg von einem Setup mit 2 virtuellen Prozessoren!

Hierfür gibt es vor allem zwei Gründe:

1. Unnötig verschlechterte Perfomance des Gesamtsystems durch Verwaltungsoverhead
Vor allem die Performance des Hostsystems leidet bei einem solchen Setup. Wie man diversen Beiträgen im Workstation-Forum von VMware entnehmen kann, wird das System mit den Verwaltungsaufgaben zur

  • Verteilung der Gastsystemlast zwischen den virtuellen Prozessoren und
  • der resultierenden Verteilung der Host-System-Last auf die 2 realen Prozessorkerne

insgesamt über Gebühr belastet. (Das wirkt sich natürlich dann auch auf die Performance des Gastsystem aus.)

In meinem Fall drängte sich oftmals der Eindruck auf, dass das System deutlich mehr mit der Auflösung der Anforderungen aus der Lastverteilung – also mit sich selbst – beschäftigt war als mit dem Abarbeiten von Applikationsanforderungen im Gast- oder Hostsystem.

Ich habe z.T. eine durchschnittliche Auslastung von 50% im Host-System gesehen, die durch Systemprozesse verursacht wurde, während sowohl im Windows-Gastsystem als auch unter Linux die Auslastung durch Userprozesse kleiner als 10% war. Die Aufgabe der Abstimmung von Lastverteilungsanforderungen zwischen Gastsystem und Hostsystem ist nach meinem Eindruck (noch) nicht optimal gelöst. Manchmal konnte ich ein fast zyklisches Hin- und Herschaufeln der Last zwischen beiden Prozessorkernen beobachten. Es war so, als ob eine Entscheidung des Gastsystems zur Lastumverteilung eine gegenteilige Reaktion des Hostsystems und diese dann wiederum die umgekehrte Reaktion im Gastsystem hervorrief. Ein solche Interpretation würde die beobachtete permanente (und völlig überflüssige) zyklische Lastumverteilung zumindest im Ansatz erklären.

VMware selbst rät übrigens wegen der Gefahr einer verschlechterten Gesamtperformance von einem Setup des Gastsystems mit 2 (virtuellen) Prozessoren ab. Der übliche Kommentar ist, dass dies nur auf größeren als Quadcore-Systemen sinnvoll sei.

Verschärft wird das ganze ggf. auch noch durch Bedingungen, wie Sie nachfolgend beschrieben werden.

2. Taktung und Schwierigkeiten mit der Synchronisation der Prozessorcores
Nach einigen Recherchen im Internet kommt man zu dem Schluss, dass bestimmte frühe Baureihen des AMD X2 Prozessors das Manko aufweisen, dass die Cores unabhängig voneinander getaktet wurden. Jeder Core hat(te) sozusagen seinen eigenen Zeitgeber. Applikationen, die die CPU-Zyklen der Cores abfragen, haben damit erhebliche Schwierigkeiten, wenn das Betriebssystem zwischenzeitlich die Last zwischen den Cores umverteilt: die Applikation erhält dann ggf. eine andere Antwort zum Zyklus, als sie erhalten hätte, wenn die Applikation auf dem ursprünglichen Core verblieben wäre.

Bei den ersten 5er-Versionen der Workstation hatte ich den Eindruck, dass dies der Grund für Instabilitäten im Gastsystem war, wenn man VMware linuxseitig nicht genau einem – und zwar dauerhaft ein und demselben – Prozessorkern zuordnete. Die Einschränkung, VMware dauerhaft einem Prozessorkern zuzuweisen, gilt heute nach meiner Erfahrung jedoch nicht mehr.

Fazit: Man sollte dem (virtuellen) Gastsystem im Setup
genau eine (virtuelle) CPU zuweisen.

In einem weiteren Beitrag werde ich darstellen, wie man die Frequenz der CPU ermittelt und im VMware-Setup der virtuellen Maschine als feste Größe verankert. Damit lassen sich Probleme umgehen, die die vmware-seitige eigenständige Frequenzbestimmung hervorrufen kann. Bei der Gelegenheit werde ich auch erläutern, wie man VMware bei Bedarf genau einem Prozessorkern zuweist.