Regressionstests werden benutzt, um zu testen, ob ein bestimmter Teil des Systems wie erwartet funktioniert und um sicherzustellen, dass alte Bugs nicht wieder eingebaut wurden. Die &os; Regressionstest-Werkzeuge finden Sie im &os;-Quelltextbaumes im Verzeichnis src/tools/regression.

Dieser Abschnitt enhält Tipps, wie man angemessenes Mikro-Benchmarking auf &os; oder von Teilen von &os; selbst machen kann. Es ist nicht möglich, jedes einzelne mal alle der folgenden Vorschläge anzuwenden, aber je mehr davon benutzt werden desto besser wird der Benchmark kleine Unterschiede nachweisen können. Schalten Sie APM und alles andere, das den Systemtakt manipuliert, ab. (ACPI ?) Benutzen Sie den Single-User Modus. &man.cron.8; z.B., und andere Systemdienste fügen nur Störungen hinzu. Der &man.sshd.8; Systemdienst kann ebenfalls Probleme verursachen. Falls während des Tests ssh-Zugriff benötigt wird, schalten Sie entweder die Neuerstellung des SSHv1 Schlüssels ab, oder beenden Sie den sshd-Elternprozess während der Tests. Lassen Sie &man.ntpd.8; nicht laufen. Falls &man.syslog.3;-Ereignisse erzeugt werden, starten Sie &man.syslogd.8; mit leerer /etc/syslogd.conf, ansonsten lassen Sie es nicht laufen. Sorgen Sie für möglichst wenig Disk-I/O, wenn möglich, vermeiden Sie sie ganz. Hängen Sie keine Dateisysteme ein, die Sie nicht benötigen. Hängen Sie /, /usr, und jedes andere Dateisystem als nur lesbar ein, wenn möglich. Dies verhindert, dass atime-Aktualisierungen auf Disk (usw.) das Ergebnis verfälschen. Reinitialisieren Sie das beschreibbare Test-Dateisystem mit &man.newfs.8; und füllen Sie es aus einer &man.tar.1;- oder &man.dump.8;-Datei vor jedem Lauf. Hängen Sie es aus und wieder ein bevor Sie den Test starten. Dies sorgt für einen konsistenten Dateisystemaufbau. Bei einem worldstone Test bezieht sich dies auf /usr/obj (Reinitialisieren Sie es einfach mit newfs und hängen Sie es ein). Um 100% reproduzierbare Ergebnisse zu bekommen, füllen Sie das Dateisystem aus einer &man.dd.1;-Datei (also mit so etwas wie: dd if=myimage of=/dev/ad0s1h bs=1m) Benutzen Sie malloc-gestützte oder preload-ed &man.md.4; Partitionen. Machen Sie einen Neustart zwischen den einzelnen Iterationen des Tests, dies ergibt einen konsistenteren Zustand. Entfernen Sie alle nicht unbedingt nötogen Gerätetreiber aus dem Kernel. Wenn z.B. USB für den Test nicht benötigt wird, entfernen Sie USB aus dem Kernel. Gerätetreiber, die sich einhängen, haben oft tickende Timeouts. Konfigurieren Sie Hardware aus, die nicht benutzt wird. Entfernen Sie Disks mit &man.atacontrol.8; und &man.camcontrol.8;, wenn die Disks für den test nicht benutzt werden. Konfigurieren Sie nicht das Netzwerk, esseidenn es wird getestet, oder warten Sie bis der Test fertig ist, wenn Sie das Ergebnis zu einem anderen Rechner übertragen wollen. Falls das System an ein öffentliches Netzwerk angeschlossen sein muss, achten Sie auf Spitzen von Broadcast-Traffic. Obwohl dieser kaum auffällt, wird er CPU Zyklen brauchen. Ähnliches gilt für Multicast. Legen Sie jedes Dateisystem auf seine eigene Disk. Dies minimiert Jitter durch Optimierungen von Lesekopfbewegungen. Minimieren Sie Ausgaben auf serielle or VGA Konsolen. Ausgaben in Dateien umgeleitet ergeben weniger Jitter. (Serielle Konsolen werden leicht zum Flaschenhals.) Benutzen Sie die Tastatur nicht während der Test läuft, sogar space oder back-space erscheint in den Ergebnissen. Stellen Sie sicher, dass der Test lang genug läuft, aber nicht zu lange. Wenn er zu kurz ist, ist Timestamping ein Problem. Wenn er zu lang ist, werden Temperaturänderungen und Drift die Frequenz von Quarzkristallen im Rechner beeinflussen. Daumenregel: mehr als eine Minute, weniger als eine Stunde. Versuchen Sie, die Temperatur in der Umgebung des Rechners so stabil wie möglich zu halten. Dies betrifft sowohl Quarzkristalle als auch Disk-Laufwerks-Algorithmen. Um wirklich stabilen Takt zu bekommen wäre es auch möglich, einen stabilisierten Takt anzuschliessen. D.h., besorgen Sie sich einen OCXO + PLL und koppeln Sie das Ausgangssignal in die Taktgeberschaltkreise anstelle das des Quarzkristalls der Systemplatine an. Wenden Sie sich an &a.phk; wenn Sie mehr Informationen hierüber benötigen. Lassen Sie den Test mindestens drei mal laufen, aber es ist besser ihm mehr als 20 mal laufen zu lassen, sowohl für den vorher als auch für den nachher Code. Versuchen Sie, abzuwechseln (d.h., nicht erst 20 mal vorher und dann 20 mal nachher), dies ermöglicht, umgebungsbedingte Effekte zu erkennen. Wechseln Sie nicht 1:1 ab, sondern 3:3, dies ermöglicht, Wechselwirkungseffekte zu erkennen. Ein gutes Muster ist: bababa{bbbaaa}*. Dies gibt Hinweise nach den ersten 1+1 Läufen (sodass Sie den Test stoppen können falls er völlig danebengeht), und Sie können die Standardabweichung nach den ersten 3+3 Läufen überprüfen (ergibt einen guten Hinweis, ob sich ein längerer Lauf lohnt), und das ergibt später Werte über Trends und Wechselwirkungenn. Benutzen Sie usr/src/tools/tools/ministat um festzustellen, ob Ihre Ergebnisse signifikant sind. Überlegen Sie, sich das Buch Cartoon guide to statistics ISBN: 0062731025 zu kaufen, sehr empfehlenswert falls Sie Dinge wie Standardabweichung und Studentsche t-Verteilung vergessen oder nie gelernt haben. Benutzen Sie keinen Background &man.fsck.8;, esseidenn Sie testen Background fsck. Schalten Sie auch background_fsck in /etc/rc.conf aus, esseidenn der Benchmark wird nicht mindestens 60+Laufzeit von fsck Sekunden nach Systemstart gestartet, da &man.rc.8; aufwacht und prüft, ob fsck auf irgendeinem der Dateisysteme laufen muss, wenn Background fsck eingeschaltet ist. Stellen Sie ebenfalls sicher, dass keine Snapshots herumliegen, esseidenn der Benchmark ist ein Test mit Snapshots. Falls der Benchmark unerwartet schlechte Performance zeigt, überprüfen Sie Dinge wie große Mengen Interrupts von unerwarteten Quellen. Es gibt Berichte, dass einige ACPI-Versionen sich daneben benehmen und ein Übermaß an Interrupts erzeugen. Um zu helfen, ungewöhnliche Testergebnisse zu diagnostizieren, machen Sie ein Paar Momentaufnahmen von vmstat -i und suchen Sie nach Ungewöhnlichem. Achten Sie auf Parameter für Optimierungen für Kernel und Userland, desgleichen für Debugging. Es ist einfach, irgendetwas durchrutschen zu lassen und dann später festzustellen, dass der Test nicht das Gleiche verglichen hat. Benchmarken Sie nie mit den Kerneloptions WITNESS and INVARIANTS eingeschaltet, esseidenn der Test interessiert sich dafür, diese Features zu benchmarken. WITNESS kann 400% und mehr Abnahme von Performance erzeugen. Ähnliches gilt für Userland &man.malloc.3;-Parameter, Voreinstellungen hierbei bei -CURRENT unterscheiden sich von denen bei Production-Releases.