FreeBSD & Performance - Ein Vergleich

Status
Für weitere Antworten geschlossen.
Hmm, versteh ich was nicht, oder wo ist das Problem?
Hier habe ich gleiche ausgeführt wie jtsn oben. Softupdates ist aktiv.
Und top braucht keine 15 Sekunden. Das geht zack zack.
 
asg schrieb:
Hmm, versteh ich was nicht, oder wo ist das Problem?
Hier habe ich gleiche ausgeführt wie jtsn oben. Softupdates ist aktiv.
Und top braucht keine 15 Sekunden. Das geht zack zack.
Zum Vergrößern anklicken....

Ich hab die Jungs so verstanden, daß man auch noch ein SATA on Board dafür braucht?
Ohne SATA gibts die Probleme scheinbar nicht so stark.

Man mag mich berichtigen wenn das Käse ist. ;)
 
Daten für FreeBSD!

Also Jungs. Ihr habt hier inzwischen 356 Beiträge produziert und einen endlos langen Thread auf freebsd-current@ erzeugt. Hier wurde viel Zeit, Arbeit und Nerven investiert, die man durch aus hätte besser verwenden können. Das Ende vom Lied war, dass man euch bei den Performanceproblemen gern helfen möchte, nur dazu nunmal eure Mitarbeit benötigt. Leider kam bis jetzt von eurer Seite aus nichts, was euer Anliegen ehrlich gesagt nicht in besonders gutem Licht erscheinen lässt. Tatsächlich scheint man sich bereits zu fragen, ob die Performanceprobleme wirklich so schlimm sind.

Also noch einmal, man benötigt von euch:
- top -S
- vmstat -i
- vmstat
Jeweils vor den Problemen, während und besser auch noch mal danach.

Also, noch einmal: Nutzt diese Chance. Sie ist da, man will euch helfen. Wenn ihr jetzt nicht in die Hufe kommt, wird man euch nie wieder anhören und euch ewig als alte Nörgler verschreihen!
 
Meine ergebnisse habe ich gepostet, da ich jedoch nciht generell ein Problem habe, sondern nur bei dem angegebenen dd werde ich mein Ergebnis nicht an die ML posten.
 
troll schrieb:
Ich werde dennoch mal eine Platte direkt an den SATA-Controller anschliessen und mein System draufkopieren.
Zum Vergrößern anklicken....

DONE. Ich kann die Probleme leider nicht reproduzieren und somit auch nicht die Angaben liefern.
Ich möchte aber noch etwas zur Diskussion sagen. Sowohl bei bsdgroup als auch hier wird jetzt die Leute gemeckert, die die nötigen Angaben nicht liefern. Die Kisten von den Leuten werden entweder ersetzt sein, oder darauf wird etwas Anderes laufen, was rennt. Es ist kaum zu erwarten, dass die Leute mit Problemen von dem Ausmass FreeBSD auf den Kisten lassen um damit arbeiten. Ich gehe davon aus, dass die Leute die Angaben nicht mehr liefern können.

Insofern fänd ichs ganz gut mal nicht auf den Leuten rumzuhacken.
Und wenn ich höre, dass sich die deutsche Community damit lächerlich gemacht hat - Lötzinn, das Problem ist existent und hat ne Menge Frust verursacht.
Wichtig ist einfach nur, dass jemand, wenn er auf das Problem stösst möglichst nicht sofort was anderes installiert, oder die Kiste wegbringt, sondern zumindest bitte die benötigten Angaben raussuchen und hier posten.
 
Naja, wenn man so einen Bullshit liest, dann offenbart sich in aller Härte, dass die deutsche BSD-Community ausreichend Probleme mit sich selber hat. Da hat wohl der eine oder andere noch nicht verwunden, dass er bei BSDForen.de nichts mehr ist.

Ansonsten gebe ich Dir recht ... die Probleme mit FreeBSD sind so vielfältig, dass ich schon lange keine Lust mehr habe, da den Lösungen hinterher zu hechten. Meine alte Kiste steht leider nicht mehr zur Verfügung, sonst hätte ich diese Performancediskussion noch mit Fakten zuende gebracht. Auf der neuen Kiste hat's allerdings auch gleich vielfältigste neue Baustellen aufgerissen - da wird sich in Qualitätsfragen nichts nennenswertes mehr tun.

Abgesehen davon ist die von Kamikaze verfaßte Kritik an die Mailingliste nicht dadurch gegenstandslos, dass jetzt keine weiteren Daten geliefert wurden. Möglicherweise ist es ja wirklich so, dass die Kollegen auf current@ die Probleme überhaupt nicht nachvollziehen können. Wäre ja schön, wenn's hier nur eine handvoll Leute ist, die solche Probleme mit FreeBSD hat. Auch bin ich fest der Überzeugung, dass sich solche Probleme auf Serversystemen nicht, bzw. kaum auswirken werden.

Die Mail zu verfassen halte ich trotzdem für richtig, weil unter anderem auch der eklatante Zustand der PR-Verarbeitung diskutiert wurde. Auch das ist im Sande verlaufen, aber das bestätigt nur das in diesem Thread gesagte.

Unterm Strich bleiben ein paar Hände voll Leute, die von FreeBSD geflüchtet sind, ein paar Handvoll Leute, die es weiterhin vergöttern und sich gegenseitig beglückwünschen und die Eier kraulen (nebenan[tm]) und vielleicht einige, die mit Bauchschmerzen dabei bleiben und dem Grundprinzip huldigen.
 
Was ich beim Lesen der Mailingliste mitbekommen habe: Daß die Leute, die fähig sind, die geschilderten Probleme bei FreeBSD zu lösen:

1. kein Deutsch können
2. keine Webforen benutzen

Ergo gar nichts davon mitbekommen.

Die von mir aufgezählten Probleme (Interruptlatenz, ungewarteter Code, Qualität) bestehen unabhängig vom Einsatzprofil (Desktop, Server). Das ist der erste Punkt.

Das zweite Punkt ist, daß die vielzitierte deutsche BSD-Community nicht existiert. Jeder frickelt sich für sich allein rum, pflegt seine eigenen Forks, Austausch findet so gut wie keiner statt. Das könnte man jetzt in eine Lizenzdiskussion ausarten lassen, wie auf der Mailingliste. Ich halte es aber mehr für ein Mentalitätsproblem. Der »kalte Webforen-Krieg« ;) ist da nur die Spitze es Eisberges.

Die deutsche FreeBSD-Community läßt sich in zwei Gruppen unterteilen:

1. die FreeBSD-Fanboys
- die hauptsächlich MacOS verwenden
- die hauptsächlich Windows verwenden
(kriegen daher mangels Praxis von den Problemen gar nichts mit)

2. die produktiven Nutzer
- die FreeBSD ernsthaft auf dem Server oder auf dem Desktop (extrem selten) einsetzen.
- werden von Gruppe 1 angegriffen, wenn sie Kritik äußern
- oder pflegen eh ihren eigenen Fork, der nicht mehr viel mit FreeBSD zu tun hat
 
Steve` schrieb:
Naja, wenn man so einen Bullshit liest, dann offenbart sich in aller Härte, dass die deutsche BSD-Community ausreichend Probleme mit sich selber hat. Da hat wohl der eine oder andere noch nicht verwunden, dass er bei BSDForen.de nichts mehr ist.
Zum Vergrößern anklicken....

falls der thread wegen dieser aussage offtopic wird und geflamed wird, schliessen wir ihn. bitte diesen absatz einfach als flamebait ignorieren.
es ist uns egal was "drueben" gepostet wird, sofern keine persoenlichen beleidigungen geaeussert werden.

gruss
 
Hm.

Bei aller (berechtigten) Kritik an den Bsd-groupies and am momentanen Stand von FreeBSD: Ich finde es auch leicht-peinlich eine solche Mail zu schreiben und dann keine Daten liefern zu können.

Ich denke Kamikaze und Yamagi haben das in guten Gewissen organisiert, weil sie davon ausgingen dass die Probleme AKUT existieren, es also Leute gibt die jetzt gerade hier und heute diese Probleme erleben. Wenn dann die Leute, die sich am lautesten beschwert haben (dazu gehörst auch du Steve) eigentlich garkeine Probleme in der Richtung haben, wirkt das schon komisch.
Von wegen Untergangsstimmung, FreeBSD alles miese. Und die Leute die angeblich ihre ganzen Kunden weg von FreeBSD migrieren? Die müsste ja wohl noch mindestens eine Maschine haben auf der sie die Situation überprüfen können?

Ganz ehrlich, wenn ich ein Dev wäre uind Fehlerberichte in der Art der abgesetzen Mail bekomme und dann NULL Daten, dann würde das meine Motivation PRs zu bearbeiten nicht erhöhen.
An den Organisationsproblemen und PR-Problemen von FreeBSD mag was dran sein, aber die Möglichkeit da was zu erreichen wird erheblich gedrückt durch den Glaubwürdigkeitsverlust den wir aus dem "Performance-Problem" ziehen werden.
:(
 
soul_rebel schrieb:
Ich finde es auch leicht-peinlich eine solche Mail zu schreiben und dann keine Daten liefern zu können.
Zum Vergrößern anklicken....
Da gebe ich Dir recht. Ich frage mich auch allen ernstes, wo sie alle geblieben sind, die meine anfänglichen Probleme noch bestätigen konnten.
soul_rebel schrieb:
Wenn dann die Leute, die sich am lautesten beschwert haben (dazu gehörst auch du Steve) eigentlich garkeine Probleme in der Richtung haben, wirkt das schon komisch.
Zum Vergrößern anklicken....
Nächstes mal werde ich das sicherlich mit der Leitung von BSDForen.de abstimmen, bevor ich mir neue Hardware kaufe und die alte Hardware - bevor sie im Keller verstaubt - verkaufe. Versprochen. Ehrenwort. Wirklich ....

soul_rebel schrieb:
Ganz ehrlich, wenn ich ein Dev wäre uind Fehlerberichte in der Art der abgesetzen Mail bekomme und dann NULL Daten, dann würde das meine Motivation PRs zu bearbeiten nicht erhöhen.
Zum Vergrößern anklicken....
Prima, dann werden vorliegende Patches ja auch in Zukunft ignoriert und nicht bearbeitet. Dann hat der Thread wenigstens den Vorteil gehabt, dass man das hier klarstellen konnte.
 
Abgesehen davon ... da draußen wird ja wohl irgendwo eine Sockel 939 SingleCore-Maschine mit einem AMD Athlon64 laufen? Vielleicht sogar auf einem Asus A8V deluxe? Das war meine alte Kiste, mit der sich die Probleme nachvollziehen lassen.
 
Habe wie schon zu Anfang des Threads geschrieben ein Asus A8V-E SE leider defekt was Tests verfälschen würde und daher werde ich es nicht einbauen, aber was schreibe ich, sollen sich mal die melden, die das Problem nachvollziehen konnten.
 
Kommt doch schon.
Das kanns doch nicht gewesen sein.
Soll die bsdforen - Community jetzt wie Trottels da stehen?

Alle diejenigen die sich ueber Performance Probleme beschwert haben, sollen auch bitte die Informationen fuer die Entwickler bereit stellen!
Also noch einmal, man benötigt von euch:
- top -S
- vmstat -i
- vmstat
Jeweils vor den Problemen, während und besser auch noch mal danach.
Zum Vergrößern anklicken....

Es geht letztenendes um eurer Problem. Man will euch helfen. Seit froh das man euch zuhört. Also antwortet auch!
 
Also, diese Mail an freebsd-current@ wurde in der Absicht geschrieben, Menschen auf die hier geäußerten Dinge aufmerksam zu machen. Kamikaze und Ich haben die ganze Sache organisiert und jetzt endlich durchgezogen, obwohl zumindest ich für meinen Teil die Performanceprobleme nicht habe und die Probleme bei der PR-Abarbeitung schon ein wenig anders sehe. Aber das schrieb ich bereits oben und soll hier nicht das Thema sein. Beim FreeBSD stieß unser E-Mail durchaus auf Interesse, man war sozusagen betroffen. Seit der ersten mail wurde ich im IRC mehrmals von FreeBSD-Entwicklern, die die Probleme im Bereich Performance gern lösen wollen, angesprochen, wo denn nun die Messdaten bleiben. Mehrmals musste ich vertrößten und mehrmals verliefen meine und die Aufrufe anderer hier im Sand. Nachdem ich Vorgestern wieder einmal ein längeres Gespräch hatte und wieder vertrößten musste, fiel im Team die - imo verständliche - Entscheidung die Reißleine zu ziehen. Wir starten einen letzten Aufruf - Beitrag 357 - und als keine Antwort kam, postete Kamikaze wie abgesprochen eine Entschuldigung auf freebsd-current@. Wir sahen darin die einzige Möglichkeit unser Gesicht zu wahren und nicht als ewige Nörgler bezeichnet zu werden. Hierbei ging es, ganz erhlich gesagt, um Kamikaztes Haut, um meine aber vor allem um BSDForen. Isr nunmal blöd gelaufen, aber ich trage für meinen teil trotzdem niemanden was nach.

Aber dennoch hat die Mail etwas bewirkt. Mir wurde bestätigt, dass einige Fehler gefunden und verbessert werden. Auch an der Abarbeitung von PR arbeitet man, wie aus dem Beitrag von Mark Linimon in dem zugehörigen Thread auf der Mailliste unschwer zu entnehmen ist:
On Fri, Jan 11, 2008 at 07:35:41PM +0100, Peter Schuller wrote:
> But understandable or not, the problem becomes particularly frustrating when
> it affects PR:s that contain patches. Such PR:s constitute direct
> contributions to the project. In cases where such patches are correct/good
> enough, the non-application of those patches have what I believe to be
> significant effects.

I think you make some excellent points -- especially with how
understandable it is for someone who's submitted a patch which got
ignored, to not do the work to submit the next one.

With respect to patches, the two things that I've tried -- and they have
been insufficient -- are the following:

- weekly email of "PRs containing patches"

- weekly email of "PRs recommended by the bugbuster team"

We can make the following observations:

- the "push" paradigm doesn't work particularly well. Partly this is
due to fatigue if you try to read through all this stuff (see below).

- the "recommended" list has been slightly effective, but it's going
to take some time for it to take off. For one thing, it has been
underpublicized; for another, we don't have the culture of committers
getting "warm fuzzies" from committing PRs. (Since no one working
on that kind of stuff gets paid AFAIK, that's the only positive
feedback they're going to get.)

Last week someone made the observation that if these things were instead
updated daily and posted to a web page, that it would be far more useful.
I've taken that up as a task.

Your other point about "latest PRs" is also a good one. That should be
relatively easy to do. I'll take up that task.

> * The committer may not be familiar with the code and, even though the patch
> looks good generally, it is felt that someone familiar with that part of the
> system needs to have a look.

In particular, this hurts for areas of the system that are unmaintained.

> What I suggest is a system where a group of non-committers systematically
> pre-process PR:s, to provide feedback and additional quality assurance to the
> committer that is to process the PR.
>
> This group of people could either be a self-proclaimed group of volunteers, or
> perhaps a group of people satisfying the criteria of "guy we kinda trust to
> do testing and provide a useful indication of sanity and correctness, but not
> with a commit bit".

So far it hasn't happened. We've set up the freebsd-bugbusters@ mailing
list and the #freebsd-bugbusters IRC channel on EFNet (and please join
us!) and the latter is where our last 2 bugathons took place.

It's clear that there are several people who want to help process the
PRs, and we don't have a good answer for them on "how can I contribute?".
The existing tool, and social conventions, don't allow for non-committers
to change PR states. As far as we've done in the past is to grant people
"GNATS access" rights but not "commit rights", on an experimental basis.
We've done this twice, and although it has worked well, just two people
isn't enough. (One has gone on to become a full committer -- which is
great!; the other current does not have as much time for FreeBSD work).
Several hundred PRs were dealt with by these two folks, so I consider the
experiment a success.

What we used as a qualification was "track record of responding to PRs and
questions on mailing lists", fwiw.

> One possible answer to this that I have gotten in the past with another
> project, is that noone is stopping me from just grabbing a bunch of PR:s and
> posting follow-ups saying I've tested something, or otherwise giving
> feedback.

Yes, but that's open-loop as well. It's the same situation as with submitting
the patch in the first place: it's going to get frustrating if no committer
picks it up and commits it.

There's not too many people so thick-skinned and persistent as to keep
going forward when no one's using their work.

> For example, patches with a high confidence of correctness due to many people
> affirming that they have tested it could be automatically prioritized for
> committers to deal with, and there will be a clear and systematic record of
> what testing was done, and by who.

Right. The "priority" field in GNATS has been so abused as to become
useless. (People assume that setting it higher will cause some kind of
magic to happen.)

My current thinking is that what committers ought to see is a metric of
correctness, and a metric of priority, _as set by someone who's vetted
the PR_. The weekly mailings are too poor an approximation of either
to be useful.

Adding the second metric would cure one problem that you don't mention --
which is that few people have the interest and patience to plow through
N-thousand PRs. It's not humanly possible to look at them all -- even
the new ones as they come in. There's simply too many. So, you create
an expectation "why bother, there's so many anyways". We need to break
that chain of expectation. A good fix is a good fix. The PR count will
never get to zero; I (with bugmaster hat on) would be thrilled if we can
get to the point of just steady-state.

> When I talk about priority above, I do not mean to imply that any committer
> should work on things they do not want to work on. But I have to assume that
> a lot of patches get committed because a committer decided to go and pick a
> few PR:s to process, rather than the committer necessarily has a burning
> interest in that particular patch.

I think most get committed because a committer sees a PR come in on the
mailing list and grabs it. Much less often do committers go through the
database looking for things to fix. Again, the lousy "search/browse"
capabilities of the existing tool let us down here.

> As such, if said committer could spend those <n> minutes closing five times as
> many PR:s because the up-front confidence in the correctness of the patch is
> so much higher, perhaps it would help the system to "scale", moving some of
> the burden off the committers.

Right. What we need is to start small and create a _culture_ of where
it's fun (or at least intellectually interesting) to work on this stuff.
I think the IRC channel may still be the best bet for this.

Once I finish fiddling around with the sparc64-6 and sparc64-7 release
builds (the first approximation is finished, but I believe we can still
add some more packages), I intend to task-switch over to looking towards
defining a PR workflow and floating some proposals. I hope to have
something concrete to present at BSDCan. Please join us on bugbusters@
to discuss any more ideas, too.

mcl
Zum Vergrößern anklicken....
Diese Dinge brauchen nun mal ein wenig Zeit und ich würde dazu sagen "Stay Tuned".

Im übrigen ist es nicht so, dass alle Personen mit Ahnung, Wissen und Engangement BSDForen verlassen haben, aber das sei auch nur am Rande erwähnt. Mein Vorschlag ist die Diskussion an dieser Stelle zu beenden. Ansonsten wird dieser Thread eher früher als später eskalieren und ich muss schließen, was ich nur ungern machen würde.
 
Zuletzt bearbeitet:
Yamagi schrieb:
Also, diese Mail an freebsd-current@ wurde in der Absicht geschrieben, Menschen auf die hier geäußerten Dinge aufmerksam zu machen. Kamikaze und Ich haben die ganze Sache organisiert und jetzt endlich durchgezogen, obwohl zumindest ich für meinen Teil die Performanceprobleme .............
Zum Vergrößern anklicken....

Hallo Yamagi und Kamikaze hallo@all,

also ich finde es erstmal gut das Ihr Initiative ergriffen habt und überhaupt eine Mail geschrieben habt, das ist aller Ehren wert dann soweit ich das verfolgt habe
habt Ihr beide das nicht einfach so rausgejagt sondern vorher lief eine Diskussion darüber
was ich als Anhänger der Offenheit begrüsse und euer Handeln noch mehr aufwertet.

Nochmals meinen allergrössten Respekt, was da in dem andern Forum gelaufen ist stösst mihr mehr als bitter auf und dazu werde ich mich weiter äussern.
Habe es heute morgen gelesen und daraufhin Kamikaze eine PM zugesendet.

Zu diesem o.g.Forum dort werde ich mich auch nicht weiter öffentlich äussern, das wäre aus meiner Sicht Zeitverschwendung.

Nochmal ich finde das immer noch aller Ehren wert was Ihr gemacht habt, und das können ruhig alle wissen.

In diesem Sinne der rudy und bleibt so wie Ihr seid.
 
Steve` schrieb:
Ich klinke mich an dieser Stelle mal aus dem Thread aus. Es ist leider wieder mal so gelaufen, wie ich es befürchtet hatte und ich hampel' schon viel zu lange mit dem Problem rum und FreeBSD hinterher.

