2024. március 19., kedd

Gyorskeresés

Útvonal

Cikkek » Számtech rovat

Intel SW-RAID0 miniteszt

  • (f)
  • (p)
Írta: |

Az írás eredetileg egy átfogó tesztnek indult dokumentált benchamark eredményekkel, összegző...

[ ÚJ TESZT ]

Az írás eredetileg egy átfogó tesztnek indult dokumentált benchamark eredményekkel, összegző grafikonokkal és értékeléssel, de csak egy mikroteszt lett belőle, amolyan kis elmélkedés, de tippadásnak/ösztönzésnek talán jó lesz, ha már rászántam az időt megírom...

Bizonyára sokak alaplapján ott lapul egy softweres RAID vezérlő mellyel RAID0 tömbbe rendezhetünk 2-4 (célszerűen azonos tipusú, méretű) winchestert. Biztos sokan fontolgatták is hogy megérné-e a várható sebességtöbbletet a felár két kissebb winyóért 1 nagyobbal szemben.

Persze ha megvettük a winchestereket és a RAID-BIOS előtt ülünk jön a tépelődés hogy valyon milyen stripesize-allocation_unit kombináció lenne jó otthoni használatra.
Ezt próbáltam volna tesztelni itthon, egy, az ICH9R IDE-vezérlőjével felvértezett Gigabyte GA-P35-DS4 alaplapon; 450Mhz-es FSB melett 3,6Ghz-en járó E6420 CPU-val (4Mb cache) 900Mhz-en 4-4-4-14--ben hajtott RAM körítésben 2db 160Gb-os Western Digital Caviar winyóval (8Mb cache verzió). Egyszerűség kedvéért frissen telepített Windows XP SP2 softwarekörnyezetben.

Elmélet:
A mind jobb párhuzamosításnak a lehető legkissebb stripesize kedvez (4K), viszont nagy CPU-IDEvezérlő terhelés léphet fel ami meglassítja a folyamatot. A másik véglet a maximális stripesize (itt 128K), de ez a sok apró fileból álló Windowsunkra leht rossz hatással.
A stripesize duplájával való formázás (allocation unit érték) elvileg kedvezne a lineáris írás/olvasásnak (tömörítés, videómuxolás, stb.), de a stripesizenél kisseb fileokat vagy a véletlenszerű apró csomagonkénti oda-vissza írás/olvasásokat jobban zavarhatja (igen kis stripesizenél viszont még lehet jó).

Nos, két dologra jöttem rá:

A HD-Tune teljesen alkalmatlan stripe-size tesztelésére, de főként az alloccation unit-éra, mert egy összefüggő kötetként megy végig a RAID-tömbön, nem is érdekli hogy van-e rajta partíció, valamint szinte ugyanazt az eredményt kaptam min-max-average speedre és acces timera is minden stripe sizevel (4K és 128K közt), csak a CPU-utilization változott és tűnt értékelhetőnek, de mértékadónak ezt sem nevezném. Úgyhogy az átfogó tesztről lemondtam, mert a másik alternatíva az IOmeter program rengeteg időt vett volna igénybe és mint később más úton megpróbáljuk belátni annyit azért nem számít a stripe-size.

A fontosabb felfedezésem hogy a HD-Tune benchmark szerint rengeteget dob a sebességen (főleg a stripe-sizenél kissebb csomagokkal való tesztnél) ha a matrix storage managerben bekapcsolom a kötetszintű visszaírási gyorsítótárat, de az elvégzett másolgatós-stopperelős tesztem szerint majdnem másfélszeresen lassítja a kötetet! (talán nem véletlenül van alapértelmezésben kikapcsolva)

Miután a benchmarkról lemondtam a fixált rendszerkötetemen összekészítettem magamnak egy mappát egy 700Mb-os AVI-val, 3 MP3 albummal és a windows könyvtárból méret szerinti kereséssel összehalászott apró fileokkal. Ezt többféle stripesizevel kreált és stripesizevel megegyező, vagy ha volt rá lehetőség (64K-ig) akkor annak kétszeresére vett foglalási egységgel formázott partícióra másoltam és ott duplikáltam miközben lemértem az időt stoperrel és néztem a taskmanagerben a CPU terhelést.

Végül arra jutottam hogy 4K-s stripe sizenek állítottam be az egész tárkapacitást és 4K-s foglalási egységgel formáztam (ez az alapértelmezés). Miért?

A duplikálgatós teszt szerint koránt sem kell annyira félni a CPU használtattól mint a HD-tune mérésében, de ott is 20% volt a csúcs úgy hogy csak 1 magot használt a 2-ből, ez szerintem csúcsértéknek belefér a keretbe (ha hevesen ír a winyóra akkor úgyse nyúzza a program a CPU-t, ha meg a CPU-t nyúzza 1000-rel akkor nem akar a winyóra is veszettül írogatni mert gondolkodik mit kell írni...) Ezzel kár foglalkozni a stripe-size eldöntésekor, 2 winyónál ICH9R vezérlővel és egy Core 2-es procival nem kell félni a terheléstől.

A vegyes méretűre válogatott mappám duplikálásakor eltelt idő stopperrel való mérése nem a legpontosabb, de nekem megtette a ~10ms pontosság is, főként hogy alig volt különbség a mérések közt, tehát gyakorlatilag másolási sebességben sincs nagy különbség stripe size kapcsán. A 4K és a 128K néhány század másodperccel elmaradt a 16K-s mellett (neten keresgélve is olvastam hogy 16K lehet a nyerő), de 4K sem volt számottevően lassabb, így valós életbeli sok véletlenszerű ide-oda írogatást-olvasgatást is feltételezve inkább bíztam a gépet 4K-s stripera.

Az foglalási egység pedig stopperrel kimérhetetlen változást hozott duplikáláskor, a fent említett indokkal (esetleges sok random read) inkább 4K-ra tettem az fe-t is (alapértlmezés).

Amit érdemes megemlíteni hogy hasznos a partíciók igazítása, mert az XP alapból 63K-ra alignol, de ez páros értékű stripesizeknél gondot szokott okozni. A Vista telepítős partícionálója elvileg 1024-el is csúsztat, de én nem bíztam a véletlenre, telepétés előtt magam partícionáltam úgy hogy kértem egy recovery consolet és bepötyögtem hogy:
diskpart
select disk 0
create partition primary align=64 size=xxxx
, ahol a 64 legyen egy, a stripesizenél nagyobb érték (8 egész számú többszöröse), a size pedig a Mb-ban értett partícióméret.
Az utolsó sor többszöri ismétlésével feldobtam 4 partíciót, elsőt pagefilenak, 2.-at Vistának, 3.-at XP-nek, a többit minden másnak (oda nem írsz sizet és lefogja a maradékot).
A külön lemez elejére helyezett pagefile partíciót mindenkinek javaslom, legyen a RAM-od 1,5x-ese + 150Mb) és telepítés után ide állítsd majd be a RAM-od 1,5x-esére méretezett pagefilet. (virtuális memória a vezérlőpultban, minimum és maximum érték ugyanarra)

Azóta már felhúztam a Vistát, tömörítettem ki DVD-képfilet rar-okból és elindítottam egy játékot is.
Úgy vettem észre a Vista jobban érzi magát 4K-s stripeon mint 128K-n (bootolási idő, vezérlőpult megynyitása stb...), bár ez lehet attól is hogy most még friss telepítés...
Érzetre nem lassult a tömörítés se és ilyen mércével a játék is hasonló idő alatt töltött be. Sőtt, mikor spawnol a Crysis mintha kevésbé zavarna be a winyónyúzás. (lehet hogy apró csomagokban olvasgat be innen-onnan és így kedvezőbb neki a kissebb stripe ; direkt nem raktam addig fel az új patchet hogy azonos verziót vessek össze, 1.1-el már lehet kevesebbet spawnol...)

Szóval összességében nem bántam meg mert rosszabb tuti nem lett. A pagefilenak és a Vistának szerintem jobb lett 4K-n mint 128K-n. Az még jó kérdés hogy többet ért-e volna 2 tömböt feldobni és a rendszernek szánt helyre 4K, a maradéknak meg 16K, de már mindegy, rosszabb nem lett mint 128K-val volt.

Megjgyzés: A partícióigazítás XP alól nem megoldható (vagyis ha beszerzel egy Windows 2003 SP2-ből származó diskpart toolt azzal megy), csak Vistával.

Értékelés, végszó?

Ne kapcsold be a kötetszintű visszaírási gyorítótárat, hacsak nem teszteled ki magadnak. (alapból ki van kapcsolva)!

Én otthoni használatra Inteles RAID0-hoz 4K-s csíkszélességet javaslok alapértelmezett formázással a fent leírt partícionálási módszerrel (persze XP-t és Vistát értelem szertin nem muszály egyaránt felrakni ha nem igényled, elég az egyik...).
Vagy esetleg olyan megoldást hogy felraksz néhányszor10Gb-nyi tömböt 4K-val amire a Windows és a lapozófile kerül és a maradék helyre 16K-s csíkszélű tömböt 16K-s allocation unittal formázva, ahol tárolod a nagyobb filokat (játékok, filmek, stb.)
(format x: /a:16k) A diskpartnál pedig "select disk 1" parncsal mész át a két kötet közt a partíciók feldobásához.

Aki azt hiszi sétszórt és logikátlan az írás annak igaza van mert összevagdaltam amit a RAID topikban írkálgattam, de így egyben van és talán többen is olvassák. Egyesek talán felfedeznek benne néhány hasznos tippet.

Hirdetés

Copyright © 2000-2024 PROHARDVER Informatikai Kft.