2xRaptor36 v RAID0 @ Silicon Image 3112

[MaWa]

Read seek avg : 5.2
Full stroke : 10.2
Track-2-Track : 0.7
nejmenší stopa (track) by měla mít 614 sektorů, což dělá 307 KB
největší cirka dvojnásobek
seek přes dejme tomu 500KB je tedy 0.7ms
seek přes 15GB (cca 8000 krát větší vzdálenost) má 5.2ms
Tomu já říkám srovnatelné hodnoty.

no nevim...pokud má nějaká veličina minimální hodnotu 0.7, maximální hodnotu 15, tak mi teda potom hodnoty 1 a 5 nepřijdou jako "skoro stejné"...jiný by to bylo, kdyby minimum bylo 0 a max třeba 100...

Samozřejmě ale mají tyhle různé nasazení vztah vůči sobě, jistou korelaci výkonu tam najdeš. Jde jen o to, jak moc velkou a já myslím že dostatečně.

?!? jaká různá nasazení ?!?

Ad řadič - tím ale přichází úplně jiná rovina diskuze o hodnověrnosti výsledků většiny testů, že? I těch na SR/AT.

tak teď sis teda blbě naběhnul ...je vidět, že nevíš, co to je IPEAK. o anandtechu se nevyjadřuju, tam nevim jak se testuje, ale IPEAK na SR je vůči těmto věcem imunní (pokud se to explicitně nevypne)...a nejem vůči nim. jde prostě "až k disku", nezajímá ho nějaký pokaždý jiný caching woken, nezajímají ho ani drivery na řadič (igh-level drivery myslim) atd...

BTW graf v HDTachu na tom sil3112 R0 poli nemá typickou sestupnou tendenci ale je to docela trhaná stálá křivka.

nj protože seš omezenej PCI...a možná i SATAnem

Já to testoval na prázdném 2mb cache 60GB 180GXP, ntfs, winxp

tak to máš "smůlu"...tohle je jediný nedochůdče z rodiny 180gxp...a taky už neni nejnovější.

pošta je domácí použití. A nezapomínej, že ty největší lamičky si posílají největší maily (2MB příloha s ppt prezentací atd.)

jo, to sice jo, ale na 2MB příloze se teda RAID neprojeví ani náhodou. navíc - myslíš, že si wokna tu přílohu uloží do jednoho fragmentu ? ani omylem...hezky jí rozkouskuje = konečná pro raid 0, jakmile to má číst...

Nevím jak je UT2k4 náročné na paměť, ale Q3A taky alttabuju instantně
Ale zní to hezky, budu muset zkusit. Stačí sehnat druhý 180GXP 60GB, udělat s ním SR0 a dát tam pagefile

ut2k4 je poněkud novější než q3a...takže asi žere víc paměti. ale kolik, to netušim, nikdy jsem neměl potřebu to nějak zkoumat. je fakt, že to nehraju uplně na nejvyšší detaily, mam jenom gf4 ti4400 128mb, takže jedu na 1024*768 na vyšší střední detaily...což to taky může ovlivnit.

Ad MTBF ... čili zhruba to co jsem říkal, jen jsem to řekl málo statisticky

no...zhruba asi jo...ale četl jsem to po tobě třikrát a moc moudrej sem z toho nebyl, tak jsem napsal svojí variantu

Nemůže být větší, ale to neznamená, že nemůže být roztažený přes dva stripy. Špatně jsem se vyjádřil. BTW na tom silu když dáš vytvořit pole automatiky, udělá ss=16KB Takže bych se ani nedivil kdyby to tak spousta lidí měla.

velikost stripe - njn, když tomu lidi nerozuměj...

Navíc se do toho plete zarovnávání souborů v NTFS na 32KB (myslím) úseky (které se pak ignoruje když dochází místo) a ukládání miniaturních souborů přímo do MFT

zarovnávání na 32kb ?!? wtf ?

Na to, že když pošleš další request, je podle statistik velká šance, že bude blízko za prvním, potenciálně v cache. Ani jeden znás asi nezná přesně adaptivní algoritmus cachování který disky používají, ale věřím že při šanci na využití 1e-6 by na disk nikdo nedal pro tyto účely 8MB paměti

aha tak to jo...no já předpokládal, že když píšeš, že předcházející request byl "daleko", tak i ten následující bude zase "daleko" (prostě random, ne nějaká lokalizovaná pattern)...a tudíž bude impossible ho nacachovat
read cache v zásadě funguje tak, že disk načte sektor, který je requested, a pokud nemá nic dalšího na práci (což minimálně chvíli platí vždy), tak načte do zásoby i celej zbytek tý stopy...resp. nechá tam něco rezervu podle velikosti a tak...většinou tam nechá i kus předcházejících dat...ale v zásadě to funguje takto.

já jsem ovšem spíše příznivec malého pagefile někde na disku Dávat to do ramdisku mi přijde jako plýtvání pamětí, kterou může OS využít jako diskovou cache.

no když jde o výkon...tak neni co řešit. ale já osobně taky dávám přednost "hdd tuningu" a patlám se s tim, kde má bejt swap, kde os, kde data, jak velký clustery, na jaký kšandě, jaký oddíly...je to levnější a je to zábavnější

Spíš by to chtělo zjistit, jak nakombinovat Program Files, Games, Documents and Settings, Windows a pagefile na jednotlivé disky/pole např na dva nebo tři. Respektvie zjistit, co se používá s čím najednou a co ne tak moc. A jestli to má cenu zjišťovat.

obecně je nejlepší koupit dva disky s maximální možnou kapacitu na trhu (tzn dnes 7k400 400gb), na prvnim udělat ntfs oddíl s co nejmenší velikostí na os, dokumenty, programy a na druhym udělat ntfs oddíl o velikosti třeba 2gb a do něj nacpat swap a nastavit ho na pevnou velikost 2gb...a zdefragmentovat...
popř. pokud je to "mission critical" aplikace, tak koupit ještě třetí disk a dát tu aplikaci (+ její data) na třetí disk sólo
výhody tohoto jsou, že v zásadě je cena stejná jako u raidu, ale nemusíš se děsit jakou nastavit stripe, jestli bude řadič fungovat nebo se srát, a taky když odejde jeden disk tak ti neodejdou všechny data...