FreeBSD & Performance - Ein Vergleich

[troll]

Huhu,

Meines Erachtens ist und bleibt das eine Frage der Motivation.

Ja, das denke ich auch. Ich hab da sogar eine ziemlich esoterische Meinung dazu, nämlich das die verstärkten Streitigkeiten und ideologischen Grabenkämpfe eine starke Verantwortung dafür tragen.
Die BSDs sind unter anderem wegen der freien Lizenz meine Favouriten. Diese freie Lizenz sollte eigendlich Streitigkeiten verhindern und tut dies auch zu einem sehr grossen Teil. Ich weiss als Projektleiter, wie stark menschliche Schwierigkeiten die Produktivität einer ganzen Gruppe schaden können. Nein, ich gehör nicht zu den Leuten, die Blumenpötte in Büros vorschreiben ;-)
Was meiner Meinung fehlt ist wieder eine anständige Motivation ein grossartiges System zu bauen und *zusammen* daran zu arbeiten. Also das Fieber seine Arbeit gut zu machen, dass es auch ermöglicht mal ne Zeitlang im Dreck zu wühlen und stolz drauf zu sein. Ein Freeze muss dazu nicht unbedingt notwendig sein.
Der Motivationswert der Mail in der FreeBSD-Liste wäre vielfach stärker, wenn nur die ersten paar Antworten gekommen wären und die Grabenkämpfe danach aussen vor wären.
So ist es für einen Entwickler frustrierend. Kritik kommt so an, wie es sich ein Entwickler wünscht und dann bricht darüber der Wahnsinn los. Im Endeffekt stehen die Entwickler, die Kritik aufgeschlossen gegenüber stehen mit Kritik da und einem endlosen Thread, in dem es überhaupt nicht mehr um ihre Arbeit geht. Das ist frustrierend und unproduktiv, weils einfach nicht Zielorientiert ist.

 

[keydex]

Es ist wirklich traurig...also ich habe mir den ganzen Thread von Anfang bis Ende durchgelesen.
Ich hatte vor demnaechst ein AM2 System als Desktop aufzubauen auf dem FreeBSD laufen sollte. Jetzt weiss ich echt nicht mehr weiter.
Muss ich denn wirklich eine Intel CPU nehmen um mit FreeBSD arbeiten zu koennen....

 

[troll]

Muss ich denn wirklich eine Intel CPU nehmen um mit FreeBSD arbeiten zu koennen....

Nein! Du musst dich aber genauestens vor dem HW-Kauf informieren, ob das Gerät zu denen mit den Problemen gehört. Ich schreib das hier grad auf ner 2XOpteron Worstation auf Tyanboard. Das Dingen rennt wie Hulle.

 

[keydex]

Ich habe mich leider ungenau ausgedrueckt. Es scheint als sei die Fehlerquelle der Chipsatz.
[Ich wollte AMD CPU's nicht schlecht reden. ]

 

[cryptosteve]

Naja, irgendwo klemmt es möglicherweise immer. Ich habe mich vorher genau zu Chipsätzen informiert und mich dann letztlich für einen nForce entschieden. Der läuft soweit auch super, die Performanceprobleme sind deutlich geringer als vorher; woran es unterm Strich nun auch letztlich liegen mag.

Jetzt ruckelt sich die TV-Karte auch im idle tot ...

 

[peterle]

So ist es für einen Entwickler frustrierend. Kritik kommt so an, wie es sich ein Entwickler wünscht und dann bricht darüber der Wahnsinn los. Im Endeffekt stehen die Entwickler, die Kritik aufgeschlossen gegenüber stehen mit Kritik da und einem endlosen Thread, in dem es überhaupt nicht mehr um ihre Arbeit geht. Das ist frustrierend und unproduktiv, weils einfach nicht Zielorientiert ist.

Denn sollte man das ganze moderieren ...

 

[juedan]

Hallo Steve`, hallo @all

Ich hatte vor einigen Jahren ja mal die Idee, eine Community zum Förderzweck zu gründen (BSDTeams, für die, die sich noch erinnern). Der Grundgedanke war, Klein(st)beträge zu sammeln (z.B. durch Spenden) und den Entwicklern so finanzielle Anreize zu bieten. Außerdem wäre es möglich gewesen, Anwendern eine Basiscommunity zu geben, mit der sie sich identifizieren können.

Da bin ich gerne bereit mitzumachen, WENN etwas vernünftiges bei rumkommt. Will heißen, dass Entwickler des Core-Teams dann auch mal zuhören, von ihrem Thron herabsteigen und nicht so tun, als nur sie die Sprache C kennten.
Dafür bin ich auch bereit, in eBay Hardware zu ersteigern, um sie dann dem Entwickler zur Verfügung zu stellen. Wie geschrieben, muß dann was bei rumkommen!

Viele Grüße

Jürgen

 

[Yamagi]

Ich weiß nicht, ob es hier neben mir noch Personen gibt, die die Blogs der FreeBSD-Entwickler lesen. Dabei viel mir vor einigen Tagen im Blog von Warner Losh (arbeitet vor allem am Netzwerkstack und Kernellocking und hat sein bestes getan das total defekte USB wenigstens halbwegs repariert zu bekommen) dies hier aufgefallen: http://bsdimp.blogspot.com/2008/01/random-acts-of-kindness.html Wichtig ist vor allem der letzt Satz, der zeigt, dass es nicht viel brauch um seine Dankbarkeit auszudrücken. Das schon eine kleine Geste ausreicht um Menschen zu einer weiteren Arbeit zu bewegen.

Ansonsten haben wir die schon angesprochenen Probleme. Performance hat das Problem, dass die hier angesprochenen Dinge nur auf selektierter Hardware auftauchen. Ich musste wirklich tief in der Kiste graben, bevor ich ein Mainboard gefunden hatte, auf dem ich die Einbrüche wenigstens ansatzweise nachvollziehen konnte. Hardwarespenden betroffener Komponenten wären daher ein erster Schritt. Ich weiß nicht, ob mein einen Verwendungszweck und Bedingungen stellen kann, dafür muss man sich wohl erst einmal an das Donations Team - http://www.freebsd.org/donations/ - zu wenden.

Zu SCSI habe ich noch einmal geschaut. Es sieht wirklich so aus, als sei der einzige Entwickler, der wirklich noch aktiv an CAM arbeitet Scott Long. Ich denke, dass sich das auch nur dann ändern wird, wenn S-ATA auf CAM portiert werden sollte. Dies wurde mal diskutiert, aber ob es dort konkrete Pläne gibt weiß ich nicht. Die meisten Treiber scheinen schlicht tot zu sein. Über die Ursachen kann ich nur spekulieren, aber ich vermute, dass die meisten Entwickler das Interesse verloren haben, da sie kein SCSI mehr einsetzen.
Ich sehe es doch selbst in meiner Tätigkeit hier, das SCSI inzwischen oftmals gar keine Option mehr ist. Es zu teuer, stattdessen bauen wir S-ATA mit doppelter Redundanz und schmeißen die Platten nach ein bis zwei Jahren weg. Auch Solid State wird immer öfter genommen, wenn es um äußerste Zuverlässigkeit und gute Performance geht.
Hier wäre das korrekte Vorgehen wohl eher anzufragen, ob jemand bereit wäre einige SCSI-Treiber zu reparieren oder sogar neu zu entwickeln, wenn er Hardware und eventuell auch Geld zur Verfügung gestellt bekommt.

 

[Elwood]

Yamagi: Danke für den Hinweis auf die Blogs. Ich hab noch nie einen Blog der Entwickler gelesen, weil ich bisher noch nicht darauf gestossen bin. Wie wäre es, wenn man eine Liste?! der Blogs im Wiki einbaut?

Als SCSI-Fan sieht man das Trauerspiel seit Jahren: Die Geräte sind teuer und teilweise kaum noch beim Händler auf Lager. Das beste war, als ich beim HW-Dealer meines Vertrauens die Mitteilung vor 2 Jahren bekam, SCSI wird eingestellt... Schock! (Was sich offenbar nur auf einen Hersteller bezog).

Klar, wenn niemand die HW hat, kann auch niemand die Software dafür warten oder schreiben.

 

[juedan]

Hallo,

auch von mir Danke für den Hinweis auf die Blogs.
Mit geht es da wie Elwood. Ich bin in der glücklichen Lage, die SCSI-Sachen über die Firma ordern zu können, aber das macht es unwesentlich besser.

ABER. Solche Hinweise gehören auf die Homepage von FreeBSD: "Hardware gesucht" "Entwickler gesucht" usw.

Grüße

JueDan

 

[Yamagi]

Eine Liste der Blogs gibt es schon, schaut mal auf http://planet.freebsdish.org

 

[Vincent Vega]

Warum tut RH das bei Linux?
Warum tut das niemand bei FreeBSD?

Red Hat ist ein Unternehmen, dass ein um den Linux-Kernel herum gebautes Betriebssystem produziert und vermarktet. Dazu pflegt Red Hat einen Quasi-Fork des Linux-Kernels. FreeBSD ist ein Projekt, in dem freiwillige und bezahlte Entwickler lose zusammenarbeiten. Du vergleichst Äpfel und Birnen bzw. Diktatur und Anarchie.

Bisher gab's in diesem Thread, meiner Meinung nach, viel zu viele Stimmen die sich über tausend Sachen beklagt haben. Das ursprüngliche Problem, die Performance-Frage, ist wie im Thread auf der Mailingliste schon längst in den Hintergrund gerückt.

Vielleicht kann sich ja jemand von denen, die sich beklagt haben bzw. beklagen, daran machen, die geforderten Informationen zu beschaffen. Es scheint durchaus Leute zu geben, die Euch helfen wollen und vielleicht auch können.

Der Ball ist bei Euch, wenn Ihr ihn nicht zurück spielt lauft Ihr Gefahr als notorische Nörgler dazustehen. Die Motivation Euch dann noch zu helfen wird dadurch nicht steigen.

 

[cryptosteve]

Der Ball ist bei Euch, wenn Ihr ihn nicht zurück spielt lauft Ihr Gefahr als notorische Nörgler dazustehen. Die Motivation Euch dann noch zu helfen wird dadurch nicht steigen.

Wieso "uns"? Es gibt in diesem Thread nicht wenige, die mit dem Thema FreeBSD leider durch sind. Die angesprochene Kritik ist ein Qualitätsmangel von FreeBSD und wir haben angeboten, dem FreeBSD-Team bei der Lokalisierung zu helfen. Sieh es mal so.

Davon abgesehen stand im Thread auf der ML bereits, dass die Performanceprobleme hdd-i/o-indiziert sind, da wird die top-Ausgabe, auf welcher CPU welches Programm läuft, wohl wenig helfen. Mit vmstats habe ich bereits mehrfach um mich geworfen (jaja, hier im Thread, ich weiß), ich erklärte aber auch an anderer Stelle im Thread, dass ich die Probleme aktuell nicht mehr habe und das bitte mal jemand anders ran müßte. Ich wäre dankbar, wenn da jemand, der die Probleme aktuell noch hat, mal tätig werden würde.

 

[juedan]

Hallo Vincent Vega,

ohne jetzt anderen in den Rücken zu fallen oder als Schleimer dastehen zu wollen, bin ich bereit ein Motherboard zu besorgen und dann zu spenden. Die Sache sollte so im März/April passieren, da unser Hardware-Supporter dann wieder erreichbar ist.
Es handelt sich dabei um ein

Siemens Fujitsu Board,
Dual P3 1,2Ghz,
2 x 32Bit PCI, 4x64Bit PCI,
1GB RAM,
onboard LSI 53C1010 U160-SCSI-Chip.

Dieser Chip macht Probleme bei FreeBSD 6 und 7: FBSD bleibt beim Booten stehen. Netzteil und Festplatte müßte der Entwickler dann selber besorgen.

Viele Grüße

JueDan

 

[Eisenfaust]

Ich habe mir die Mail und die Antwort von Kris Kenneway angesehen. Soweit steht eigentlich dort alles drinnen.

Habe heute wieder vor einer zuckelnden und ruckelnden Maschine gesessen, Immer dann, wenn ich ein 'make world' anwerfe oder mit 'rsync' Backups auf eine Sicherungsplatte schreibe oder wenn abends/nachts find hohen HD I/O produziert. Mein Single-Core AMD geht dann richtig in die Knie. Nicht immer an der selben Stelle, aber FBSD 7.0-PRE/RC verschluckt sich einfach zu häufig, als daß man es ignorieren könnte. Von der USB Maus will ich gar nicht erst sprechen.

Das selbe Phanomen, nur in etwas schwächerer Form, da auf leistungsstärkerer Hardware, sehe ich auf einem Q6600 auf einem ASUS P5K Premium mit 8 GB RAM. Der Quad-Core hakelt ebenfalls beim Buildworld (und es ist unabhängig davon, ob ich mit make parallelisiere oder nicht). Es macht auch keinen Unterschied, ob ZFS Laufwerke oder gewöhnliche FFS-Partitionen im Spiel sind.

Kann ich noch etwas beisteuern?

 

[cryptosteve]

Kann ich noch etwas beisteuern?

Wenn Du Zugriff auf eine stark ruckelnde Maschine hast, dann vielleicht einfach mal die von Kris geforderten Daten, damit die Diskussion auf der ML nicht verreckt.

also ein "top -S", ein "vmstat" und ein "vmstat -i" jeweils vor dem Ruckeln und während der Belastung. Dann dann irgendwie als Reply auf die entsprechende Mail in der Mailingliste.

vgl. http://docs.freebsd.org/cgi/getmsg....2008/freebsd-current/20080113.freebsd-current

 

[-Daemon-]

Zu der Mail: Es war fast klar das es so ausgeht... Der A. F. bekommt es immer hin Threads entgleisen zu lassen.


Zu den geforderten Daten: Beim nächsten make world/portupgrade denk ich dran. Wenn wir uns schon bemerkbar gemacht haben sollten wir auch helfen -- alles andere ist der Sache an sich nicht förderlich (und in gewissem Sinne auch unfair, erst "meckern" und dann die Hände in den Schoß legen... Nee nee).

 

[troll]

Zu den geforderten Daten: Beim nächsten make world/portupgrade denk ich dran.

Das ist doch mal was :-)

Wenn wir uns schon bemerkbar gemacht haben sollten wir auch helfen -- alles andere ist der Sache an sich nicht förderlich (und in gewissem Sinne auch unfair, erst "meckern" und dann die Hände in den Schoß legen... Nee nee).

Ich find die Kommunikation im Moment eigendlich ziemlich gut. Die Mail in der ML war konzentrierte Information was los war und hier ausgelagert wird das Vorgehen weiter durchgekaut. Ich fänds gut das beizubehalten. Sprich, sobald Daten vorliegen das konzentriert wieder in die ML zu bringen.

 

[Vincent Vega]

Bin gestern über eine Mail gestolpert, welche die gefühlten Performance-Probleme erklären könnte. Das Problem ist dass der Maustreiber unter dem Giant-Lock steht, während die meisten anderen Systemkomponenten eigene Locks haben. Das Giant-Lock kann aber natürlich nur akquiriert werden, wenn keine anderen Locks mehr gehalten werden. Je mehr andere Locks gehalten werden, desto "länger" braucht es, bis ein unter Giant-Lock stehender Teil des Kernels ausgeführt werden kann. Könnte übrigens auch die "im Idle" ruckelnde TV Karte erklären.

Vielleicht können die Leute mit den hier im Thread angesprochenen Performance-Problemen mal einen Blick auf die Option LOCK_PROFILING werfen.

 

[Kamikaze]

Ich hatte tatsächlich zwischenzeitliche Probleme, die nur dann auftreten, wenn der moused lief. Die Maus in der xorg.conf direkt zu verwenden hat das behoben. Auf einem System ist das Problem wieder verschwunden, auf meinem Notebook, war es bis zu dessen Tod aber noch akut.

 

[Vincent Vega]

Wenn man so drüber nachdenkt, sind die hier im Thread beschriebenen Probleme ja eigentlich auch keine Probleme mit der "Performance" sondern mit "Interaktivität".

Wenn die Maus ruckelt, die Musik hängt oder das TV Bild mehr wie eine Serie von Einzelbildern erscheint, denkt man sofort, der Rechner sei überlastet und deshalb langsam. Ob der Rechner aber eigentlich trotzdem noch in der Lage wäre, mehr Arbeit z.B. in Form eines Web- oder Datenbank-Servers oder eines reinen Rechenjobs (also etwas wofür man Maus/Musik/TV nicht braucht) zu verrichten wird man ja erstmal nicht überprüfen.

 

[Kamikaze]

Nein, die Antwortzeiten an den Netzwerkinterfaces (z.B. ping per Crosskabel) verlängern sich auch deutlich. Das heißt, es dauert durchaus mal über eine Sekunde, bis der Ping beantwortet wird. Die graphische Oberfläche ist lediglich das Merkmal an dem das Problem zuerst auffällt.

 

[cryptosteve]

Bin gestern über eine Mail gestolpert, welche die gefühlten Performance-Probleme erklären könnte.

Die Mail war mir auch aufgefallen. Aber trifft psm nicht nur PS/2-Mäuse? Demnach sollte das Problem bei per USB angeschlossenen Mäusen doch nicht auftreten, oder?

 

[jtsn]

Die Mail war mir auch aufgefallen. Aber trifft psm nicht nur PS/2-Mäuse? Demnach sollte das Problem bei per USB angeschlossenen Mäusen doch nicht auftreten, oder?

Der USB-Stack ist auch GIANT-locked.

 

[cryptosteve]

Der USB-Stack ist auch GIANT-locked.

Ja, genau wie NVIDIA und bktr und damit ist fast die ganze kritische Hardware betroffen.