FreeBSD & Performance - Ein Vergleich

Status
Für weitere Antworten geschlossen.
Lieber Endorphine,

deine Kritik ist leider absolut fehl am Platz. Du verallgemeinerst in unzulaessiger Art und Weise wenn du behauptest, dass sich der Inhalt dieses Threads auf ein "Frueher war alles besser"-Gejammer herunterkochen laesst. Lies ihn doch mal von Anfang an (so wie ich zum Beispiel) und du wirst feststellen dass juedans Beobachtung nur eine Ergaenzung zur Grundaussage "Es existiert ein Problem innerhalb der FreeBSD-Struktur" darstellt. Der Kern des Threads ist aber in der Tat ein anderer.
Und zwar der, dass bekannte Probleme nicht behoben werden. Mit deiner allerdings fast schon persoenlichen, nicht faktbezogenen, Kritik zerstoerst du allerdings die Diskussion innerhalb dieses Fadens zugunsten einer "Ich habe Recht"-Argumentation. Muss das sein? Du hast nichts weiter beigetragen als die Diskussion, die an realen Loesungsansaetzen orientiert war, zu unterbrechen und eine hitzige, emotional gefuehrte Argumentation loszutreten. Das ist in meinen Augen reine Trollerei. Ich hoffe du bist stolz auf dich.

An alle anderen: lasst uns zum Kern des Threads zurueckkehren. Steve`, ich bin sehr auf deinen Entwurf gespannt.
 
Nix mein Entwurf, Kamikaze wollte pinseln. ;) Dauert aber noch bis Weihnachten. Egal, hauptsache, das Thema kommt mal sachlich und konkret zur Sprache. Wenn das dann auf den Mailinglisten nicht thematisiert wird, fällt mir auch nichts mehr ein.
 
Das Problem ist auch, dass FreeBSD offiziell um und bei 200 Commiter hat. Die die ich regelmäßig auf den Mailinglisten sehe, kann ich leider an einer Hand abzählen :(
 
Steve` schrieb:
Egal, hauptsache, das Thema kommt mal sachlich und konkret zur Sprache. Wenn das dann auf den Mailinglisten nicht thematisiert wird, fällt mir auch nichts mehr ein.
Zum Vergrößern anklicken....
Vielleicht ganz interessant in dem Zusammenhang sind zwei Mails auf stable@ von dieser Woche:
http://docs.freebsd.org/cgi/getmsg....e/2007/freebsd-stable/20071223.freebsd-stable
http://docs.freebsd.org/cgi/getmsg....e/2007/freebsd-stable/20071223.freebsd-stable


Ich kann die Probleme von Steve` mittlerweile auch nachvollziehen -- ich hab hier noch 7.0-PRE laufen, durch die "richtige" Kombination von Festplattenzugriffen und rechenintensiven Sachen kann ich das System so weit ausbremsen das auf einen Mausklick/eine Tastatureingabe ewig nichts passiert... Das ist natürlich sehr subjektiv, das ist mir auch klar.
Es ist halt so daß ich mein System nutzen will und mich nicht mit irgendwelchen Problemen des Systems an sich auseinandersetzen will (da fehlt mir im Moment die Zeit). Und es ist auch nicht sehr erbauend wenn sich jemand hinsetzt und einen Patch schreibt der $Problem löst und der dann eben mal ignoriert/abgelehnt/$was-auch-immer wird. Ich kann es da nur zu gut nachvollziehen wenn derjenige dann frustriert ist...
 
Yamagi schrieb:
Das Problem ist auch, dass FreeBSD offiziell um und bei 200 Commiter hat. Die die ich regelmäßig auf den Mailinglisten sehe, kann ich leider an einer Hand abzählen :(
Zum Vergrößern anklicken....

Commiter zu sein heisst bestimmt nicht ein Programmieräffchen sein der auf der Mailingliste auf Anregungen wartet. Das Projekt ..

Ach was rede ich hier. Der Thread ist ein einziges Messen der Retorischen Fähigkeiten geworden. Macht alleine weiter.
 
Nochmal: Es geht nicht darum, die Qualität der eigenen Rhetorik ins Feld zu führen, sondern einzig und allein darum, die qualitativen Probleme von FreeBSD zu sammeln und mal gebündelt zu thematisieren.

Und das es Probleme gibt, wird auch der letzte Leser mittlerweile gemerkt haben. Das es keine Spinnerei ist, dürfte spätestens dann auffallen, wenn man zusammenfaßt, dass es eher zwei dutzend als ein dutzend Stammuser sind, die derweil von solchen artverwandten Problemen berichten.

Wenn Du keine Probleme mit FreeBSD hast ... schön für Dich. Dann spare Dir doch bitte Kommentare in diesem Thread solange, bis wir das hier sachlich zusammengefaßt und auf die ML gebracht haben. Danach kannst Du mit Deinen Freunden den Thread zerreißen. Danke.
 
Wer behauptet, wir schrieben hier nur um uns gleich den Nürnberger Meistersingern in Rhetorik zu üben und zu messen, der hat entweder diesen Thread nicht gelesen oder aber nicht viel mit FreeBSD zu tun. Wer heute mit Betriebsystemen groß wird, die Abstürze und Fehlfunktionen zur Regel erkoren haben und ein Volk von Mittelmaß seine Qualitätsansprüche demgemäß herabgesetzt hat, wird nicht verstehen, daß man Qualitätseinbußen anmäkelt.

Diejenigen, die seit Jahren privat oder geschäftlich mit den *BSD UNIXen zu tun haben, wissen welche qualitativen Einbußen gerade FreeBSD in den vergangenen 5 Jahren hat hinnehmen müssen! Und diejenigen unter uns, die selber in Projekte eingebunden sind werden wissen, daß es in den meisten Fällen von personellen Fragen abhängt, ob eine Sache gut oder schlecht läuft. Und als Konsequenz hieraus lassen sich nur drei prinzipielle Wege ableiten: man verläßt den Pfad, man beschreitet ihn wie ein Hammel auf dem Weg zur Schlachtbank weiter oder man versucht etwas zu ändern - und sei es nur durch Absenden von PRs und ausgiebiges Testen neuer Lösungsansätze.
 
Ich arbeite immer noch an der Zusammenfassung. Das ist ein langer Thread und die zusammenfassung sollte doch relativ kurz und strukturiert sein, also braucht das wohl seine Zeit.

Zum Thema früher-war-alles-besser-Gejammer. Es ist eine nachweisbare Tatsache, dass es gelegentlich vorkommt, dass Regressionen ignoriert werden, weil niemand zuständig ist und sein will. Das ist kein Hardwareproblem.

Was FreeBSD 7 angeht, die erste Beta war eine absolute Katastrophe, inzwischen läuft es aber prima bei mir. Ich fahre aber auch nur Intel-Systeme.
 
Kamikaze schrieb:
Ich arbeite immer noch an der Zusammenfassung. Das ist ein langer Thread und die zusammenfassung sollte doch relativ kurz und strukturiert sein, also braucht das wohl seine Zeit.
Zum Vergrößern anklicken....
Ja, ist klar, dass da einiges an Stoff und kontroversen Beiträgen zusammengekommen ist. Es kommt unterm Strich ja auch nicht auf die eine oder andere Woche an.

Ich denke Dir jetzt schonmal für Deine investierte Zeit und Mühe ...
 
Nochmal zur WinTV


Hast du mal manpage von bktr gelesen bzw. das ist von 5.0 ..da steht das die Karten über options extra in einen Kompalitätsmodus für Chipsätze Via/Sis etc geschalten werden können.

siehe auch:
/src/sys/dev/bktr/bktr_card.h.

die Werte kann man auch über sysctl steuern


Ich hab keine TV-Karte
 
FreeBSD's problems as seen by the BSDForen.de community

Diese Mail gibt hauptsächlich meine Sicht auf diesen Thread wieder. Ich denke es gibt da von eurer Seite noch einiges gerade zu rücken, bis das verschickt werden kann. Deshalb warte ich jetzt mal auf Feedback von euch. Trotzdem hoffe ich ihr seid im großen und ganzen zufrieden.

--------------------------------------------------------------------------------------

Hello,

I'm writing this mail on behalf of the largest German BSD community
(http://bsdforen.de/). Some of our most respected and experienced community
members have stopped using FreeBSD entirely, especially professional users have taken this step.

Many of us are very attached to FreeBSD and those of us who turn our backs to
the system consider this a personal loss.

This mail is the result of a forum thread that consists of more than 200 posts
(still growing) that started in October 2007
(http://www.bsdforen.de/showthread.php?t=19426). It is meant to sum up the
causes of this development, the reasons we see for this and what we think
might be promising ways to try solve these problems; at least in the areas we
were able to achieve consent.

The first problem is the unbearable performance many AMD users are suffering
for several chipset and CPU generations. Even minimal I/O load on a hard disk
suffices to lock up whole systems. Posts on the mailinglists current and
stable have often been answered with denial or have simply been ignored. Only
on very rare occasions (if at all) have these problems been taken seriously.

The second big problem is the handling of regressions. PRs remain unanswered
or the reporters are told that the regressions they report do not exist. Some
of our members have even suffered the experience that they developed a patch,
but it simply was ignored or turned down for the reason that it was a "Linux
solution". Especially frustrating for those among us who have never looked at
Linux code.

These problems seem to be exceptions, but they are very persistent exceptions.
Problems concerning code that is currently being worked on are shown much
attention, feedback and patches are happily taken and the developers supply
the problem reporter with steps to take in order to track down these problems.

The problem seems, in our opinion, to reside with unmaintained code. It seems
that nobody wants to take responsibility for code that has been untouched for
a longer period of time. This is quite understandable, considering that
developers already have projects they're working on and probably consider much
more important, but that does not make it less of a problem.

What we think might be a solution to the regression problem, would be the
establishing of a Regressions Team, similar to other teams like the Security
Team. The sole purpose of this team would be to take care of regressions that
concern unmaintained code.

To solve the performance problems it appears to us, that a guide to tracking
performance problems or a performance test suite is required. This would
hopefully allow us to write PRs and emails that would be taken more seriously.

- Dominic Fandrey on behalf of BSDForen.de community
 
Zuletzt bearbeitet:
Klingt gut. Wenn du es abschickst würde ich die BSDForen.de-Adresse nutzen. Du musst sie zwar erst beim Mailman registrieren, wenn du noch nicht hast, aber es wirkt professioneller und offizieller als Gmail, GMX und Konsorten :)
 
Ich finde auch, das es eigentlich die Sache auf den Punkt bringt und nicht zu dreist ist, sondern einfach ein Hinweis an die Entwickler.

Eine Kleinigkeit, die ich beim Überfliegen gesehen habe:
many AMD users are suffering for several chipset ans CPU generations.
Zum Vergrößern anklicken....
# sed s/ans/and/ ;)
 
Hi,

prinzipiell finde ich den Text gut, zwei Ergänzungen hätte ich aber doch:

Die Performance-Probleme auf AMD Systemen könnte man vielleicht etwas genauer erläutern. Es geht hier ja speziell um das Verhalten einer Desktop-Umgebung unter Last, nicht etwa um die Compile-Dauer von KDE oder irgendwelche MySQL-Benchmarks. Ich fände es auch sehr sinnvoll, wenn die Betroffenen erst noch das von Kris Kennaway erwähnte Tool benutzen (falls das manche nicht schon probiert haben? Ich habe davon auf jeden Fall das erste Mal gehört).

Achja, waren das wirklich nur AMD Systeme mit diesem Problem?

Als zweiten Punkt würde ich irgendwo deutlich erwähnen, dass uns klar ist, dass es OpenSource Projekten meist nicht an Ideen, sondern an Leuten mangelt. Ansonsten kriegen die Entwickler womöglich einen fiesen Ausschlag, wenn sie zum x-ten Male irgendwelche gut gemeinten Ratschläge hören, was sie alles besser machen könnten ;-) (mir ist im übrigen klar, dass euch das klar ist (:-P), aber ich wäre da lieber etwas übervorsichtig).

*örgs* .. ich hoffe mal, die email geht nicht daneben. Wir kennen den kompletten Hintergrund + die Personen und können den "Tonfall" wunderbar abschätzen. Ob das bei der FreeBSD-Mailinglist genauso ankommt, wie wir es meinen?

Ciao, Tobias
 
Hallo Kamikaze,

danke für Deine Arbeit. Es ist ein sehr guter Text geworden.
Bin mal auf die Reaktionen gespannt.

Viele Grüße
JueDan
 
@TobiasM
Was die AMD-Performance angeht, ist das wohl kein Problem des Schedulers (dann wären, nach meiner unqualifizierten Meinung, alle Architekturen betroffen). Deshalb ist dieses Werkzeug nicht weiter relevant hier. Es geht in der Mail auch mehr um die allgemeine Richtung als um einen bestimmen PR.

@juedan
Vielen Dank, ich werde wohl noch ein zwei Tage warten, bis ich sie verschicke. Vielleicht sogar länger, je nach dem wie das Feedback hier ausfällt.
 
Mein Impuls war es das kursiv zu schreiben - wie bloß? Aber Anführungszeichen sind eine gute Alternative, danke!
 
Ich würde eventuell nochmal nach belegbaren Beispielen für die "Vorwürfe" bzgl. ignorieren von Performance Problemen bzw. ablehnen von Patches suchen ( ML Einträge ) um einer Diskussion vorzubeugen.

Keine Ahnung ob diese Beispiele schon im Thread enthalten sind, aber es wäre auf jeden Fall besser das ganze mit ein paar Fakten untermauern zu können, nicht das die Diskussion nachher losgeht und wir keine Fakten zum untermauern haben.

Ansonsten sehr gut formuliert und besten Dank für die Mühe.
Bin schon gespannt auf die Antworten.

Gruß, Cessel
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben