Ubuntu 6.06.1, OpenBSD 4.0 beta, NetBSD 3.0.1 dual Intel Woodcrest-en

Hardver

Hétfőn FreeBSD 6.1/AMD64-et telepítettem egy olyan szerverre, amely kettő darab kétmagos Intel Xeon "Woodcrest" processzort tartalmaz. A technika viszonylag új, ezért kíváncsi voltam arra, hogy hogyan futnak rajta a nyílt forrású, szabadon elérhető operációs rendszerek. A FreeBSD a hét elején jól vizsgázott. A zsír újnak számító processzoron, és a mindennapinak azért nem nevezhető MegaRAID SAS/SATA kártyán stabilan futott. Egyetlen szépséghibája volt a tesztnek, nevezetesen azt, hogy az alaplapi hálózati chip-eket nem ismerte meg az FBSD 6.1-es kiadása.

Ezek után nézzük, hogy mit szólt a vashoz az Ubuntu 6.06.1, az OpenBSD 4.0 beta és a NetBSD 3.0.1. Mindegyikből az AMD64-es kiadást tettem próbára.


A szóban forgó vas

(További képek és a szerver technikai paraméterei itt)

Ubuntu 6.06.1
----------------

Korábban azt terveztem, hogy az Ubuntu 6.06.1 szerverekre szánt változatát telepítem fel a szerverre. Ezt meg is tettem, de utána eszembe jutott, hogy jó volna azért látni, hogy mit produkál egy X.Org-gal is, ezért a 6.06.1 desktop-ot is rátoltam. A kettő között gyakorlatilag semmi különbség nincs, csak a csomagösszeállítás az, ami más.

A lemezre ráboot-olva hamarosan a megszokott Ubuntu desktop felület jelentkezett be. Egy kattintás az asztalon levő "Install" ikonra, és máris elindult a grafikus telepítő. A szokásos dolgok (nyelv, időzóna, billentyűzet kiosztás, melyik lemezre, felhasználó, jelszó) megadása után a telepítés automatikus, csak a végén figyelmeztet, hogy vegyük ki a CD-t.

Amint kész lett a telepítés, újraindítottam, de nem boot-olt be. Elindítottam "rescue" módban a CD-t, és láttam, hogy a boot-kor a SAS/SATA kártya drivere nem töltődik be az initrd-ből. Kiderült, hogy a Debian telepítő egy bugja miatt ez a modul nem kerül automatikusan be az initrd-be.

Sebaj, tegyük bele:

echo "megaraid_sas" >> /etc/mkinitramfs/modules
mkinitramfs -o /boot/initrd.img-2.6.15-1-486 2.6.15-1-486

 
Ezután reboot, majd szépen el is indult a rendszer.

A dmesg itt. A dmesg-en látszik, hogy lenne még mit dolgozni a rendszerrel, hogy tökéletes legyen. De a lényeg, hogy szépen megy, ráadásul "látja" és használja is az alaplapi hálózati chip-eket.

A rendszerről további infók tudhatók meg az ifconfig kimenetből (látszik a két alaplapi hálózati chip + az általam korábban a FreeBSD miatt beletett 10/100-as 3com hálózati kártya), az lsmod kimenetből és az lspci kimenetből.

Hogy ne csak a boot alapján döntsem el a "mennyire fut jól?" kérdést, egy fél napon keresztül nyúztam a gépet. Kernelt fordítottam egy, kettő, három, négy, öt és nyolc szálon.

A teszthez a legfrissebb stabil kernelnek, a 2.6.17.11-nek a forrását használtam. A teljes kernelt lefordítottam "make allyesconfig" beállításokkal. A "make allyesconfig" annyit tesz - ahogy a neve is mutatja - hogy a kernel konfigurációs file-ban mindent "yes"-re állít, azaz a kernel összes részét lefordítja.

Ezzel a beállítással az alábbi időket kaptam:

Trey új játéka
2x dual-core Xeon 5160 @ 3.0 GHz
 
time make real 24m8.490s
user 21m39.633s
sys 3m1.011s
 
time make -j 2 real 13m29.288s
user 21m12.468s
sys 3m1.499s
 
time make -j 4 real 8m27.997s
user 20m2.311s
sys 2m56.271s
 
time make -j 5 real 8m20.409s
user 20m19.204s
sys 3m0.435s
 
time make -j 8 real 8m1.677s
user 20m16.132s
sys 3m1.839s
 

Az Ubuntu tehát az initrd-s hibától eltekintve jól vette az akadályt. A gép a tesztek alatt hasonlóan stabil volt, mint a FreeBSD alatt, mikoris órákon keresztül fordult a "make buildkernel" és a "make buildworld" páros egymás után.

OpenBSD 4.0 beta
--------------------

A következő operációs rendszer az OpenBSD volt. Féltem, hogy nem fog bebootolni a gépen. Sajnos igazam is lett. A képen látható állapotig jutott, majd ott keményre fagyott:

NetBSD 3.0.1
----------------

A NetBSD legutolsó kiadása sem bizonyult "ügyesebbnek":

Még addig sem jutott, mint az OpenBSD. Lehet, hogy nem volt jó hatással rá a monitoron levő doboz?

<poén>

És a végén egy kis ráadás. A poén kedvéért kíváncsi voltam, hogy egy ilyen vas elég lenne-e a Windows Vista-nak. Gondoltam feltelepítem, négy processzormag, 2 GB RAM csak elég lesz. Sajnos csak idáig jutottam:

"No physical memory is available at the location required for the Windows Boot Manager. The system can not continue."

</poén>

Mivel a tesztek elején az volt a célkitűzésem, hogy megtudjam, hogy out-of-the-box melyik OS támogatja a vasat teljes egészében, azt kell mondanom a tesztek végén, hogy egyik sem. A legközelebb az Ubuntu és a FreeBSD áll hozzá. Az előbbit egy kicsit hackelni kell a telepítés befejezése előtt, hogy boot-oljon, a másik pedig egyelőre nem ismeri a hálózati chip-eket (gondolom a -CURRENT már igen). Az OpenBSD esélyes, hogy némi debug után beboot-oljon, a NetBSD viszont elég hamar, már a boot-olás elején feladta. Van még mindegyik projektnek mit dolgoznia.

Hát ennyit a tudomány és a technika újdonságaiból mára.

( trey | 2006. 08. 31., cs – 20:08 )

Érdekes megfigyelni, hogy míg FreeBSD alatt csak "make -j 4"-ig adott jobb eredményt a több szálon való fordítás, addig Linux alatt még a "make -j 8" is jobb volt.

--
trey @ gépház

Minden bizonnyal, de mondjuk ütemező nem lehet? Nem vagyok benne biztos, hogy a Linux O(1) ütemezője nem jobb, mint a FreeBSD 4BSD ütemezője. Legalábbis sok processzoros rendszereken. A Linux ütemezőbe azért meglehetősen sok olyan új funkció került, ami ezeket vasakat jól támogatja.

--
trey @ gépház

Már sokan leírták, hogy a FreeBSD build processe nagyon nem párhuzamos.

Közelebb járnál az igazsághoz, ha ugyanazon a gépen, ugyanazzal a Linuxszal fordítanál kernelt FreeBSD és Linux OS-ekkel. Bár ez sem fair, de egy fokkal értelmesebb összehasonlítani a kettőt, mint egy Linux, meg egy FreeBSD kernel-OS fordítást...

"Már sokan leírták, hogy a FreeBSD build processe nagyon nem párhuzamos."

Miért? És lehet erről valahol olvasni?

"Közelebb járnál az igazsághoz, ha ugyanazon a gépen, ugyanazzal a Linuxszal fordítanál kernelt FreeBSD és Linux OS-ekkel. Bár ez sem fair, de egy fokkal értelmesebb összehasonlítani a kettőt, mint egy Linux, meg egy FreeBSD kernel-OS fordítást..."

Nem akartam összehasonlítani, csak érdekességként figyeltem meg. Mi az oka, hogy egyik helyen meg tudják oldani, a másikon meg nem? Vagy nem is cél?

--
trey @ gépház

A kerdes a forditgatos benchmarkolasara vonatkozott (es amint Trey valaszabol kiderult, nem az volt az elsodelges celja).

Ennelfogva teljesen mindegy, hogy a NetBSD hol butul, ill. hogy az eredmenyul kapott binarisok jok lennenek-e barmire is (a celarchitektura is lehetne akarmi). A lenyeg az az, hogy a NetBSD buildworld procedura ugyanugy mukodik minden Unix-like oprendszeren, es egy szep nagy kerek kompilacio.

"A lenyeg az az, hogy a NetBSDbuildworld procedura ugyanugy mukodik mindenutt, es egy szep nagy kerek kompilacio."

Lehet, hogy félreértek valamit, de hogyan pörgessek le ezen a gépen egy NetBSD world-öt, ha nem tudok rá NetBSD-t telepíteni, mert már a telepítő is pánikol? :) Vagy nem erre gondolsz?

--
trey @ gépház

Kibaszottul egyszerű, ez a szép benne.

Lehúzod az src fát valamelyik tükörről, a toplevelen ott csücsül egy build.sh nevű szkript, azt kell különféle targetekkel meghívni, és szépen megcsinál mindent. Egy cross toolchain felépítésével kezdi, ha azon túlvan, már nemigazán játszanak be a host perverziói.

Mindez részletesen ki van fejtve a http://netbsd.org/guide/en/chap-build.html helyen, röviden ennyi (az ottani példák alapján sparc64 architektúrára): 


./build.sh -u -m sparc64 tools
# kernel konfig hackelés, sys/arch/sparc64/conf alkönyvtárban
./build.sh -u -m sparc64 kernel=MYKERNEL
./build.sh -U -u -m sparc64 build

Mert nem az volt a cél? :) A fordítások arra szolgáltak, hogy megnézzem stabilan megy-e egy rendszer. A cél az volt, hogy ha valaki rendel egy ilyen gépet, akkor mondhassam, "Hogy Linux? Igen, azzal megy, de figyeljen az initrd-re", "OpenBSD? Hát azzal nem igazán." A számok csak melléktermékek és max. megfigyelések, hogy egyik helyen így viselkedett, a másik helyen meg úgy. Nem vontam le belőle semmilyen következtetést. Az ebben a cikkben levő számok max. arra jók, hogy ha valaki ugyanezt a kernelt lepörgeti ugyanezzel a "make allyesconfig"-gal egy másik gépen, akkor lesz valami fogalma arról, hogy mondjuk a régi Xeon gépénél egy ilyen konfig jobb-e vagy sem.

--
trey @ gépház

( godot v | 2006. 08. 31., cs – 20:15 )

Csak ha van időd, egy DflyBSD 1.6 -ot még elindíthatnál rajta.

Üdv
Godot

( wowbagger v | 2006. 08. 31., cs – 21:12 )

Hihi. Vicces az az SBS 2000 a monitor tetején :)
__________________________________________________________
Az életben csak egy dolog a szép, de az épp nem jut eszembe.

( uid_228 | 2006. 08. 31., cs – 21:21 )

Engem ez érdekelne a dmesg-ből:

[ 132.361007] Vendor: ESG-SHV. Model: SCA HSBP M1..... Rev: 1.39
[ 132.361014] Type: Enclosure ANSI SCSI revision: 03
[ 132.361049] 2:0:42:0: Attached scsi generic sg3 type 13

Ha SATA vinyó van benne és gondolom olyan hot-swap szekrény is, akkor ezt hogyan érzékeli a Megaraid kártya? :o Valami smbusos okosság és SCSI processzornak mondja a host felé? :)

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Huh, nem tudom. Megmondom a frankót, nem nagyon mélyedtem bele a kártya lelki világába, mert perpill SAS lemezem nincs. SATA diszk van rajta, mert abból van egy szakajtóval, de a teszt kedvéért is csak egyet tettem bele mert lusta voltam a keretekbe a vinyókat belecsavarozni.

--
trey @ gépháza

Na jó, de azt csak látod, hogy megy-e még valamilyen kábel a kártyától a rackhez, nem? :)

A Fujitsu-Siemens TX150-ben SMBus kábel van a "RAID"-kártya (fospumpa Promise S150TX4, de utálom) és a kalicka között. Azért is kérdeztem, az előbb hátha itt is.

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

Ezek a kábelek vannak rajta.

http://hup.hu/old/images/trey/work/woodcrest/S3600020.JPG
http://hup.hu/old/images/trey/work/woodcrest/S3600021.JPG
http://www.intel.com/design/servers/raid/pix/srcsas18e_lg.jpg

Más kábelről nem tudok. :)

Szerk: ja, megnéztem a PDF-ben, hogy mire gondolsz. Nem emlékszem ilyenre (a kártya képén se látok hasonlót), de reggel megnézem pontosan.

--
trey @ gépház

Igen. BIOS-ban lehet ki/be kapcsolni.

"Intel® I/O Acceleration Technology (Intel® I/OAT) is available on new Dual Core Intel® Xeon® Processor-based Servers. These servers feature Intel gigabit LAN on motherboard connections.

You can add additional Intel® I/OAT-capable ports by installing Intel® PRO/1000 PCI Express* Server Adapters."

http://www.intel.com/technology/ioacceleration/buy.htm

--
trey @ gépház

( bra | 2006. 09. 01., p – 10:52 )

Le akartam tölteni ezt a cikkben említett kernelt és ledöbbentem. Megszűnt az a sok éves gyakorlat, hogy mindegyikből kiadnak egy .tgz-t és egy .tbz-t és most már csak patchek vannak?

( budee | 2006. 09. 01., p – 23:53 )

nekem ez a "make allyesconfig" nem muxik. P4-es gepemen semmi gond, amd64-en: 

...
  BUILD   arch/x86_64/boot/bzImage
Root device is (9, 0)
Boot sector 512 bytes.
Setup is 7233 bytes.
System is 13125 kB
System is too big. Try using modules.
make[1]: *** [arch/x86_64/boot/bzImage] Error 1
make: *** [bzImage] Error 2

real    98m40.115s
user    90m31.839s
sys     3m58.667s

Erdemes megnezni mennyi ideig tart, normalis esetben ezen a gepen a kernel kevesebb mint 5 perc. gcc 4.1.1 es 3.4.6-ot probaltam.

AMD64-en nem is megy tovább. Nekem is idáig jutott. Csak éppen 24 perc alatt, egy szálon :)

Most lepörgettem egy i386-ot a P4 notebookom-on "allyesconfig"-gal. Az végigmegy, az eredmény:

real 76m58.476s
user 48m28.238s
sys 4m50.290s

Egyébként az AMD64 az utolsó lépésnél

->

BUILD arch/i386/boot/bzImage
Root device is (3, 4)
Boot sector 512 bytes.
Setup is 7287 bytes.
System is 13881 kB
Kernel: arch/i386/boot/bzImage is ready (#1)
Building modules, stage 2.

<-

áll meg, innen más csak pár másodperc a vége egy i386-on is.

--
trey @ gépház