[Smart Array P400] Snelheidsprobleem > 512KB Transfer Size

[FireDrunk]

Beste Mede-tweakers,

Ik zit met het volgende probleem. Ik ben in bezit van een Smart Array P400 Controller met daaraan 2x 500GB Samsung en 2x 500GB Seagate schijven. In mijn windows 2003 server haalden deze tezamen een goede 350~400 MiB/s Schrijven en 400~500 MiB/s Lezen.

Omdat ik het stroomverbruik van mijn server teveel vind om hem altijd aan te laten staan, dacht ik: Ik zet de controller eens in mijn Media Center(Gigabyte 790g Chipset moederbord met A64x2 4850BE)

Na installatie van de Windows 2000 driver (wegens ontbreken van windows XP drivers) had ik resultaten van 50MB/s. Na enig geklooi met drivers (wisselen tussen P400 en P400i) heb ik de volgende resultaten behaald:


http://www.cravu.nl/screenshot.jpg

Deze resultaten zijn dus erg raar. Weet iemand hoe dit kan?

# Ik heb de nieuwste Firmware + Driver + Battery Backed Cache + alle toeters en bellen die het sneller maken...
# Onder Windows 2003 is het bekend dat de RAID Performance beter is, dat weet ik, maar ik vind dit een heel raar verschijnsel

Wie helpt mij?

PS: Net even Sisoft Sandraa gedraait, deze geeft 60MB/s aan bij FileSystem en 160MB/s bij Harddisk.. de 160 MB/s lijkt een gemiddelde van wat ATTO zegt

[ Voor 3% gewijzigd door FireDrunk op 27-08-2008 21:16 ]

[Verwijderd]

Je kunt geen normale benchmarks gebruiken als je een write-back mechanisme gebruikt. Ik ken jouw controller niet, maar als dit een Areca-klasse is met eigen geheugen is het logisch dat je fluctuerende resultaten krijgt in ATTO. SiSoftware Filesystem-benchmark kijk je naar de read/write scores, vergeet die index score daar heb je weinig aan.

Als je controller 1GB RAM heeft, moet je 8GB testbestanden gebruiken, ATTO gaat maar tot 256MB en is eigenlijk een veels te ouderwets programma om een moderne controller op juiste wijze te testen.

[FireDrunk]

In Sisoft Sandra heb ik de File System benchmark gebruikt en er staat dan 160MB/s bij Sequential Read terwijl dit onder Windows 2003 meer was.

Ookal is het misschien geen perfecte benchmark, dan mag ik toch nog steeds dezelfde resultaten verwachten onder windows xp als onder windows 2003?

onder 2003 waren de resultaten misschien ook wel niet kloppend, maar wel consequent in vergelijking tot de block size.

[FireDrunk]

* Neemt een aanloop...

[FireDrunk]

* Neemt aan, en paast door.

[Verwijderd]

Het benchmarken van een write-back mechanisme op Windows is niet gemakkelijk, heel veel benchmarkutilities vallen dan eigenlijk af. Dat is ook de reden dat ik mijn tests veel liever op FreeBSD en Linux doe, aangezien je daar veel meer controle hebt en eenvoudig kan benchmarken.

Als je toch een poging wilt doen, download dan IOmeter. Op dit forum staat een IOmeter topic met een korte 'how-to'. Wat je wilt doen is minimaal 8GB lezen, rustperiode en daarna 8GB schrijven. Dit kun je redelijk gemakkelijk zelf opgeven. Vergeet niet de size in te vullen in de eerste tabblad, anders zal het initialiseren eeuwig duren omdat hij de hele disk vol gaat schrijven. Dat is niet nodig dus als je bijvoorbeeld 4294967296 invult bij de sector count oid, één sector is 512 bytes dus dat getal betekent dat je testfiles 8GB groot worden.

Op deze manier kun je zowel cooldown opties instellen, de test lang genoeg laten duren voor nauwkeurig resultaat, met de queue depth en alignment spelen, zien wat voor invloed dit heeft op je snelheid, etc. Merk op dat je met Windows vrijwel altijd een stripe misalignment krijgt. Op Linux/BSD kun je dit voorkomen door geen partities op de RAID device te plaatsen, maar direct het filesystem.

[FireDrunk]

Heb het al anders opgelost. Toch bedankt voor het reageren.