Nieuw reactie in topic: [Benchmarks] Het grote: "Post hier je RAID scores topic" II

ik verwacht uiteraard ook geen superprestaties van een onboard controller die op de pci bus zit aangesloten, maar ik ben zeker niet ontevreden met de snelheid vergeleken bij een single hitachi 7k250 160gig.

2x Samsung T166 320GB SATA2, 16MB, NCQ, op een Asus M2V SLI Deluxe moederbord (nVidia MediaShield RAID controller):



Ik vind dit persoonlijk nogal vies tegenvallen op m'n vorige setup (2x Maxtor 120GB SATA1 op een VIA RAID controller) haalde ik bijna dezelfde scores. Iemand enig idee waar dit aan kan liggen? Op het moment staat de block size op 64K. Zou het helpen als ik die op 128K zet? Zoveel verschil moet dit toch niet maken? Verder heb ik de nieuwste drivers gedownload enz, dus dit is het probleem ook niet volgens mij....

Test eens met een andere blokgrootte (64K of hoger). Hier heb je wel de laatste versie van HD Tune voor nodig (2.54).

2x Maxtor MaxLine 3 7L320SO 320GB Sata-1in Raid0 Striping.
Asus A8N32-SLI Deluxe
Silicon Image 3132
512Kb Block Size

@RooN en CDAAbeltje, probeer het eens met Atto-256? Krijg je denk ik veel realistischere scores.

Done



Volgens mij scheelt het niet veel....

quote:

CDAAbeltje schreef op dinsdag 02 oktober 2007 @ 16:34:
Done

Wel 256MB transfer size (in ATTO "Total Length" genoemd) gebruiken dan he.
Indien hij niet verder gaat dan 32MB dan heb je de oude versie. Haal een nieuwe versie op in de topicstart, daar staat een link naar de juiste "256MB" versie.

quote:

Enlightenment schreef op dinsdag 02 oktober 2007 @ 17:26:
[...]

Wel 256MB transfer size (in ATTO "Total Length" genoemd) gebruiken dan he.
Indien hij niet verder gaat dan 32MB dan heb je de oude versie. Haal een nieuwe versie op in de topicstart, daar staat een link naar de juiste "256MB" versie.

Dan moet het dus zo goed zijn ?! :



Wel weer wat verschil maar ik heb geen idee of dit nou voor mijn striping snel of niet snel is

Niet bepaald. Even wat vragen:

Station g, is deze:
- 100% leeg?
- vult deze je hele RAID0 volume? of heb je nog andere partities?

De write scores die je krijgt zijn onacceptabel laag namelijk. Heb je misschien windows filesystem write-back uitgeschakeld?

- Sation G is niet 100% leeg er staan nu momenteel 3 DVD's op. Ik wil juist deze 2 schijven in Raid0 gaan gebruiken als download schijf.
- Ik heb op deze 2 schijven die de Raid0 striping maken geen andere partities gemaakt !

Hoe zit het trouwens met de Read scores ? Zijn die wel acceptabel ?

Waar kan ik zien of Filesystem Write-Back aan of uit staat ?

Edit:
Ik heb nog eens een beetje zitten te prutsen met ATTO. Als ik de instelling van Overlapped I/O verander naar Neither dan haal ik de volgende scores:




Ik weet niet of dit dan wel de goeie instelling is want ik zie het bij de rest van de testers anders staan. Maar goed. Kan iemand mij vertellen waarom mijn score dan zo laag is als ik hem test op Overlapped I/O ?

ik had toch meer verwacht van mijn setup


4x samsung 501LJ (500gig) in raid 5 op een highpoint rocketraid 2320 controller

Msi K9N Sli F2 (Nvidia 570 chipset)
X2 6000+
Gskill 2gb 6400
2x Seagate Barracuda 7200.10 80GB Sata 2 en NCQ in RAID 0 met een blocksize van 128





//Schijven functioneren als mijn systeemschijf btw

Asus M2N-e (NF 570Ultra)
AMD X2 3800+ (2.0GHZ) @ 2.6GHZ
2GB Corsair XMS2 PC6400
2xWD Raptor 36GB (oude versie) in raid0 met een blocksize van 128KB





Deze schijven zijn voor m'n boot

-Ze presteren niet 100%, wat zou ik hier aan kunnen veranderen zodat ze wel goed werken ?

Naar mijn weten heb ik niets verandert aan mijn Raid0 opstelling maar nu zijn de scores wel dik in orde. Volgens mij moest de Aray ff wakker worden ofzo



Joost mag weten wat er verandert is

quote:

saikoboarder schreef op woensdag 03 oktober 2007 @ 17:16:
ik had toch meer verwacht van mijn setup
[afbeelding]

4x samsung 501LJ (500gig) in raid 5 op een highpoint rocketraid 2320 controller

Je draait RAID5 dus is HDTune een zinloze benchmark om performance te meten. Probeer het eens met ATTO-256 of een andere benchmark die via je filesystem test.

quote:

CDAAbeltje schreef op woensdag 03 oktober 2007 @ 23:20:
Naar mijn weten heb ik niets verandert aan mijn Raid0 opstelling maar nu zijn de scores wel dik in orde. Volgens mij moest de Aray ff wakker worden ofzo

[afbeelding]

Joost mag weten wat er verandert is

Ik vermoed toch dat je write-back hebt ingeschakeld. In het nederlands heet dit zoiets als "optimaliseren voor snelheid", terwijl de andere optie is "optimaliseren voor snelle verwijdering". Als ik het me goed herinner. Write-back staat ook op meer plaatsen in windows configuratieopties. Safe mode of een diagnostic mode zet write-back mogelijk ook uit.

quote:

Jelmer-AMD schreef op woensdag 03 oktober 2007 @ 20:42:
Asus M2N-e (NF 570Ultra)
AMD X2 3800+ (2.0GHZ) @ 2.6GHZ
2GB Corsair XMS2 PC6400
2xWD Raptor 36GB (oude versie) in raid0 met een blocksize van 128KB

-Ze presteren niet 100%, wat zou ik hier aan kunnen veranderen zodat ze wel goed werken ?

Welke controller gebruik je precies? Toevallig een 'extra' controller op je moederbord?

wow
HD-tune


tegenover ATTO


klein verschil dus.

quote:

Je draait RAID5 dus is HDTune een zinloze benchmark om performance te meten. Probeer het eens met ATTO-256 of een andere benchmark die via je filesystem test.

Kan iemand me hier iets meer uitleg bij geven ?
Hoe verschillen de testen van HD-tune en ATTO ?

Welke controller gebruik je precies? Toevallig een 'extra' controller op je moederbord?
[/quote]

Ik gebruik de Nvidia Raid Controller van de Asus M2N-e Nforce 570Ultra en er zit geen extra controller op mijn bord

quote:

Jelmer-AMD schreef op woensdag 03 oktober 2007 @ 20:42:
Asus M2N-e (NF 570Ultra)
AMD X2 3800+ (2.0GHZ) @ 2.6GHZ
2GB Corsair XMS2 PC6400
2xWD Raptor 36GB (oude versie) in raid0 met een blocksize van 128KB


-Ze presteren niet 100%, wat zou ik hier aan kunnen veranderen zodat ze wel goed werken ?

Lijk me niet echt in orde, een losse raptor 73GB zit op 84MB max. in HD Tune bij mijn. De burst is ook erg laag.

Ik hoop toch dat de Nforce 570 controller iets beter presteert, ga namelijk ook twee raptors draaien op die controller.

Wat doet een losse schijf bij jou ongeveer?

quote:

saikoboarder schreef op donderdag 04 oktober 2007 @ 19:58:
Kan iemand me hier iets meer uitleg bij geven ?
Hoe verschillen de testen van HD-tune en ATTO ?

ATTO is een benchmark die zijn I/O via het filesystem doet, je ziet ook een driveletter bovenin, zoals C:. Dat is dus een filesystem, meestal NTFS of anders FAT(32). Dat betekent dat je filesystem de eigenlijke I/O doet, ATTO doet aanroepen naar de Virtual Filesystem (VFS) layer van je besturingssysteem zodat het programma niet hoeft te weten hoe NTFS werkt.

HDTune is een sterk synthetische benchmark, eentje die rechtstreeks I/O requests stuurt naar fysieke hardware, dus buiten het filesystem om. Het gevolg is dat elke optimalisatie die je filesystem uitvoert bij HDTune niet wordt gebruikt. HDTune stuurt dom I/O requests en gaat met het voetje trappelen totdat er antwoord is ontvangen, waarna het verder gaat met de volgende request. Voor hardeschijven is dit doorgaans geen probleem omdat deze niet veel performance verliezen volgens deze methode. Echter, ga je RAID-arrays testen dan wordt het verhaal heel anders.

Ga je HDTune op een RAID-array uitvoeren dan krijg je geen valide resultaten. RAID is sneller niet omdat het I/O requests sneller uitvoert, maar omdat het er meer tegelijkertijd kan uitvoeren. Als je filesystem een file leest, stuurt het bijvoorbeeld gelijk 10 I/O requests in plaats van 1 tegelijk. Dit staat bekend om read-ahead; het leest alvast vooruit. Gevolg is dat je RAID-array opeens 10 requests krijgt. Even simpel gezegd kan deze bijvoorbeeld 5 requests naar schijf0 sturen en de overige 5 naar schijf1. Theoretisch (en in dit voorbeeld ook in de praktijk) ben je dan twee keer zo snel klaar.

Je kunt dit verhaal een beetje vergelijken met een single threaded programma die geen gebruik kan maken van dual of quadcore, welke net als RAID ook gebruik maken van parallellisatie om bepaalde taken te versnellen. Een quadcore kan een instructie niet sneller verwerken dan singlecore, maar kan er wel 4 tegelijk verwerken. Hetzelfde principe gaat op bij RAID.

ok bedankt voor de nuttige uitleg

@saikoboarder: ik ben een blog-post aan het schrijven op mn site over dit onderwerp. Mag ik je vragen jouw twee screenshots te gebruiken hierin? Helaas heb je je DM uitstaan, anders had ik het zo wel gevraagd.

geen enkel probleem
als je andere benches nodig hebt laat het maar weten.

Oke hier is hij dan: Why HDTune is unsuitable for RAID arrays.

Wel in het Engels, maar ja ik heb het je al in het Nederlands uitgelegd natuurlijk.
Bedankt voor de pics!

Sorry maar ik denk dat jouw artikel en jouw uitleg hierboven gewoon niet juist zijn.
Vooral de vergelijking met de dual/quadcore CPU's klopt niet.

Een belangrijke parameter bij de verschillende benchmarks is de blokgrootte die gebruikt wordt om de requests te maken. Laten we dit gemakshalve de request size noemen.
Stel dat we uitgaan van een Raid0 configuratie met vier HD's en een striping size van 32KB. De ideale request size is dan 4x32KB = 128KB.
Als de request size in HD Tune is ingesteld op 128KB zul je dus (in theorie) de maximale snelheid halen. Dus een enkele request wordt netjes verdeeld over de vier HD's die tegelijk gaan lezen (parallelle verwerking).
Een quadcore CPU presteert pas optimaal als het vier verschillende instructies kan uitvoeren. Jouw vergelijking loopt hier dus al mank.

Een tweede fout maak je door te zeggen dat HD Tune de I/O requests rechtstreeks naar de fysieke hardware stuurt. Klopt niet. HD Tune stuurt de requests naar de driver van de fysieke hardware.
Het lijkt me veel logischer dat eventuele optimalisaties in die driver zitten en niet in het filesysteem.
Of een request nu van een synthetische benchmark of een leesbewerking van Windows komt maakt voor de controller niets uit. Het zijn gewoon sectoren die gelezen of geschreven moeten worden.

Je zegt dat HD Tune maar een request tegelijk maakt en dan rustig op een antwoord wacht. Dat geldt uiteraard voor alle requests en dat is ook helemaal geen probleem voor een degelijk RAID systeem.
Stel dat in hetzelfde voorbeeld de request size in HD Tune is ingesteld op 32KB. Dit gaat er hoogstwaarschijnlijk gebeuren:
HD Tune stuurt requests van 32KB, de RAID controller accepteert die en geeft onmiddellijk antwoord (request is uitgevoerd) maar pas na de vierde request gaat de RAID controller de requests doorgeven naar de HD's.
Ondertussen blijven de requests van HD Tune komen. Dus uiteindelijk heb je hier dus ook gewoon een parallelle verwerking van de gegevens met maximale prestaties.

Die 10 gelijktijdige requests waar jij het over hebt worden volgens mij ook allemaal netjes na mekaar naar de RAID controller verstuurd (die ze dan wel parallel gaat verwerken).

De resultaten van verschillende benchmarks die hier gepost worden komen bijna altijd overeen (rekening houdend met de request size). Jij pikt er net een test uit waar de resultaten niet overeen komen. Dan lijkt het mij toch interessanter om te onderzoeken waarom deze test, in tegenstelling tot de anderen een grote afwijking toont. De excessieve CPU belasting (81.4%) doet mij toch al vermoeden dat er iets niet juist is.

Mij heb je dus niet kunnen overtuigen dat HD Tune niet geschikt is om RAID systemen te testen.

Voor het testen van RAID systemen is het wel aan te raden om versie 2.54 te gebruiken omdat je daarmee de request size kunt instellen.

@ Twister336

Ik weet niet wat HD Tune gebruikt bij versie 2.53 en lager met betrekking tot de request size, maar ik zie geen schokkende verschillen tussen 2.53 en 2.54 . Ik heb diverse request sizes getest van 64KB t/m 8MB.

De RAID set gebruikt een 128KB stripe size.

Met 2.54 8MB request size:


Met 2.53:


En hier de ATTO benchmark: