Vlákno názorů k článku FreeBSD 7.0 je venku i s mnoha novinkami od Radek Hladik - Nove FreeBSD je opravdu zajimave. Ta spousta novych...

Nove FreeBSD je opravdu zajimave. Ta spousta novych vlastnosti je vcelku uctyhodna. Ale nic neni tak ruzove, jak se to upece, takze par postrehu z meho zkouseni:
* Pod virtualboxem jsem FreeBSD nenainstaloval, protoze mi nechodila sitovka (system ji sice najde, ale ona proste nefunguje). Nekde radili rucne prepnout na 10MBit, ale v te fazi instalace nebyl jeste k dispozici shell (a cele ISO se mi tahat nechtelo)
* iSCSI ma pomerne mizerny vykon, na 100MBitu mi delalo 600KB/s pod VMWare, 1.5MB/s na realnem HW s Realtek RTL8111. Meril jsem obycejny read z daneho zarizeni dd if=/dev/da1 of=/dev/null. Zajimave bylo, ze se zvetsujici se blocksize rychlost rostla, ale maximum bylo 8.5MB/s (pro blocksize 1M). Na gigabitu se u blocksize 512 rychlost zvedla na dvojnasobek (tedy 2.5MB/s) a u 1M uz dosahovala nejakych 25MB/s (maximum, ktereho jsem dosahl). Sit pri tom pri SSH prenosu dosahovala "normalnich" hodnot, tedy napr. 11.5MB/s pro 100MBit. Zrejme system nekde na neco nevhodne ceka, protoze si jinak nedovedu predstavit, proc na gigabitu, ktery je 10x rychlejsi dojde u stejne blocksize jen k 2x navyseni. A pak je taky zajimave, ze pouzitelne hodnoty se zacinaji objevovat az nekde u nekolika set kilo. Spis bych cekal, ze se to bude pohybovat nekde u hranice 1500B (kvuli velikosti packetu).
* iSCSI initiator nema uplne nejluxusnejsi ovladani. Napriklad mit na iSCSI / si nedovedu moc predstavit, jak bych delal. Pro srovnani nova Fedora 8 uz pri instalaci nabizi pripojeni iSCSI targetu a automaticky si upravuje i bootovaci ramdisk (jen je potreba kernel a ramdisk nejak spustit ze site, nebo mit /boot na lokalnim necem)
* USB subsystem pouziva stale giant-lock, jeste jsem nemeril vliv na provoz, pokud system bude na USB HDD
* a to nejlepsi na konec. FreeBSD 7.0RC2 AMD64 nam s onim realtekem 8111 "sestrelilo" cele dva racky, kdyz nejakou chybou odeslalo frame, kde jako svoji MAC adresu uvedlo MAC adresu internetove gateway. Switch z toho byl kupodivu docela zmateny :-) A cele sitovani fungovalo tak, ze vypadavaly packety, SSH hlasilo Invalid Packet Length a nejake hausnumero, atd... Zatim jsme nezjistili, zda jde o chybu sitovky nebo toho presouvani TCP prace na sitovku. Nekteri stejne postizeni psali, ze se jim toho podarilo zbavit vypnutim prave txsum, rxsum a podobnych...

Takze zaverem, FBSD 7 vypada opravdu hodne zajimave, ma spoustu novych a peknych funkci, ale doporucuju poradne testovat a testovat...

v Vmware BSD7 pochopitelne bezi, krom toho iscsi test se sitovkou Realtek ma asi takovou vypovidaci hodnotu jako doba za kterou umejete podlahu zubnim kartackem.

Nu, vaše poznámka zní dost lame, ale i tak stojí za zmínku, že Fedora Core 7 na tom samém hw zvládne přes iSCSI vytížit naplno gigabit (cca 115 MB/sec)...

Vsak jsem taky psal, ze sitovka nefunguje pod Virtualboxem. Pod vmware server samozrejme funguje, emulovana e1000 je schopna udelat az 11.5MB/s na 100Mbitu pri prenosu pres SSH (vcetne sifrovani), ale iSCSI dela jen 600KB/s. (na jinak temer nezatizenem Dual Core Pentiu 2.4GHz se 2GB RAM).
Na invektivni zbytek prispevku reagovat neminim...

Nenapsal jste co je to za Realtek, ale pamatuji si ze kdyz jsem naposledy s Realtekem pracoval, dokazal jsem na 100 Mb sitovce vytahnout maximalne 6 MB/s. Navic musite vzit v uvahu, ze virtualizovana sitova karta (zvlast pokud se fyzicky lisi - a ze se E1000 a Realtek lisi opravdu dost) jen velmi tezko dosahne stejne rychlosti jako fyzicky HW. Nicmene se domnivam ze prispevek ktery jste oznacil za invektivni mel do invektivy velmi daleko - neznam zadny server ktery by pouzival Realtek sitovou kartu (pokud se nebudeme bavit o samo-domo-na kolene serveru). Za vypovidaji vysledek bych akceptoval test rychlosti na gigabitu treba e1000 (ktery je hojne pouzivany) a primo na fyzickem HW.

Psal jsem, ze to byl realtek 8111 (gigabit). Virtualizovana e1000 muze samozrejme mit nizsi vykon, ale rozhodne ne desetinovy. A vmware server se pouziva i v ostrych nasazenich, takze testy na nem nejsou uplne od veci.
Ale kazdopadne jsem pod vmwarem i na fyzickem hw zkousel prenosy pres SSH ( ssh user@server 'dd if=testfile' | dd of=/dev/null ) a ty dosahovaly realnych limitu (a to i pod vmware). Navic jsem pak na obou konfiguracich vyzkousel open-iscsi pod linuxem a opet jsem dosahoval realnych limitu. Navic u SSH (poustel jsem ho pod FreeBSD) jsem nijak nevypinal sifrovani, takze tam byla jeste zatez na CPU. Ale vyplyva mi z toho, ze sitova vrstva FreeBSD takovych prenosovych rychlosti byla schopna i s realtekem i e1000.
My naopak pomerne hodne serveru s realtekem mame, mozna spadaji do kategorie samo-domo-na kolene, ale svoji praci udelaji a jsou za rozumnou cenu. A konkretne s Realtekem jsem nikdy zadne problemy nemel, dokonce stara rtl8139 mi spolehlive fungovala a funguje vsude, kam jsem ji dal. Mozna ma o trochu nizsi vykon, mozna vic zatezuje procesor, ale zatim mi to nikde nevadilo... A bezproblemova a spolehliva FastEthernet karta s naprosto postacujicim vykonem za 100Kc... Ale to je na jinou diskuzi.

Pokud se nepletu, tak FreeBSD má nebufferovaná bloková zařízení, takže při měření přístupu na raw device to bude dost ovlivňovat latence sítě, nikoli její propustnost (prostě --- pošle se packet, počká se na odpověď, až přijde odpověď, tak se pošle další). Spíš to zkus změřit s filesystémem, kde by měl readahead/writeback tu latenci překlenout.

To mi pripada pomerne divne. Mel jsem za to, ze cteni z block device bude nejrychlejsi operace (pokud do hry nevstoupi nejaka cache). Pokud udelam na zarizeni fs a na nem velky soubor, ktery budu cist, tak mi ho bude bufferovat fs vrstva? Ta by prece mela delat maximalne cache na urovni souboru, ale ne preorganizovat komunikaci s blokovym zarizenim.
Ale az se k tomu dostanu, tak to zkusim.

Filesystem bude dělat read-ahead - požadavky na čtení bude posílat předem, v každém momentě tak bude "rozečteno" více bloků než při sekvenčním čtení pomocí dd z devicu.

Nejrychlejší jak na co. Nemá buffery, takže žere míň CPU než filesystém. Na disku readahead není potřeba, protože disk dělá readahead už v sobě a ty ATA příkazy mají mizivou latenci. Na síti je readahead nutnost.

Můžeš si samozřejmě readahead (pomocí aio_* funkcí) dodělat do toho příkazu "dd" nebo "cp", běžně tam není, nemá asi smysl kvůli tomuto jednomu případu iScsi ho tam dodělávat.

problem s iSCSI vykonem byl uz vyresen.. viz:

http://lists.freebsd.org/pipermail/freebsd-scsi/2008-February/003383.html

To vypada zajimave. Az budu mit chvili, tak to zkusim. Nezahledl jsem ale nejake info, co patch opravuje. Na prvni pohled nevypada moc komplikovane, tak by me zajimalo, v cem byl problem a jak to patch resi.

Tak problem timto patchem vyresen nebyl, hodnoty zustavaji porad nizke. Zkousel jsem i dalsi sitovky, gigabit, nullio target atd... Pokud by mel nekdo zajem o detaily, tak jabber radek-test@jabber.cz