Geri dönüşüm testleri sistemin belirli bir bölümünün beklendiği gibi çalışıp çalışmadığınıve eski hataların tekrar edip etmediğini öğrenmek için kullanılır. FreeBSD geri dönüşüm testi araçlarıFreeBSD kaynak ağacının src/tools/regression dizininden elde edilebilir
Bu bölüm FreeBSD üzerinde ya da FreeBSD nin kendisine mikro düzeyde uygun kalite testi(Benchmark) yapma ile ilgili ipuçlarıiçerir. Aşağıdaki bütün önerilerin hepsini kullanmak pek mümkün olmasa da ne kadar fazla kullanılırsa küçük farklar için daha iyi kalite testi sağlanmışolur.
APM ve diğer önemsiz saat türü şeyleri kapatın (ACPI ?)
Tek kullanıcılımod(single user mode) da çalışın. Örnek: cron(8) ve diğer daemon olarak çalışan programlar gürültü eklerler. sshd(8) programıda problemlere neden olabilir. Eğer test boyunca ssh erişimi gerekliyse hiç olmazsa SSHv1 anahtar(key) üretmeyi kapatın veya test yaparken ana sshd sürecini öldürün.
ntpd(8) i çalıştırmayın.
Eğer syslog(3) olaylarıoluşturulduysa, ya syslogd(8)'yi boş /etc/syslogd.conf dosyasıyla çalıştırın aksi halde çalıştırmayın.
Disk I/O(Giriş-Çıkış) işlemlerini minimize edin, mümkünse hiç olmasın.
Gerekli olmayan dosya sistemlerini başlatmayın.
Mümkünse /, /usr ve diğer dosya sistemlerini read-only modda açın. Bu I/O görüntüsünden diske olan atime güncellemelerinin(vb.) olmamasınısağlar.
newfs(8) ile okuma/yazma test dosya sistemlerini tekrar yükleyin ve her çalıştırmada tar(1) veya dump(8) komutlarıile yeni dosya oluşturarak dosya sistemini test edin. Teste başlamadan bu dosya sistemlerini önce bırak (unmount) ve sonra bağla (mount) işlemlerini yapın. Bu sabit bir dosya sistemi görüntüsünün oluşmasınısağlar. Sağlam bir test için bu /usr/obj (sadece newfs yeniden ayarlayıp mount ile bağlayın) dizinine uygulanmalıdır. %100 verimlilik için dd(1) komutu ile bir dosyayıdosya sistemine yerleştirin.(Örnek: dd if=myimage of=/dev/ad0s1h bs=1m)
Malloc ile alınmışya da md(4) ile önyüklenmiş bölümleri(partition) kullanın.
Testin iterasyonlarıarasında sistemi yeniden başlatın, bu daha kararlıbir sistem oluşturur.
Temel olmayan aygıt sürücülerini çekirdekten çıkarın. Örneğin USB test için gerekli değilse, USB yi çekireğe yüklemeyin. Yüklü olan sürücüler genelde zamanaşımına sebep olurlar.
Kullanılmayan donanımlarıyapılandırmayın. Eğer test için kullanılmayacaksa diskleri atacontrol(8) ve camcontrol(8) ile sistemden ayırabilirsiniz.
Eğer sistem halka açık bir ağa bağlıolmak zorunda ise broadcast trafiğinin ani yükselmesine dikkat edin. Zor farkedilebilmesine rağmen, yine de işlemci zamanının bir kaynaklarının harcayacaktır. Bunlar multicast için de geçerlidir.
Her dosya sistemini kendi diskinize koyun.
Seri veya VGA konsollarına olan çıktıyıminimize edin. Çıktıyı dosyalara yüklemek sistemi rahatlatacaktır. (Seri konsollar daha kolay tıkanırlar.) Test çalıştığısürece klavyeye dokunmayın.
Testin yeteri kadar uzun olduğundan emin ol, ama çok uzun olmasın. Eğer test çok kısa ise, tarihin ölçülmesi problem olabilir. Eğer çok uzun olursa sıcaklık değişimleri ve sürüklenmeler bilgisayardaki kuvars kristallerinin frekansınıetkiler.Bir dakikadan fazla bir saatten az bir süre ideal bir süredir.
Makinenin etrafındaki sıcaklığımümkün olduğunca sabit tutmaya çalışın. Bu kuvars kristallerini ve disk sürücü algoritmalarını birlikte etkiler. Gerçek stabil saat için stabilize saat takılabilir. Mesela OCXO + PLL devresi kullanılarak bu devrenin çıktısıanakartın dalga üreticileri yerine kullanılabilir. Daha fazla bilgi için Poul-Henning Kamp <phk@FreeBSD.org>ile irtibata geçebilirsiniz.
Testi en az 3 defa çalıştırın ama koddan önce ve sonra 20 defadan fazla çalıştırmak daha iyidir. Eğer mümkünse araya zaman koyun (koddan önce 20 defa ardından koddan sonra 20 defa çalıştırma), bu çevresel etkileri dağıtmayısağlayabilir. Boşlukları 1'e 1 şeklinde değil 3'e 3 şeklinde koyabilirsiniz, bu birbirine olan tesiri dağıtabilir. Güzel bir örnek: bababa {bbbaaa}*. Bu ilk 1+1 çalışmadan sonra bir olumsuzluk görülürse testi iptal etme gibi bir imkanınız olur, ilk 3+3 den sonraki standart sapma gibi hesaplamalar uzun çalışmasıdurumunda ne olabileceği hakkında bilgi verir.
Sayıların anlamlıolduğunu görmek için usr/src/tools/tools/ministat dosyasınıkullanın. Eğer istatistik hakkında pek bilginiz yoksa ve standart sapmayıve Student's T dağılımınıbilmiyorsanız "Cartoon guide to statistics" kitabını tavsiye edebiliriz, ISBN: 0062731025.
Eğer test arkaplan fsck(8)'in değerlendirmesi değilse, fsck(8)'i kullanmayın. Ayrıca değerlendirme boot dan 60+"fsck çalışması" kadar saniye sonra çalıştırıldıysa background_fsck yı /etc/rc.conf dan engelleyin, çünkü rc(8) fsck engellenmemişse aktif hale gelir ve fsck nin herhangi bir dosya sisteminde çalıştırılması gerekip gerekmediğine bakar. Bunun gibi, değerlendirme snapshot ile değilse sistemde herhangi bir snapshot'un olmadığına emin olun.
Eğer değerlendirme beklenmedik kötü performans gösterirse, farklıyerlerden gelebilecek yüksek kesme miktarıgibi şeyleri kontrol edin. ACPI'ın bazıversiyonlarında aşırıkesmelerin üretildiği raporlanmıştır. Garip olan test sonuçlarınıteşhis etmek için "vmstat -i"'nin birkaç görüntüsünü alın ve beklenmedik durumlar için gözden geçirin.
Çekirdek ve kullanıcıuzayıiçin optimizasyon parametrelerine dikkat edin. Keza hata ayıklama parametrelerine de.
Değişmez ve sabit çekirdek seçeneklerinin (WITNESS ve INVARIANTS ) açık olduğu durumlarda değerlendirme yapmayın eğer test bu seçeneklerle alakalıdeğilse. WITNESS performansta %400 oranında düşmelere neden olabilir.Kullanıcıuzayımalloc(3) parametreleride -CURRENT sürümlerinde ve diğer sürümlerde farklıdır ve farklı sonuçlar üretebilir.