Geschwindigkeit unter 7.0 - Bitte ERST lesen

Yamagi

Yamagi

Possessed With Psi Powers
Teammitglied
Aus gegebenen Anlass möchte ich noch einmal darauf hinweisen, dass man bei Geschwindigkeitsproblemen mit FreeBSD 7.0 vor dem Erstellen eines neuen Threads folgendes beachten sollte:

- FreeBSD 7.0 kommt mit dem alten Scheduler SCHED_4BSD. Dieser ist unter 7.0 merklich langsamer und hakeliger als noch unter FreeBSD 6.2. Das betrifft gerade Maschinen mit vielen Prozessen, also Desktops. Bei Problemen lohnt es sich sowohl auf UP- als auch auf SMP-Maschinen auf SCHED_ULE zu wechseln. Der aktuelle Scheduler kann mittel "sysctl kern.sched.name" angezeigt werden.

- FreeBSD 7.0 kommt mit großen Änderungen am Threading und am Malloc. Daher sollten möglichst alle Pakete neu gebaut werden, die Nutzung von compat6 führt zu schlechter Performance oder funktioniert bei systemnahen Dingen - z.B. bei X.org - nicht.

Diese Hinweise bleiben für die nächste als "Sticky" markiert und damit oben angeklebt.
 
Hmm, ich werde warten, bis das RELEASE als ISO-Image draußen ist, dann brennen, alle Pakete vom alten System deinstallieren, und dann mit sysinstall ein upgrade von der CD durchführen, die neuen Pakete auch von der CD installieren bzw. für alles weitere ein pkg_add -r sowieso durchführen. So sollte es keine Probleme geben. Und Compat6 wird dann wohl kaum interessieren...
 
Zuletzt bearbeitet:
Also ich hab gerade FreeBSD 7.0 RC1 laufen (gestern gezogen). Und die Kiste ist merklich langsamer als auf FreeBSD 6.2. *grrrrr*

Dabei hab ich gar keine Exotische Hardware. i386 Duron 1800Mhz, 1GB Ram und ne Geforce Graka
 
Habe mir gestern per cvsup die Sourcen von 7.0-PRERELEASE gezogen und muss hier anfügen, dass man unbedingt auf SCHED_ULE umsteigen sollte (4BSD is einfach langsam). Danach ist ein neu bauen aller Ports nicht zwingend notwendig (bei mir lief X.org und co auch mit COMPAT6), jedoch sind die Programme schon langsamer, so dass sich ein portupgrade -af lohnt. Danach rennt das System aber auch deutlich schneller als noch unter 6.2. Denke mir mal SMP ist dran 'schuld'.
Noch ein Hinweis zu portupgrade:
Lasst portupgrade erstmal alle ruby ports upgraden und danach macht ihr ein portupgrade -afx ruby*.
Bei mir ist portupgrade immer nach dem neu bauen von ruby mit nem Fehler abgebrochen, wenn mans jedoch vorher (oder nachher) getrennt baut, dann rennt portupgrade ohne Probleme durch.
Achja: nicht vergessen vorher den Portstree zu updaten. ;)
 
Was muss getan werden um ' SCHED_ULE' zu aktivieren?
Reicht es aus einen neuen Kernel mit der Option zu backen oder muss das ganze System neu kompiliert werden?
 
Ich denke, der Kernel reicht; ich hatte gehofft, es sei als Modul ladbar (weil freebsd-update anscheinend nur GENERIC patcht). :( Weiß jemand mehr?

EDIT: Da war jemand schneller. ;)
 
Wenn die es geschafft haben einen Sheduler als Modul nachladbar zu machen, dann verneige ich mich ;-)

CU

Martin
 
dark_angel schrieb:
Lasst portupgrade erstmal alle ruby ports upgraden und danach macht ihr ein portupgrade -afx ruby*.
Bei mir ist portupgrade immer nach dem neu bauen von ruby mit nem Fehler abgebrochen, wenn mans jedoch vorher (oder nachher) getrennt baut, dann rennt portupgrade ohne Probleme durch.
Zum Vergrößern anklicken....
Ich weiß nicht warum Leute sich immer so einen Stress machen mit portupgrade oder dann noch COMPATXY dazu :zitter:
Wenn man gerade schon seine Welt neugebaut hat, kann man doch schnell ein beherztes pkg_delete -a machen und dann selektiv neuinstallieren;
1) macht das nie Probleme -> spart Zeit
2) die ganzen kleineren Programm und Lib-Leichen verschwinden -> das System bleibt auch über die Jahre "slim"
 
soul_rebel schrieb:
Ich weiß nicht warum Leute sich immer so einen Stress machen mit portupgrade oder dann noch COMPATXY dazu :zitter:
Wenn man gerade schon seine Welt neugebaut hat, kann man doch schnell ein beherztes pkg_delete -a machen und dann selektiv neuinstallieren;
1) macht das nie Probleme -> spart Zeit
2) die ganzen kleineren Programm und Lib-Leichen verschwinden -> das System bleibt auch über die Jahre "slim"
Zum Vergrößern anklicken....

Kann ich dir jetzt auch nur zustimmen. War zu blind für die Lösung. ^^
Habe mir jetzt auch ein kleines Script gebastelt, dass mir eine Neuinstallation mit vorherigem pkg_delete -af, selbstständig durchführt.

Wen es interessiert:
Code: 
#!/bin/sh
echo "Deleting all packages"
/usr/sbin/pkg_delete -af

echo "rebuilding portstree"
rm -rf /usr/ports/*
portsnap fetch extract

echo "Start compiling all ports listet in file $1"
cat $1 | while
read line
do
echo "Now working on: $line"
cd /usr/ports/$line
make install clean
done
Man muss es nur mit dem Dateinamen der Ports (z.B. devel/distcc), die man gern wiederhaben möchte, aufrufen.
 
Treten die Geschwindigkeitsprobleme mit der aktuellen Version 7.0 Stable immer noch auf? Nur bei dem alten Scheduler? Wie groß sind diese?

Treten Sie auch auf meiner Hardware auf?
- Intel Core 2 Duo E6420
- Gigabyte GA-965P-DS3 Rev 3.3 BIOS-F12 (ICH8,P965 Chipset)
- Samsung SATA2 250 GB Festplatte
- 2GB RAM DDR2-800 MDT CL5
- DVD-RW-Brenner SATA

Gruß,
Ararat++
 
Du solltest SCHED_ULE nehmen und alle Pakete neu installieren. Ansonsten hast du nichts zu befürchten, außer du hast ein zickiges Mainboard.
 
Danke. Wurde der Patch mit der ruckelnden Maus schon integriert? Und warum tritt dieser bei den anderen BSDs nicht auf?
 
Der Patch wurde am 6. März 2008 in den X.org Port integriert, wie unter http://www.freshports.org/x11-servers/xorg-server/ zu sehen ist. Du musst ihn also nicht manuell einspielen.

Das Problem mit der ruckelnden Maus resultiert nicht wie erst angenommen aus der neuen Interruptverarbeitung von FreeBSD 7.0. Schuld ist die interne Zeitverarbeitung. X.org holt sich bei jeder Veränderung der Mauszeigerposition mit gettimeofday() die aktuelle Uhrzeit vom System, im die korrekte Geschwindigkeit des Zeigers zu errechnen. Nun gibt gettimeofday() allerdings nicht einfach die Uhrzeit zurück, stattdessen werden noch einige Berechnungen mit ihr durchgeführt, um den Fehler durch die Gangungenauigkeit der Systemuhr und die Abweichung durch Last auf dem System auszugleichen. Diese Algoritmen sind unter FreeBSD sehr teuer, da man sich für Genauigkeit vor Geschwindigkeit entschieden hat. Das ist einer der Hauptgründe, weshalb professionelle Zeiterfassung fast ausschließlich auf FreeBSD betrieben wird.
X.org wurde unter Linux entwickelt und nimmt blind gettimeofday() in Standardeinstellung, also mit höchter Präzesion, da dies unter Linux etwas gleich teuer ist wie ein Aufruf mit schlechterer Präzesion. Der Patch veringert die Präzesion und senkt damit die Kosten der Zeitberechnung massiv. Das die Probleme unter FreeBSD 6.x nicht auftraten liegt einfach daran, dass 7.0 neue und aufwendigere Algoritmen für die Zeitberechnungen hat, die vor dem Hintergrund stärkerer Hardware eingeführt wurden.
Da du einen Dualcore hast, werden dich die Ruckler höchstwahrscheinlich eh nicht treffen. Ist ein Kern ausgelastet, geht das System für gettimeofday() einfach auf den zweiten. Da brauch es mehr Gewalt übliche EInsatzszenarios um es in die Knie zu zwingen.
 
Danke für die Erklärung. :)

Macht sich die geringere Präzision irgendwo bemerkbar? z.B. bei Ego-Shootern, wo es beim professionellen Spielen genau darauf ankommt, oder nicht?
 
Nein, da du für die Maus nur die relative Zeit berechnen musst, ist das vollkommen irrelevant.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben