HDD Samsung

[MaWa]

2Marsellus Wallace: Pořád to nechápeš. Jistě že i v desktopovém využití jsou přístupy náhodné, ale kolik jich je? Omezeně!

čemu říkáš náhodný přistup ? definuj prosím, ten pojem. přijde mi, že se každý bavíme o něčem jiném...

Každý program je unikátní natolik, že nemůžeš říct, že obečně to je přístup o půl délky plotny a následné čtení 500 kByte nebo naopak šílené seekování a čtení mála dat.

ano, každý program je unikátní, ale pokud použiješ standardní (typické) programy, tak výsledky všech důležitých "veličin" můžeš použít ze SR testbed3 a použít je v IOMEteru. a věř mi, že jakkoliv defragamentuješ, tak sekvenčních čtení nad 64kB je pod 1%. jinak je to vždycky seek - čtení - seek atd atd...

Jak chceš vytvořit obecnou simulaci přístupů I/O, když nelze určit způsob? V serverech je přístupů hodně, fronta je velká a každý přístup je jinam (dva uživatelé čtou každý jiný program a hlavička si pěkné zalétá). To v desktopech ale není, protože napřed se čte jedna věc a pak druhá.

ano, ale toto vše lze v IOMeteru nastavit, což bys měl vědět, když ho tak kritizuješ...
v IOMeteru lze normálně nastavit I/o depth na 1 (a mnoho serverů tak i s iometerem testuje - např. Neoseeker). lze tam nastavit avg size. externě tam LZE nastavit lokalizaci. tak co od benchmarku ještě chceš ? budeš radši používat c bench, kde sice nemusíš nic nastavovat, ale výsledkem je jedno téměř nic neříkající číslo ? je to jako kdyby jsi testoval auta (disky) a dával jim známky od 1 do 5. třeba bys dal známku autu (disku) 4. to NIC neříká o tom jestli je to konkrétní auto (disk) dobrý v jízdních vlastnostech (u disku třeba v positioningu) nebo třeba ve spotřebě paliva (u disku třeba I/Os per large chunk size). chápeš ? ale na čistě HW serveru se (imho) očekávají takovéhle věci.

V desktopech se jedná více méně o sekvenční čtení větších bloků dat... fronta tady nehraje takovou roli.

z druhou polovinou souhlasím, ale jak to souvisí s IOMEterem a c benchem, o kterém se tady bavíme ?
ad první polovina - každé čtení je STR, pokud nedefinuješ pojem SUSTAINED...

Disk s lepšími I/O nemá pro desktopové použití jednoznačnou výhodu - ano, má jistou výhodu, ale ne nijak dramatickou.

teď si připadám jako v Černých baronech, ale co si představuješ pod pojmem I/O ? asi něco jiného, než já.

Porovnej si výsledky WD Raptor 36GB s ostatními disky (už na to odkazuju asi 100x). V serverech jasně vede, v desktopech jen velmi nepatrně. Proč? No protože seek není u desktopů tak důležitý (lépe řečeno je důležitý, ale ne tak důležitý jako v serverech).

full seek není u desktopu tak důležitý. zase je tam důležitější track-to-track seek. to lze ale obejít lokalizací IOMeteru. už to to také opakuji poněkolikáté.

Pokud se ti to nezdá, tak proč lidi defragmentují? No protože po defragmentaci jsou ty data blízko a disk seekuje kratší vzdálenosti.

seek na krátké vzdálenosti lze v pohodě udělat pomocí IOMeteru stejně jako avg size, což snižuje náhodnost přesně tak, aby to odpovídalo home use.

Binární soubory jsou celistvé a čte se celý binární soubor (je jedno, po jak velkých logických blocích). Pomůže ti defragmentace u serverů, kde jsou přístupy zcela náhodné? To těžko, defragmentovat maličké bloky databází je k ničemu, když mezi nimi není žádná programová spojitost (a to v serverech není).

ano, ale s IOMEterem a server pattern uděláš queue depth třeba 2-8 a přes celý disk a s avg size třeba 4kB, kdežto home use uděláš queue 1-4 (spíš 2) přes 1GB s avg size 32kB (dejme tomu). a je to.

Způsob určení výkonu v desktopových aplikacích je jeden - aplikační testy. Testovat dlouhé fronty I/O požadavků přes IOmeter? K čemu, když taková situace nastává leda v serverech?

aha, žebysme byli u jádra pudla ? víš, ono lze s IOMeterem dělat i depth 1, 2 nebo 4, ne jen 128 nebo 256 (které jsou out i na server use).

"We're going to drop the 256 I/O load. Even busy servers achieve this figure only in burst moments. When considering steady-state loads, 64 I/Os easily represent a very heavy depth indeed." - citace z "tvého" URL. Kolik jich bude v desktopech? Myslíš, že víc? Takže podle tebe jsem měl vzít IOmeter a testovat zcela nereálné přístupy (v desktopech nereálné) nebo formulovat tuny mnou vymyšlených úloh, které se ani nemusí shodovat s realitou? To radši použiju ověřený a spolehlivě fungující test z velmi odborného časopisu c't.

měl jsi někdy puštěný IOMeter ? asi ne co ? v něm NEmusíš testovat 256 depth. ono tam jde i 1,2 nebo 4 queue depth. stejně tak vše ostatní lze nastavit. a pokud ti přijdou výsledky publikované na SR jako vymyšlené, tak to potěš koště

ad c bench - já proti němu nic nemám, ale jak víš, že ten program dělá to, co dělat má ? že v něm není (ad absurdum) jen náhodný generátor výsledků ? na netu působím již docela dlouho, ale žy be stále mluvilo o c t, jak je to odborný server, o tom nevím. jsou jednozančně lepší servery...
z mého pohledu to klidně může být server na úrovni českého živě. a pak mám věřit výsledkům ? proč radši nevydáš trochu námahy a nepoužiješ radši něco, co si sice musíš nastavit, ale pak to již funguje spolehlivě a internetová komunita takový test dostatečně uznává ? znovu opakuji - žádný větší server netestuje pomocí c bench a pokud ano, tak ten výsledek má velmi malou hodnotu, do jaké míry ovlivňuje celkový výsledek testu. proč by to tak bylo, kdyby byl c bench ten nejlepší benchmark na světě (resp. by by lepší než IOMeter, pokud ho někdo umí nastavit) ? proč všichni netestují c benchem když je tak super ? a free ? proč ? protože nikdo na netu ještě nedokázal, že jeho patterny jsou opravdu takové, jaké být mají a nikde na netu není dokumentace, co přesně a jak ten benchmark testuje. a to pak je opravdu akorát bench pro LAMY, které chtějí mít jedno číslíčko, kterým porovnají deset disků a mají jasno, který má to číslíčko největší. pro někoho, kdo tomu alespoň trochu rozumí je ten výsledek naprosto irelevantní. alespoň do doby, než ct ukáže, na jakých patternách se to testuje.