http://www.bsdforen.de/showthread.php?p=104781&highlight=vmstat#post104781
Zum Vergrößern anklicken....


... schade. Es liegt in der Natur der Sache, daß man nicht jedem 'helfen' kann. Sehr witzig finde ich übrigens, daß plötzlich einige Kinderzimmer-Administratoren mittels richtiger Konfiguration ihre Ruckelprobleme lösen. Das reflektiert übrigens meiner Meinung nach ein generelles Problem in der Mailingliste, das bei vielen schnell zu Ermüdungserscheinungen führt.

Übrigens sieht Dein 'vmstat -i' normal aus, kein IRQ-Flooding, alles im grünen Bereich. Bei mir gibt es ebenfalls keine IRQ-Auffälligkeiten, wenn es wackelt oder hakelt.

Übrigens, auf meinen 64 Bit Kisten mit FreeBSD 7.0 kann ich unter GNUstep, wenn ich Sound abspiele und dabei mit der Maus ein Fenster größer oder kleiner mache und den linken Mausknopf dabei lange gedrückt halte, das System, inkl. Sound, mit tödlicher Sicherheit zum Stehen bringen! Vielleicht könnt ihr das ja mal ausprobieren ...
 
Hallo Yamagi, hallo Kamikaze,

auch von mir ein Dankesachön für das Engagement Eurerseits.
Da ich nur für mich sprechen kann, möchte bemerken, dass es sich für mich gelohnt hat. Es hat sich jemand bei mir privat gemeldet, der bereit ist, mit mir/uns das sym-Treiber-Problem zu analysieren und zu beheben, was allerdings eine gewisse Zeit dauern wird.

Viele Grüße

JueDan
 
Das freut mich, dann war die ganze Aktion wenigstens nicht völlig umsonst. Danke sehr :)
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben