Performance mies unter FreeBSD 6.0 Beta ??

gladiator

Chaos mit System...
nach meinem Boardtausch und der damit verbundenen Softwarebastelei konnte ich es nicht lassen, ein FreeBSD 6.0 Beta3 zu installieren und dieses via make world auf Beta4 zu bringen und den Debug-Kram aus dem Kernel zu entfernen. Allerdings kommen mir die Werte, die mir ubench geliefert hat, etwas niedrig vor.

meine Kiste:
Tyan Thunder HeSL S2567
Dual P3-1000 (FSB 133, 256kB L2-Cache)
2 GB SD-RAM PC133 Reg. ECC
FreeBSD 6.0 Beta4 ohne WITNESS und weitere Debug-Optionen

ubench liefert in etwa folgende Werte (gerundete Werte):
CPU 69000
MEM 55000
--------------
AVG 62000

Die Werte erscheinen mir etwas niedrig, da in einem frueheren Thread die Dual-P3 zumindest in der CPU-Performance irgendwo bei 100000 lagen...
Dass es an der Hardware liegt, kann ich mir ehrlich gesagt nicht vorstellen, eher dass
a) FreeBSD 6.0 performancemaessig ein ziemlicher Rueckschritt ist (wo ist die Bremse?)
b) ich bei meiner Kernel-config danebengegriffen habe (eigentlich nur ein um SCSI- und RAID-Optionen reduzierter GENERIC-Kernel bei dem SMP und APIC mit dazugekommen sind)
Habt ihr schon aehnliche Erfahrungen gemacht?
 
FreeBSD 6.0 performancemaessig ein ziemlicher Rueckschritt ist (wo ist die Bremse?)

naja, im 6'er is doch der ganze debug kram aktiviert. performancerekorde solltest du nicht wirklich erwarten :)

(edit)
FreeBSD 6.0 Beta4 ohne WITNESS und weitere Debug-Optionen

ich vermute das einfach auch noch ne menge müll und genereller developkram mit im source hängt.
 
marzl schrieb:
naja, im 6'er is doch der ganze debug kram aktiviert. performancerekorde solltest du nicht wirklich erwarten :)
(edit)
ich vermute das einfach auch noch ne menge müll und genereller developkram mit im source hängt.
...die ganzen Debug-Optionen habe ich eigentlich rauskompiliert, daran sollte es ja eigentlich nicht liegen, es sei denn, es gibt in der Kernel-Config ausser dem gesamten Debug-Block noch weitere Optionen, die ich uebersehen haette.
Ausserdem geht es hier ja nicht um Rekorde, sondern um etwa 30%, die bei mir im Vergleich zu mehreren anderen Usern hier im Forum fehlen.
Im Uebrigen liefert ubench -s (Single-CPU-Mode) etwa die Haelfte, sprich
CPU 34800
d.h. auch die UP-Performance ist denkbar miserabel und liegt in etwa auf dem Niveau eines (Single-) P3-700...
 
Ähm, du hast die Debug Sachen im Kernel deaktiviert. Aber deren Gegenstücke im gesamten Userland nicht.
 
Elessar schrieb:
Ähm, du hast die Debug Sachen im Kernel deaktiviert. Aber deren Gegenstücke im gesamten Userland nicht.
... und wo finde ich die? Gibt es da einen globalen Schalter, den man dazu setzen kann/muss? (nochmal neu bauen/installieren versteht sich in diesem Fall ja von selbst)
 
Setz einfach mal in der make.conf
WITH_DEBUG=no
WITHOUT_DEBUG=true

Das funktioniert zumindest bei einigen ports. Dann kannst du mit
# portupgrade -fa
versuchen alles neu zu bauen.
 
um die ganze Sache nochmals zu rekapitulieren:

# meine make.conf sah gestern beim Updaten von 6.0Beta3 auf 6.0Beta4 recht jungfraeulich aus, keine Spur von irgendwelchen Debug-Optionen
# in meiner Kernel-Config habe ich alles auskommentiert, was nach Debug aussieht

Elessar meint, im Userland waeren u.U. noch weitere Debug-Geschichten aktiv, was aber heissen wuerde, das bei jedem einzelnen Userland-Prograemmchen separat die Debug-Optionen per Default eingeschaltet wurden (was ich mir eigentlich nicht so recht vorstellen kann...)

[LoN]Kamikaze meint, zumindest bei den Ports funktionieren die globalen Schalter in der make.conf, und koennte evtl auch beim make buildworld greifen...

OK, mal angenommen, ich setze die beiden von [LoN]Kamikaze genannten Debug-Schalter und in den einzelnen makefiles stehen genau die entgegengesetzten Optionen - was greift dann???
 
Ich kann hier ebenfalls bestätigen, dass sich FreeBSD 6.0BETA4 "gefühl" recht lahm verhält. Das war seinerzeit unter FreeBSD 5.0BETAx anders, da war auch der ganze Debugging-Krams aktiv, aber das System in sich performanter.

Ich habe das nicht mit genauen Zahlen gemessen, bemerke aber ein ewiges Ruckeln im TV-Bild meiner TV-Karte, speziell, wenn die Festplatten auf Touren kommen und viel Krams durch die Gegend schaufeln. Dann steht das TV-Bild teilweise mehrere Sekunden still.
 
1. Nimm die debug options aus dem Kernel.
2. Führe
Code:
ln -s 'aj' malloc.conf
unter /etc aus.
Schau Dir mal /usr/src/UPDATING an
 
Hier ist es etwas besser, wenn der Kernel ohne Debugging läuft (was ich aber vermeide, sonst wäre CURRENT witzlos). malloc.conf ist ohnehin "eingerichtet", weil mein pekwm sonst nicht startet.

Trotzdem ist die Performanz im Vergleich zum frühen 5.0er Stadium schlechter geworden. Mich stört das im Endeffekt nicht und ich will mich nicht beschweren, ich stelle es nur fest.
 
asg schrieb:
1. Nimm die debug options aus dem Kernel.
2. Führe
Code:
ln -s 'aj' malloc.conf
unter /etc aus.
Schau Dir mal /usr/src/UPDATING an

... ist ja schon etwas seltsam, da in der manpage von malloc folgendes zu finden ist:

A All warnings (except for the warning about unknown flags being
set) become fatal. The process will call abort(3) in these
cases.

J Each byte of new memory allocated by malloc(), realloc() or
reallocf() as well as all memory returned by free(), realloc() or
reallocf() will be initialized to 0xd0. This options also sets
the ``R'' option. This is intended for debugging and will impact
performance negatively.

Der positive Performance-Effekt wird in der Mailing-Liste erwaehnt, obwohl die Doku eigentlich auf einen Performanceverlust hinweist...
werde ich jedenfalls mal so testen.
 
Ich habe hier einen Dual P3 733 mit 6.0-BETA4 zu laufen, da zeigt das vorkompilierte ubench-Paket etwa 50.000 und wenn ich ubench mit p3-Optimierung baue, dann habe ich etwa 85.000 CPU-Punkte. Ich denke es liegt also eher an ubench und nicht an FreeBSD.

Björn
 
Björn König schrieb:
Ich habe hier einen Dual P3 733 mit 6.0-BETA4 zu laufen, da zeigt das vorkompilierte ubench-Paket etwa 50.000 und wenn ich ubench mit p3-Optimierung baue, dann habe ich etwa 85.000 CPU-Punkte. Ich denke es liegt also eher an ubench und nicht an FreeBSD.

Björn

wenn ich den bei Dir erzielten Faktor von 1,7 auf meiner Kiste auch erreiche, bin ich zufrieden...
Da muss ich doch glatt mal ein optimiertes ubench bauen.
 
Hmm, also es gibt flags für das Userland bezgl. debugging.
Ich finde diese aber weder in der manpage von make.conf, noch in der example mak.conf und auch nicht unter /usr/share/mk/.
Sehr käsig, imho.

Ansonsten sollte debugging im userland nur aktiv sein wenn man sich die sourcen zieht und CURRENT baut. Wenn man vom ISO installiert hat sollte das debugging für das userland nicht aktiv sein.
 
asg schrieb:
Hmm, also es gibt flags für das Userland bezgl. debugging.
Ich finde diese aber weder in der manpage von make.conf, noch in der example mak.conf und auch nicht unter /usr/share/mk/.
Sehr käsig, imho.
Vielleicht gibt es da ja auch gar nichts; ich habe auch schon danach gesucht, aber keinen Hinweis dafür gefunden. Auf entsprechende Fragen in den Mailinglisten wird bezüglich Userland nur 'ln -s aj /etc/malloc.conf' geantwortet. Wenn man das setzt, dann gibt's bei ubench schon deutlich mehr Memory-Punkte.

Björn
 
gladiator schrieb:
[LoN]Kamikaze meint, zumindest bei den Ports funktionieren die globalen Schalter in der make.conf, und koennte evtl auch beim make buildworld greifen...
Es gibt einige Ports die ihre eigenen Debugfunktionen mitbringen und die hören meistens auf eine der beiden angegebenen Optionen.
 
... so, jetzt ein kleines Update, da ich schon zum Testen gekommen bin:

ubench mit CPUTYPE=p3 kompiliert und schon hatte ich folgende Werte:
CPU 115600
MEM 56000

noch die malloc-Geschichte:
CPU 115800
MEM 59000

somit bin ich zufrieden und muss kein weiteres make buildworld lostreten.
 
[LoN]Kamikaze schrieb:
Setz einfach mal in der make.conf
WITH_DEBUG=no
WITHOUT_DEBUG=true

Das funktioniert zumindest bei einigen ports. Dann kannst du mit
# portupgrade -fa
versuchen alles neu zu bauen.

Das sollte man sich lieber nicht in die make.conf schreiben. Fast alle Ports, bei denen die Variable WITH_DEBUG von Bedeutung ist, wird nur geprüft ob sie definiert wurde, aber nicht welchen Wert sie hat, also es verwenden viele
Code:
.if defined(WITH_DEBUG)
  bla bla
.endif
anstatt
Code:
.if ${WITH_DEBUG} == "yes"
  bla bla
.endif
Mit WITH_DEBUG=no definiert man also die Variable, das "no" ist den meisten Ports völlig egal und somit erreicht man genau das Gegenteil von dem was man wollte.

WITHOUT_DEBUG ist noch unbedeutender, da diese Variable nur von insgesamt fünf Ports verwendet wird.

Björn
 
Habe ich mal nachgeprüft und muss feststellen, das du leider recht hast. Ich habe die WITH_DEBUG=no aus meiner make.conf entfernt.

Ich finde übrigens nur 4 Ports die darauf hören. Allerdings taucht es recht oft in den options unter /var/db/ports auf.
 
Zurück
Oben