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

[Fanatic_FS]

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.

[RooN]

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....

[Twister336]

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

[CDAAbeltje]

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

[ Voor 5% gewijzigd door CDAAbeltje op 02-10-2007 12:34 ]

[Verwijderd]

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

[CDAAbeltje]

Done



Volgens mij scheelt het niet veel....

[Verwijderd]

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.

[ Voor 36% gewijzigd door Verwijderd op 02-10-2007 17:28 ]

[CDAAbeltje]

Verwijderd 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

[Verwijderd]

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?

[CDAAbeltje]

- 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 ?

[ Voor 48% gewijzigd door CDAAbeltje op 03-10-2007 09:00 ]

[saikoboarder]

ik had toch meer verwacht van mijn setup


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

[Verwijderd]

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

[ Voor 12% gewijzigd door Verwijderd op 03-10-2007 20:38 ]

[Verwijderd]

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 ?

[ Voor 48% gewijzigd door Verwijderd op 03-10-2007 20:43 ]

[CDAAbeltje]

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

[Verwijderd]

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.

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.

Verwijderd 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?

[ Voor 17% gewijzigd door Verwijderd op 04-10-2007 18:22 ]

[saikoboarder]

wow
HD-tune


tegenover ATTO


klein verschil dus.

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 ?

[Verwijderd]

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

[mad_max234]

Verwijderd 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?

[Verwijderd]

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.

[saikoboarder]

ok bedankt voor de nuttige uitleg

[Verwijderd]

@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.

[saikoboarder]

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

[Verwijderd]

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!

[Twister336]

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.

[MortalPiso]

@ 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:

[ Voor 3% gewijzigd door MortalPiso op 06-10-2007 12:54 ]

[Verwijderd]

@MortalPiso: Areca vertrouwt niet op het filesystem maar gebruikt zijn eigen read-ahead, waardoor hij minder gevoelig is voor missende optimalisaties. Maar bijvoorbeeld een onboard RAID0 doet dit absoluut niet. Je Areca is ook minder gevoelig voor blokgroottes. Dit komt omdat de data toch al klaar staat. Ook al gebruik jij een andere blocksize Areca zelf intern een andere blokgrootte kunnen gebruiken. Het testen van intelligente controllers is vaak niet zo simpel.

Je scores in ATTO zijn fluctuerend omdat je waarschijnlijk Write Back hebt ingeschakeld en ATTO geen pauze inlast tussen de tests. Dus na een write-test waarbij dus 256MB wordt geschreven gaat ATTO gelijk weer een read test doen, maar er wordt op dat moment nog wel data van de write opdracht weggeschreven, wat de scores beïnvloed. Het beste zou zijn op IOmeter te gebruiken waarbij je een cool down pauze inlast, zodat elke benchmark (in dit geval afhankelijk van blocksize) niet beïnvloed wordt door eerdere benchmarks.

@Twister336: op jouw verhaal reageer ik later, moet nu weg.

[Nyarlathotep]

Heb ook even getest. Eerst even de specs:

Intel Core Duo E6750 @3.4
Gigabyte GA-P35-DS4
Intel ICH9R chipset
2GB Team PC6400
2x Seagate ST3250410AS 250GB, 16mb buffer, SATA II, Single Platter









Ik denk dat dit prima resultaten zijn. Alleen die burst score lijkt mij absoluut niet te kloppen. Weet iemand hoe dit kan??
Mijn C: partitie bevat mijn Vista 64 installatie. Ik heb getest onder XP 32.

[ Voor 6% gewijzigd door Nyarlathotep op 06-10-2007 16:23 ]

[Verwijderd]

Hier even een HDtach van de nieuwe Seagate 7200.11



Nu nog even in Raid zetten en dan wordt het leuk.

[ Voor 3% gewijzigd door Verwijderd op 06-10-2007 17:42 ]

[Verwijderd]

@Nyarlathotep: Je hebt een Intel ICHxR controller die je in RAID mode gebruikt en je hebt write-back ingeschakeld. Dan zal je Intel-controller, net als Areca, truucjes uitvoeren waarvan het eindresultaat snelheidsverbetering kan zijn, maar het benchmarken van deze controller veel lastiger is. Je burstscore is authentiek, aangezien alle I/O via je RAM geheugen loopt is dat effectief de throughput van de driver via je RAM geheugen. Je test dus niet (direct) je schijven maar een intelligente controller. Als je Areca test met de oude versie van ATTO (32MB) krijg je ook geen valide resultaten.

[Nyarlathotep]

Verwijderd schreef op zaterdag 06 oktober 2007 @ 17:49:
@Nyarlathotep: Je hebt een Intel ICHxR controller die je in RAID mode gebruikt en je hebt write-back ingeschakeld. Dan zal je Intel-controller, net als Areca, truucjes uitvoeren waarvan het eindresultaat snelheidsverbetering kan zijn, maar het benchmarken van deze controller veel lastiger is. Je burstscore is authentiek, aangezien alle I/O via je RAM geheugen loopt is dat effectief de throughput van de driver via je RAM geheugen. Je test dus niet (direct) je schijven maar een intelligente controller. Als je Areca test met de oude versie van ATTO (32MB) krijg je ook geen valide resultaten.

Dus voor een authentiek resultaat zou ik de write-back optie even uit moeten zetten? Of is de invloed dan alleen merkbaar op de burst rate?
Ik zal straks even de tests runnen met die optie uitgeschakeld. Al kan ik nu wel tevreden zijn met de resultaten, of niet?

[Twister336]

@Nyarlathotep: De resultaten zien er inderdaad prima uit. Je krijgt twee keer de snelheid van een single drive.

Verwijderd schreef op zaterdag 06 oktober 2007 @ 13:27:
@Twister336: op jouw verhaal reageer ik later, moet nu weg.

Ik wacht met spanning

[Verwijderd]

Twister336 schreef op vrijdag 05 oktober 2007 @ 23:31:
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.

Leg uit.

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.

Nee, dan verlies je het effect van parallellisatie. Je hebt dan een situatie waarbij 4 hardeschijven die in staat zijn te seeken allemaal ingezet worden voor één I/O operatie. Je throughput kan hierdoor wel hoger worden, maar je verliest significant aan performance zodra de I/O stroom ingewikkelder wordt, zoals bij het uitpakken van bestanden, laden van programma's en andere taken die niet sequentiëel gebeuren.

Het beste heb je een stripesize van 128KB tot 1MB zodat een enkele I/O request door één schijf behandeld kan worden, dan kan de volgende I/O request door de volgende schijf behandeld worden, enzovoorts. Dat is de theorie, in de praktijk haal je natuurlijk nooit de 100% verbetering omdat requests niet altijd op de juiste 'schijf' belanden; met andere woorden de 'load' is niet eerlijk verdeeld over de schijven. Daar doe je weinig aan, tenzij je een goede controller hebt zoals Areca die aan request reordering doet.

Als de request size in HD Tune is ingesteld op 128KB zul je dus (in theorie) de maximale snelheid halen.

Klopt maar je verliest significant aan andere vormen van I/O en ik denk dat het niet vaak voor komt dat je met 200MB/s iets moet lezen of schrijven maar veel vaker voorkomt (zeg 99,9%) dat je schijven bottleneck zijn door non-sequentiële I/O.

Een quadcore CPU presteert pas optimaal als het vier verschillende instructies kan uitvoeren. Jouw vergelijking loopt hier dus al mank.

Nee, want als je een filesystem een bestand van zeg 700MB laat lezen (of 5MB dat maakt weinig uit), zal deze iets van 10 I/O requests veroorzaken. Dat is dus de read ahead resulterende in een hogere queue depth. Om maar even een analogie te maken: zoiets als 10 threads. Door deze techniek kunnen RAID-arrays hun potentie ook daadwerkelijk omzetten in performance. Maar iets als HDTune gebruikt dit niet, en is dus een synthetische benchmark die ongeschikt is voor het meten van performance op een RAID-array zoals je dat in een realistische omgeving zou krijgen. Niet gebruiken dus.

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.

Oke heb je gelijk in. Strict genomen kan een applicatie nooit direct met hardware communiceren, dat gaat altijd via de HAL (Hardware Abstraction Layer) en dus via drivers. Wat ik bedoelde te zeggen is dat dit 'raw requests' zijn en geen API-calls van een filesystem. Te vergelijken met raw sockets ipv winsocket. Dit soort I/O wordt denk ik alleen gebruikt voor defragmenteren en andere low-level I/O. Niet erg belangrijk, het gaat er uiteindelijk om welke performance je krijgt via je filesystem.

Het lijkt me veel logischer dat eventuele optimalisaties in die driver zitten en niet in het filesysteem.

Het feit dat bijna alle filesystems dergelijke optimalisaties kennen, spreekt je tegen. Een driver weet niet met welk doel een filesystem zijn I/O uitvoert, dus om een soort prediction aan je driver toe te voegen kan teveel van het goede zijn. Toch zijn er drivers die dat doen, zoals van de Intel ICHxR RAID controller die aan low-level read-ahead doet. Kennelijk denkt Intel beter te kunnen optimaliseren dan het filesystem. Een andere mogelijkheid is dat Intel dit voornamelijk doet om synthetische benchmarks, zoals HDTune, op te krikken omdat dat is wat mensen zien en dus ook in HDTune een hoge score willen zien. Het zou niet voor het eerst zijn dat fabrikanten optimalisaties uitvoeren om beter in bekende benchmarks uit te komen (zoals nVidia met 3DMark en ATi met Quake3).

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.

Klopt, het verschil is dat het filesystem gelijk 10 requests stuurt die in één klap verwerkt kunnen worden door de controller/driver en dat synthetische benchmarks zoals HDTune 1 request sturen en daarna de volgende, etc.

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.

Hm je moet het concept van Sliding Window eens bekijken:



Probeer deze flash-demo eens:
http://www2.rad.com/networks/2004/sliding_window/demo.html

Begin met een window size van 4, reken zelf de throughput uit per 10 seconde. Gebruik hierna een window size van 1, en je ziet wat HDTune doet ongeveer.

De excessieve CPU belasting (81.4%) doet mij toch al vermoeden dat er iets niet juist is.

Het is een hardware assisted controller, dus de driver besteed werk uit aan de CPU, dus een dergelijke CPU belasting is niet zo heel vreemd. Dat betekent overigens niet dat je dit tijdens normaal gebruik hebt, want non-sequentiele I/O is duidelijk bottlenecked aan de kant van de fysieke schijven, de rest van je systeem doet dan vrijwel geen flikker, gewoon wachten tot de schijven klaar zijn. Dit is ook de reden waarom storage performance zo belangrijk is, het is al een tijdje het meest trage onderdeel in je systeem. Zelfs een quadcore met 8GB geheugen kan nog retetraag zijn en daarom is RAID voor high-end systems ook zo interessant.

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

Misschien nu wel? Maar ook al zou HDTune een juiste Sequentiele throughput rate geven, dan nog zegt dat niets over echte performance in een desktop-systeem, omdat daar bijna alle I/O niet strict sequentiëel is en vaak zelfs zwaar non-sequentiëel. Access time is een low-level statistiek die, net als kloksnelheid bij processors, niet direct te vertalen valt naar performance. Er zijn namelijk nog veel meer factoren die de uiteindelijke real-life performance bepalen. HDTune, net als ATTO en HDTach zijn alleen nuttig om de STR te bepalen, wat nog steeds niet heel veel zegt over de daadwerkelijke performance.

[Twister336]

@Enlightenment: Je maakt een grote redeneringsfout.
ATTO maakt geen gebruik van eventuele optimalisaties van het filesysteem. ATTO gaat immers (zoals andere benchmarks) de cachemanager van Windows uitschakelen voor de tests.
ATTO zal wel de optimalisaties van de hardware (in dit geval de RAID controller) gebruiken, net zoals HD Tune.

Even een plaatje om alles te verduidelijken:

RAID0 systeem met vier HD's


Stel dat het gele bestand een foto is die ingelezen wordt door Irfanview. Irfanview leest in blokjes van 32KB dus zal het eerst blokje 4 aanvragen.
De RAID controller gaat meteen ook blokjes 5,6 en 7 lezen.
Waarom? Omdat de controller weet dat de kans heel groot is dat requests voor die blokjes zullen volgen en het lezen van die blokjes geen nadelige invloed heeft omdat ze gelijktijdig gelezen kunnen worden.
Dat is het basisprincipe van de read-ahead cache die RAID controllers gebruiken.
Als HD Tune ingesteld staat met een blokgrootte van 32KB gebeurt er exact hetzelfde.
Of die requests nu van een programma of een benchmark komen maakt voor de controller helemaal niets uit.

Ik zou eerder zeggen dat HD Tune beter is om te testen, net omdat het geen gebruik maakt van het filesysteem.
Er zijn nl. een paar zeer grote nadelen bij het gebruik van het filesysteem:
fragmentatie: als het testbestand gefragmenteerd is, zijn de resultaten waardeloos
file positie: als het testbestand op het einde van een (bijna volle) schijf staat zijn de resultaten meer dan 2x trager dan wanneer het aan het begin van een (bijna lege) schijf staat.

Heel jouw stelling is gebaseerd op dat ene atypische resultaat terwijl het overgrote merendeel van de resultaten aantonen dat HD Tune wel degelijk de correcte doorvoersnelheid bij RAID systemen meet.

De enige prestatiewinst die je van een RAID(0) configuratie kunt verwachten is een hogere doorvoersnelheid dus is het ook logisch dat vooral deze parameter gemeten wordt.
Een hogere doorvoersnelheid heeft uiteraard ook voordelen voor kleinere bestanden alleen zul je daar het verschil minder snel opmerken.

[MensionXL]

Hoe zijn jullie ervaringen met verschillende merken schijven door elkaar in een raid0 opstelling? Dus bijvoorbeeld 2x een Seagate en 2x een Samsung allebei in 1 raid0 array. Brengt dit nog enige nadelen met zich mee en is het verstandiger om identieke schijven te koppelen? Of valt dit wel mee?

[RooN]

Poosje verder, wat dingetjes geprobeerd maar tis nog niet echt zoals het zijn moet volgens mij...even een shotje van mn diskconfig:



C en D zijn dus twee partities op mn RAID0 setup (2x Samsung T166, 320GB, SATA2). E is een extra PATA schijf waar wat belangrijke informatie opstaat. Deze doet er verder niet toe. Dit zijn de Atto scores en de HDTune scores:





Read-prestaties zijn volgens mij wel goed. Booten en opstarten gaat redelijk vlot allemaal. Maar de writeprestaties (zie atto scores) zijn bedroevend! Installeren van apps en progs gaat ook niet echt heel snel ofzo....ideeen waar dit aan kan liggen?

[ Voor 11% gewijzigd door RooN op 16-10-2007 17:52 ]

[Verwijderd]

@RooN: HDD Write-back buffer uitgeschakeld? Dat is veiliger voor je data maar gaat significant ten koste van je write snelheden, tenzij je NCQ gebruikt. Kun je eens een re-copy test doen met explorer zelf?

MensionXL schreef op donderdag 11 oktober 2007 @ 20:07:
Hoe zijn jullie ervaringen met verschillende merken schijven door elkaar in een raid0 opstelling? Dus bijvoorbeeld 2x een Seagate en 2x een Samsung allebei in 1 raid0 array. Brengt dit nog enige nadelen met zich mee en is het verstandiger om identieke schijven te koppelen? Of valt dit wel mee?

Valt wel mee. Ik zou alleen geen raptor en 7200rpm disk koppelen, dan ga je wel met twee heel verschillende klasse schijven werken. Het probleem is vooral verschillende firmware van de schijven, zodat ze verschillende strategiën hanteren. Femme had ook een benchmark met een nieuwe en oude raptor in RAID0 als ik me niet vergis. Was nog steeds stukken sneller dan een enkele nieuwe raptor.

[ Voor 66% gewijzigd door Verwijderd op 16-10-2007 17:57 ]

[Verwijderd]

Twister336 schreef op dinsdag 09 oktober 2007 @ 15:23:
@Enlightenment: Je maakt een grote redeneringsfout.
ATTO maakt geen gebruik van eventuele optimalisaties van het filesysteem. ATTO gaat immers (zoals andere benchmarks) de cachemanager van Windows uitschakelen voor de tests.

Dus? Dat voorkomt niet dat je filesystemen met hogere queue depths gaat werken. Het voorkomt alleen dat je synthetisch hoge scores haalt omdat de gegevens van je RAM komen ipv je schijven. Zie bijvoorbeeld de 2.2GB/s burst scores van Intel ICHxR arrays in HDTune, of de ATTO 32MB scores op een Areca array. Die zijn kunstmatig groot dat deze nooit van de fysieke schijven af kan komen. Om deze reden schakel je de filecache uit: je wilt je schijven testen, niet je RAM.

Even een plaatje om alles te verduidelijken:

Plaatje gaat uit van een slechte RAID0 config met een te lage stripesize. Je gooit door deze configuratie heel veel IOps weg, omdat je voor één I/O request meerdere schijven moet aanspreken. Dat dien je altijd te voorkomen.

De RAID controller gaat meteen ook blokjes 5,6 en 7 lezen.
Waarom? Omdat de controller weet dat de kans heel groot is dat requests voor die blokjes zullen volgen en het lezen van die blokjes geen nadelige invloed heeft omdat ze gelijktijdig gelezen kunnen worden.

Nee, je filesystem doet dat, niet je RAID controller. Uitzonderingen zijn Areca controllers en andere high-end controllers die niet vertrouwen op de intelligentie van het filesystem, maar hun eigen optimalisaties gebruiken. Kort gezegd zijn deze controllers uit het jasje van Windows' filesystem layer gegroeid en loont het om eigen optimalisaties te gebruiken.

Kijk, de beste plaats om dit soort optimalisaties door te voeren is het filesystem, die weet immers waar files precies staan (wat helemaal niet contiguous hoeft te zijn) en heeft de meeste informatie om te besluiten welke optimalisaties gewenst zijn. Zoals altijd met Windows gaat dat niet perfect en valt er nog veel te verbeteren. Vista heeft al wijzigingen doorgevoerd gekregen, zoals het vervallen van de maximal physical request size en wellicht nog veel meer.

Dat is het basisprincipe van de read-ahead cache die RAID controllers gebruiken.

De read-ahead cache van high-end controllers zoals Areca is bedoeld om in feite een hogere queue depth af te dwingen: de standaard queue depth van Windows' VFS is niet hoog genoeg om de maximale throughput van Areca bij te benen. Maar laten we ons focussen op onboard controllers; high-end controllers zijn een heel andere tak.

Ik zou eerder zeggen dat HD Tune beter is om te testen, net omdat het geen gebruik maakt van het filesysteem.

Er zijn nl. een paar zeer grote nadelen bij het gebruik van het filesysteem

Dan gebruik je Windows toch gewoon zonder filesystem?

Nee even serieus, je hebt gelijk wat betreft fragmentatie en nog wel meer dingen, maar dat is de realiteit! Dat is de performance die jij gaat krijgen als je werkt met windows. Je kunt wel benchmarks doen en een theoretische leer op nahouden, maar dan verwijder je jezelf wel ver van de werkelijkheid. Benchmarks zijn nog altijd bedoeld om te kunnen voorspellen welke performance je zou krijgen onder realistische omstandigheden. Anders dient het geen enkel praktisch nut.

De enige prestatiewinst die je van een RAID(0) configuratie kunt verwachten is een hogere doorvoersnelheid dus is het ook logisch dat vooral deze parameter gemeten wordt.

Nee, RAID0 verhoogt het aantal bewerkingen dat je per seconde kunt doen, niets meer en niets minder. Als gevolg hiervan is het mogelijk (en gemakkelijk) om een hogere doorvoersnelheid te halen, omdat de gegevens contigious (aaneensluitend) zijn kunnen alle schijven I/O opdrachten optimaal afhandelen. Parallellisatie is bij RAID het toverwoord.

Anders dan vaak wordt gedacht - verhoogt RAID0 dus evengoed de verwerkingssnelheid van kleine bestanden. Waarom denk je anders dat databases RAID gebruiken? Uiteraard voor availability maar zeker ook voor performance. Throughput is overigens helemaal niet zo belangrijk. Ik ken geen applicaties die een continu stroom van 200MB/s nodig hebben, maar toch is I/O vaak een bottleneck. Heel veel benchmarks hier op OM zijn gericht om de doorvoersnelheid (throughput) te meten, maar eigenlijk is de IOps van non-sequentiële I/O veel belangrijker.

[Verwijderd]

systeem
2 keer dualcore xeon 5060
4 keer 1gb kingston Fbdimm
moederbord Asus DSGC-DW
Intel 5000X MCH en Intel 6321ESB ICH-chipset
heb de onboard intel matrix controller gebruikt met 3 keer 320gb seagate 7200.10 firmware van de schijven 2 keer 3.AAD en 1e met 3.AAC in RAID0



avarage read: 167.4 mb/s

[RooN]

Verwijderd schreef op dinsdag 16 oktober 2007 @ 17:54:
@RooN: HDD Write-back buffer uitgeschakeld? Dat is veiliger voor je data maar gaat significant ten koste van je write snelheden, tenzij je NCQ gebruikt.

Idd, dat was m Tnx! Stom dat ik daar niet eerder aan heb gedacht. Nu zijn de write snelheden ongeveer gelijk aan de reads; ongeveer 140-150 MB/s.

[the_RJ]

WhiteRaver schreef op dinsdag 28 augustus 2007 @ 20:52:
2 x Samsung T166 320GB, ATTO 2.34, Raid 0


Dit alles met:
Gigabyte GA-P35-DS4 (raid draaiend op onboard Intel ICH9R chip met Intel drivers) (bios F6)
2 x Samsung T166 320GB (raid 0)
1 x Hitachi Deskstar 7K250 250GB (extra opslag)
1 x Maxtor Diamond 10 200GB (backup)
Windows Vista 64-bit.
Voor de rest zie tweakers gallery.
_{Sorry voor de imageshack pics}

Hallo,

ik vraag mij nu iets af, ik heb ook een GA-P35-DS4 en ook 2x Samsung T166 320GB (raid 0). Ik kreeg alleen die ICH9R chip als raid controller niet aan de praat, windows installatie ging dan steeds fout (overigens staat windows op een WD raptor, niet op deze raid). De P35-DS4 heeft echter nog een andere RAID oplossing van Gigabyte zelf, zijn alleen maar 2 sata aansluiting voor aanwezig. Deze gebruik ik dus voor mijn RAID0 en net atto erop losgegooid:



Zelfde hardeschijven op hetzelfde mobo alleen de andere controller die op het mobo aanwezig is, geeft dat zoveel verschil? (BIOS is up-to-date)

[ Voor 7% gewijzigd door the_RJ op 20-10-2007 14:40 ]

[Verwijderd]

Ja want die extra controller zit vast via PCI. En dat is niet alleen langzamer qua sequentiële snelheden maar door de toegenomen latency ook op realistische I/O zoals programma's inladen en swappen.

Beter gebruik je die ICH9R controller, dat is echt een prima controller met een boven-gemiddelde snelheid door wat truucjes die Intel uithaalt in de drivers.

[Verwijderd]

Ik heb net mijn nieuwe pc met RAID 0 van een sweex-kaartje, maar volgens mij vallen de resultaten flink tegen.

Deze is met de originele drivers die op de SWEEX-cd stonden:



Deze is met de laatste drivers van siliconimage.com:



-update - Ook nog een ATTO-benchmark:


Wat dus opvalt is dat de originele sweex-cd-drivers sneller zijn. Vreemd genoeg, als ik deze oude weer installeer keer ik niet terug naar de oude resultaten. Ik zou (denk ik) windows weer opnieuw moeten installeren.

Een vriend van me heeft dezelfde harde schijf, maar niet in RAID staan en deze behaalt dezelfde resultaten (in de HD Tune bench iig)!! Is die Silicon Image-chip echt zo brak?

Mijn systeem
Windows Vista Ultimate
Asus P5K, P35
Intel Core 2 Quad Q6600
4x 1GB Kingston DDR2 PC5300 667Mhz CL5
Samsung 500GB SATA II 7200RPM 16MB (HD501LJ) 2X RAID-0
Sweex 2 port serial ata raid (silicon image 3512)

[ Voor 5% gewijzigd door Verwijderd op 21-10-2007 00:58 ]

[Verwijderd]

HDTune is niet geschikt om RAID-arrays mee te testen, maar de resultaten van ATTO zijn niet echt spectaculair. Die vriend van je zal echter geen 100MB/s+ resultaten halen met 1 schijf.

Probeer het ook eens met software RAID en vergelijk je resultaten.

[ Voor 5% gewijzigd door Verwijderd op 21-10-2007 01:12 ]

[Verwijderd]

Ik ben er idd achter dat HD Tune niet geschikt is om RAID arrays te testen.

Las net dat het PCI kaartje wel eens de bottleneck kan zijn. In dit geval dat PCI sweex-kaartje. Zou ik moeten gaan kijken naar een PCI-e kaartje met raid?

[Verwijderd]

Oeps ik dacht dat je zei PCI-express op het einde van je post, maar als het via PCI draait heb je wel grotere problemen dan een lagere throughput. Idd naar PCI-express kijken. Moet je volume trouwens bootable zijn? Kun je niet de onboard controller gebruiken? Die zijn namelijk het snelst.

[Verwijderd]

Onboard kan ik alleen RAID gebruiken met 1 HD binnen in en 1 HD aan de buitenkant via E-sata. Daar had ik me dus in vergist bij de aanschaf van mijn P5K-bordje. En toen maar ff snel een PCI-kaartje gekocht van Sweex, maar daar word ik nu ook niet echt gelukkig van...

Ja, het moet bootable zijn; heb verder geen andere schijven waarvan ik kan booten.

Ik zal zsm een PCI-express RAID controllertje op de kop tikken. Bedankt!

[Verwijderd]

Nu een adaptec 1220SA pci-express kaartje geïnstalleerd en het gaat stukken sneller!


ter vergelijking met de sweex-pci controller:


edit: typo

[ Voor 3% gewijzigd door Verwijderd op 24-10-2007 14:36 ]

[Verwijderd]

Ziet er prima uit.

Alleen gebruik je nu 4MB transfer size (total length genoemd door ATTO), dat maakt je benchmark minder betrouwbaar. Misschien dat je met 256MB tranfer size (hiervoor heb je ATTO-256 nodig) nog betere resultaten krijgt.

[Verwijderd]

Bij deze dan!!


Ik had dat eerder niet gedaan, omdat ik het leuk vond om het verschil tussen een PCI-X en PCI kaartje te laten zien.

De results zijn nu trouwens nog beter!

Edit
Enlightenment, Queen of RAID, nog bedankt!!

[ Voor 12% gewijzigd door Verwijderd op 25-10-2007 04:18 ]

[Verwijderd]

systeem
2 keer dualcore xeon 5060
4 keer 1gb kingston Fbdimm
moederbord Asus DSGC-DW
Intel 5000X MCH en Intel 6321ESB ICH-chipset
een stukje terug in dit topic heb ik al een screenshot gepost met de intel matrix controller deze keer heb ik de Dell perc5/i gebruikt dit is een pci-e 8x LSI 8 poorts sas/sata controller met 256mb geheugen en een Intel IOP333 cpu met weer 3 de zelvde hd's 320gb seagate 7200.10 firmware van de schijven 2 keer 3.AAD en 1e met 3.AAC in RAID0

hdtach 3x320gb perc5i raid0 strip size 32kb cluster 64kb NO read ahead

avarage read :192 mb/s

atto 3x320gb perc5i raid0 strip size 32kb cluster 64kb NO read ahead.JPG


ik heb verschillende strip size getest en vreemd genoeg lijkt 32kb het snelste te zijn ( +- 190mb/s) een stipsize van 128kb gaf bij hdtach zelfs een grafiek van rond de 40mb/s beide geformateerd met een cluster grote van 64kb heeft iemand eenig idee hoe het kan dat een grotere strip size juist trager is op deze controller ( ook met grote files ) hier beneden atto 128kb stripsize ( screenshot van hdtach heb ik helaas niet meer )

atto 3x320gb perc5i raid0 strip size 128kb cluster 64kb NO read ahead.JPG


edit:
was vergeten te zeggen dat read ahead aan of uit in de banchmark progjes nauwelijks verschil maakte

[ Voor 4% gewijzigd door Verwijderd op 04-11-2007 21:43 ]

[Quorton]

specs
Intel Q6600 @ 3,33 G
Asus P5K-e wifi (ICH9R)
4x 1G Team group @ 1120 5-5-5-15
4x 500G Samsung T-166
Vista 64 business

Ik heb 2 raid configuraties
raid 0


en raid 5


raid0

raid5


Raid 0 ziet er wel goed uit, maar bij raid 5 is de write snelheid toch wel laag (in ATTO).
Een collega van me heeft nl exact dezelfde setup/OS en haalt daar write snelheden rond de 200.000

Wat kan er anders zijn dat het bij mij zoveel trager is ?
Ik heb write enabled cache in de raid control manager aangezet, de write cache van de disken in de device manager kan ik niet aanzetten, die vinkjes worden iedere keer weer uitgezet (schijnt niet te kunnen met raid?) en ik heb diverse services disabled.

[Verwijderd]

ICH9R write snelheden rond de 200MB/s? Wellicht burst maar niet sustained. Je moet weten dat je bij ICH9R niet alleen je hardeschijven test maar ook je geheugen (mits write-back is ingeschakeld). Het is dan erg makkelijk om onrealistische resultaten te krijgen. ICH9R is niet makkelijk te benchmarken.

65MB/s write lijkt mij wel oke. Wellicht dat een benchmark met cooldown periode na elke write benchmark nog een beter resultaat oplevert. Ik ben overigens wel benieuwd welke scores geom_raid5 haalt onder FreeBSD met jouw hardware. Maar je hebt er zeker al data op staan enzo?

[Verwijderd]

Specs

AMD Sempron 64 3000+
MSI R482 IL
3x Samsung T166 250 GB 8 MB SATA
1x Samsung T133 400 GB 16 MB SATA
Highpoint RocketRAID 2310 PCIe 4x

Ik heb een RAID 10 configuratie van 499 GB en de resterende 149 GB heb ik als JBOD geconfigureerd.

RAID 10:


Ik ben tevreden over de resultaten

[BlueKeenan]

Het is niet helemaal eerlijk omdat dit een server bak is maargoed.

Specs :

Intel Core 2 Quad Q6600 2,4 Ghz
4 Gb DDR-2
Foxconn G33M-S bordje,
Areca 1220 raid controler.

Onboard RAID controler (RAID 1, 2x 160 GB)

ATTO


HDTach



Areca RAID controler (RAID 5, 8x 500 GB)

ATTO


HDtach



En owja, de areca raid was toen ik de bench uitvoerde aan het rebuilden.

Je hoort mij niet klagen.

[sig69]

Sinds gisteren heb ik 4 Western Digital Caviar RE WD1600YS in raid 0:
weg
Niet verkeerd dacht ik zo.

[ Voor 44% gewijzigd door een moderator op 18-12-2008 19:21 ]

[Verwijderd]

Geen slechte scores maar aan het grote verschil tussen de 128 t/m 8192KB scores te zien lijkt de RAID-driver niet erg efficient. Welke controller gebruik je?

[ Voor 5% gewijzigd door Verwijderd op 26-11-2007 21:13 ]

[sig69]

Het hangt aan Intel een ICH9R chipset op een Gigabyte P35. Zo groot is het verschil tiisen 128 en 8192KB toch niet?

[Verwijderd]

199MB/s versus 259MB/s vind ik een groot verschil. Dat zou eigenlijk niet mogen. Maargoed ATTO is niet de beste tool om RAID implementaties mee te testen.

Een perfecte RAID driver/implementatie heb ik nog nooit gezien. Maar zelfs bij onboard RAID zou de sequentiele overdracht de max theoretische snelheid dicht moeten benaderen, zeker bij simpele levels als RAID0 en RAID1.

Zou je de 'write-back' optie tijdelijk eens aan kunnen zetten en dan opnieuw testen? Mogelijk komt de hogere score echter door caching en is het dus geen geldige score. Om goed te testen moet je meer dan 8 keer je RAM geheugen schrijven wil je een betrouwbare score hebben. Intel ICH9R gebruikt namelijk je geheugen als buffercache, voor extra snelheid.

[sig69]

Met de write-back optie uit komt dit er uit:

Edit: ik sliep al half, verkeerde schijf gebenched...

Edit2: dit zijn de resultaten met write-back uit dus:
weg

[ Voor 108% gewijzigd door TERW_DAN op 18-12-2008 19:21 ]

[Verwijderd]

CPU: AMD X2 3800
Moederbord: ASUS M2NPV-MX
Geheugen: Twinmos 1GB cas 5 DDR2-6400
Softwarematige RAID0 over 5 schijven met LVM:
2x Seagate 120GB IDE (lezen: 55 MB/s ,hdparm -t)
2x Seagate 120GB SATA-I (lezen: 55 MB/s ,hdparm -t)
1x Samsung T166 320 GB SATA-II (lezen: 87 MB/s ,hdparm -t)
Chunksize: 256K
Readahead: 8192 (LVM). 5120 (RAID)
Bestandsysteem: ext3 (noatime)
Besturingsysteem: Linux 2.6.22 32-bit

Benchmarkprogramma: Bonnie++ 1.03 (dit is de single-cpu versie, dus alleen één core wordt gebruikt).

Leessnelheid: 233 MB/s
Schrijfsnelheid: 237MB/s

sudo /usr/sbin/bonnie++ -n 1024 -r 1024 -s 4096 -x 1 -u root -q | bon_csv2txt

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
thuis 4G 43813 98 237188 91 100201 37 46860 97 232695 43 346.1 2
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
thuis 1024 23681 68 22717 23 2427 12 24000 69 22648 27 1422 8

Benchmarkprogramma: hdparm -t

Leessnelheid gemiddeld: 240MB/s

Benchmarkprogramma: dd

sudo sync;time sudo bash -c "(dd if=/dev/zero of=bf bs=8k count=500000; sync)"
500000+0 records in
500000+0 records uit
4096000000 bytes (4,1 GB) gekopieerd, 17,3145 seconden, 237 MB/s

real 0m18.180s
user 0m0.124s
sys 0m14.033s

Schrijven: 237 MB/s

[ Voor 11% gewijzigd door Verwijderd op 01-12-2007 11:20 ]

[dvl-2]

Ik heb altijd met HD-tach gebenchmarked en die geeft op mijn raid6 array (9-disk) netjes een avarage read van 420MB/s.

Nu heb ik ook een keer ATTO gerunt omdat dat hier veelgebruikt is en ik het al lang niet meer gebruikt had, de schrijfsnelheden die daarmee gehaald worden zijn rond de 700MB/s maar volgens ATTO haalt de array maar rond de 40MB/s read.

Nu de vraag; kan ATTO wel met raid6 omgaan? De 40MB/s die uit de benchmark komen kloppen, heel duidelijk, niet. Gewoon met bestanden verplaatsen vanaf die array naar een raid0 gaat met 200MB/s gem. wat de max is van die raid0-array.

Misschien wel handig erbij te zeggen dat ik lang geleden toen de array nog 4-disk raid5 was de read/write wel met elkaar overeen kwamen. Naderhand zijn stripe/blocksize niet meer aangepast en er enkel disks bij gekomen en een keer raid-level 'verhoogd' naar raid6.

Meer mensen die dit probleem hebben? Controller in kwestie is een areca 1280 met 2GB cache.

[Verwijderd]

Een betere vraag zou zijn, kan een superoud programma als ATTO (de 32MB versie denk ik dat je hebt) wel met RAID omgaan. Het antwoord is nee, iig niet in betrouwbare zin.

Probleem is dat je een intelligente controller hebt, waarschijnlijk met write-back ingeschakeld. Het feit dat je RAID6 gebruikt maar niets uit, hetzelfde probleem zul je hebben met RAID0 en zelfs een JBOD.

Als je jouw controller wilt benchmarken met testgroottes van minimaal 8 * RAM moeten werken. Stel jouw systeem heeft 4GB en je Areca 2GB, dan is de minimale testgrootte dus 48GB voor een betrouwbaar resultaat. Wat je nu gebruikt is 32MB, en dat floept zo de write-buffer in. In feite test je dan de geheugen en verwerkingssnelheid van je Areca kaart, niet van je hardeschijven. Met dezelfde technologie kun je een ouderwetse floppydrive een write speed van 700MB/s geven.

Je Areca is ongetwijfeld snel, maar je kunt geen simpele programma's zoals ATTO, HDTune, HDTach gebruiken om dit te testen. Deze programma's zijn allemaal niet geschikt voor RAID arrays, en vooral niet voor Areca's met 2GB aan dedicated buffercache.

[dvl-2]

Gebruikte wel de 256MB versie van ATTO. Heb inderdaad 4GB ram en zou dus minimaal 48GB als testgrootte moeten hanteren. De verklaring waarom ATTO zulke write-speeds haalt is na jou uitleg inderdaad logisch.

Toch blijf ik het 'vreemd' vinden want een 3-raptor raid0 op precies diezelfde controller laat wel gelijke write/read speeds zien (ook idd van 700MB/s, beide dat had al een lampje moeten gaan laten branden). Ook verklaard het de ATTO-resultaten in de benchmark-database van 900MB/s aangezien die test niks met de HDD's te maken heeft maar alleen met de cache.

Een programma zoals HDTach laat wel duidelijk verschil zien tussen de array's en geeft ook realistischere resultaten en ik zal die dan maar 'standaard' gebruiken en de resultaten met een korreltje zout nemen (al lijken mij die resultaten wel te kloppen).

Leuk is dan wel te weten dat deze areca (met een IOP341) een 'plafond' heeft op ongeveer 750MB/s waar oudere modellen (1220/1230) met een IOP333 op 500MB/s een max hadden.

[Verwijderd]

dvl-2 schreef op dinsdag 04 december 2007 @ 14:59:
Toch blijf ik het 'vreemd' vinden want een 3-raptor raid0 op precies diezelfde controller laat wel gelijke write/read speeds zien

Hoezo vreemd? Volgens mijn verhaaltje klopt dat dus inderdaad; je zou zelfs hetzelfde resultaat moeten krijgen met een oude schijf in een RAID0-array bestaande uit 1 disk. Het gaat hier in feite niet om de disks maar om je Areca controller, die met truucjes ATTO en andere software te slim af is.

Een programma zoals HDTach laat wel duidelijk verschil zien tussen de array's en geeft ook realistischere resultaten en ik zal die dan maar 'standaard' gebruiken en de resultaten met een korreltje zout nemen (al lijken mij die resultaten wel te kloppen).

Ja kan, als er gewoon sequentiëel gelezen wordt over de hele disk dan wordt de invloed van caching beperkt. Bovendien heb je dan geen last van een write-back buffer - dat is alleen van toepassing als je schrijfopdrachten hebt. Bij writes kan areca direct na het ontvangen zeggen 'deze is weggeschreven!' en dan gaat het filesystem door met de volgende opdracht. Maar met lezen gaat dit grapje niet op; Areca zal de schijven moeten gebruiken tenzij (een deel van) de data in Areca's onboard dedicated buffercache zit. Draai maar eens een aantal HDTune's achter elkaar - dan zie je dat sommige seeks (access time puntjes) helemaal onderaan zitten - die zijn cached en komen niet van de fysieke hardeschijven.

Leuk is dan wel te weten dat deze areca (met een IOP341) een 'plafond' heeft op ongeveer 750MB/s waar oudere modellen (1220/1230) met een IOP333 op 500MB/s een max hadden.

Klopt! Ik heb dus zo'n ARC-1220 met IOP333 en haal daarbij 880MB/s read en 430MB/s write max burst speed. Hoger zul je dus nooit kunnen met deze controller. Ik moet er wel bij zeggen dat je zelden meer dan 200MB/s aan doorvoersnelheid nodig hebt - hardeschijven zijn bottleneck omdat ze maar heel langzaam een random I/O stroom kunnen verwerken. En realistisch gebruik (servers/desktop) lijkt vaak sterk op random I/O. Dan kan de verwerkingssnelheid - zelfs op een Areca - terugvallen tot 2MB/s of nog lager. Sequentiële I/O is een best-case scenario, oftewel de maximum performance. Het is opzich jammer dat deze zoveel aandacht krijgt; sequentiële I/O is namelijk niet verantwoordelijk voor de traagheid van storage.

[dvl-2]

Verwijderd schreef op dinsdag 04 december 2007 @ 18:08:

Hoezo vreemd? Volgens mijn verhaaltje klopt dat dus inderdaad; je zou zelfs hetzelfde resultaat moeten krijgen met een oude schijf in een RAID0-array bestaande uit 1 disk. Het gaat hier in feite niet om de disks maar om je Areca controller, die met truucjes ATTO en andere software te slim af is.

Je begrijpt me verkeerd:

raid0 array in ATTO resulteerd in 750MB/s read en 750MB/s write
raid6 array in ATTO resutleerd in 40MB/s read en 750MB/s write

Die 40MB/s valt dus uit te toon mbt de andere resultaten en is ook met jou verhaal door mij niet te verklaren

Verwijderd schreef op dinsdag 04 december 2007 @ 18:08:

Klopt! Ik heb dus zo'n ARC-1220 met IOP333 en haal daarbij 880MB/s read en 430MB/s write max burst speed. Hoger zul je dus nooit kunnen met deze controller. Ik moet er wel bij zeggen dat je zelden meer dan 200MB/s aan doorvoersnelheid nodig hebt - hardeschijven zijn bottleneck omdat ze maar heel langzaam een random I/O stroom kunnen verwerken. En realistisch gebruik (servers/desktop) lijkt vaak sterk op random I/O. Dan kan de verwerkingssnelheid - zelfs op een Areca - terugvallen tot 2MB/s of nog lager. Sequentiële I/O is een best-case scenario, oftewel de maximum performance. Het is opzich jammer dat deze zoveel aandacht krijgt; sequentiële I/O is namelijk niet verantwoordelijk voor de traagheid van storage.

Klopt inderdaad, die MB/s uit die reviews is niet meer dan beetje een 'patsfactor', je gebruikt toch nooit meer dan 200MB/s dus alles erboven is grappig maar gebruik je toch niet. Zoals je zegt is de I/O-performance een stuk belangrijker.

[Madrox]

Verwijderd schreef op dinsdag 04 december 2007 @ 18:08:
[...]
hardeschijven zijn bottleneck omdat ze maar heel langzaam een random I/O stroom kunnen verwerken. En realistisch gebruik (servers/desktop) lijkt vaak sterk op random I/O. Dan kan de verwerkingssnelheid - zelfs op een Areca - terugvallen tot 2MB/s of nog lager. Sequentiële I/O is een best-case scenario, oftewel de maximum performance. Het is opzich jammer dat deze zoveel aandacht krijgt; sequentiële I/O is namelijk niet verantwoordelijk voor de traagheid van storage.

De hamvraag is dus; wat is het beste wat je kan doen om de random I/O op te voeren ?

ps: Zie scores van 100MB +, met 1 harddisk. Zijn mijn twee WD 4000YS RE dan zo langzaam of lijkt dat maar zo ?
Vanaf 64kb scoren ze 93/94.000 read en write (Atto (256??)). Softwareraid XP, RAID-0, hangen aan Asus A8n SLI Premium aan de nVidia NF4 Serial ATA II poorten.

Ter vergelijk de enkele WD 3200jb 320GB scoort dan een 64-65.000.

Het is wel zo dat mijn Wd3200jb in twee partities gehakt is; c:\ 32GB D:\288.
De Raid-0 array is 1 grote van de twee WD 4000YS RE's.

update!

Als ik de test speed knop indruk bij primairy en secundairy channel (apparaatbeheer/nvidia sata controller), krijg ik verschillende sustained speed waardes, dat kan toch eigenlijk niet als ik twee identieke harddisk heb ? Het gat is nogal groot, disk 1 scoort 72.1. disk 2 maar 57.7

[ Voor 35% gewijzigd door Madrox op 06-12-2007 17:32 ]

[-MD-]

Asus P5N-E SLI
2x Samsung Spinpoint 500GB (7200rpm Sata2 16mb)
RAID 0

Met de volgende resultaten:



Ik heb er geen verstand van dus ik durf ook niet te vertellen of het goed is in verhouding met mijn specs. Ik ben wel blij want mijn systeem is een stuk sneller dan mijn vorige, maar als het beter kan dan hoor ik het natuurlijk graag.

Overigens heb ik mijn besturingssysteem op 2x WD Raptor 74GB (SATA 10K rpm 16mb) in RAID 0. Resultaten hiervan volgen nog, ik krijg deze vooralsnog niet getest (foutmelding: 'Cannot open file benchtst.$$$.')


Zie ook: Raid Setup: Installatie vraag.

[Verwijderd]

Een slechte write op ICH xR RAID 5 kan ik me goed voorstellen.

Heb zelf de ervaring dat op mijn 3 schijven Seagate 7200.10 250 GB (AAD, AAE, AAE) de write ook niet boven de 4 MB/s komt.

Ik kopierde eens een ISO van zo'n 4 GB vanaf m'n laptop via GBit LAN naar m'n desktop, naar een RAID 5 partitie.

2 uur en 20 minuten resterend zegt ie na een twee minuten transferen. Ja, zijn we nu helemaal van de ratten beschimmeld zeg

Uiteraard geannuleerd en toen naar een RAID 0 partitie gekopierd vanaf m'n laptop. Resulteerde in een nette 30 MB/s (het maximale van m'n laptop HDD).

Op LAN parties ook. GBit LAN, RAID <> RAID, en traaag, traaag, traaag.

Ik denk dat het de volgende keer voor mij RAID 10 wordt, dan maar een 50% verlies ipv 25% (bij vier schijven), maar ik ben die langzame write meer dan zat. Een losse RAID controller is nog net iets té prijzig imo.

Beetje RAID 5 controller op PCI-Express (x4 of x8, x1 win ik niks mee kwa transferrate, dan krijg je bus bottleneck op 250 MB/s theoretisch max.)

4 poorts, RAID 5, PCI-Express, eigen XOR Unit, zit je al aan de 280 euro

En om dan nog maar te zwijgen over de 8 poorts. Die goedkopere RAID kaartjes hebben ook nog eens een nep interface, PCI-X en dan chipje ertussen om er PCI-e van te maken, nee bedankt.

[dvl-2]

Je kan nou eenmaal ook niet voor een dubbeltje op de eerste rang zitten he

[TheBorg]

160-180MB/s sustained is wel de max met de ICH9R. Dit met 4 drives (met 5 loopt alles in de soep), 64kb stripe size, write back enabled. In ATTO benchen met direct I/O, neither. Als ik tijd heb zal ik zaterdag een bench posten.

[ Voor 12% gewijzigd door TheBorg op 12-12-2007 21:41 ]

[Verwijderd]

dvl-2 schreef op woensdag 12 december 2007 @ 16:49:
Je kan nou eenmaal ook niet voor een dubbeltje op de eerste rang zitten he

Wat is er nou zo bijzonder aan RAID 5? Moet toch veel sneller kunnen. CPU gebruik is ook maar 2% ofzo

[Verwijderd]

Verwijderd schreef op woensdag 12 december 2007 @ 22:20:
[...]


Wat is er nou zo bijzonder aan RAID 5? Moet toch veel sneller kunnen. CPU gebruik is ook maar 2% ofzo

RAID5 is een complex RAID level.

De meeste implementaties, zoals van onboard chipjes die RAID5 kunnen, zijn erg simplistisch gebouwd. Normaal zou je denken, als je CPU belasting maar 2% is, waar ligt dan de bottleneck? Het antwoord: door een slecht design, is de bottleneck je hardeschijven. Een simpele RAID5 implementatie doet namelijk alle writes in twee fases, zogenaamde 2-phase writes. Hierbij wordt er eerst data ingelezen, daarna de pariteit uitgerekend, en daarna alle relevante data naar disk geschreven inclusief verse parity. Nadeel van deze trage 2-phase writes is dat schijven bij het schrijven continu aan het lezen zijn, en dus hele tijd aan het seeken zijn, van sequentiëel schrijven is dan eigenlijk geen sprake meer.

Moderne implementaties daarintegen, maken gebruik van request combining. Oftewel het samenvoegen van requests. Dit is nodig om zogenaamde 1-phase writes mogelijk te maken, waarbij er niet meer gelezen hoeft te worden van de schijven maar er alleen geschreven wordt. Om dit mogelijk te maken moet de implementatie een write-buffer hebben die alle write requests opslaat, aan elkaar lijmt en zoekt naar 'full stripe blocks'.

Formule: (aantal_schijven - 1) * stripesize = full stripe blocksize.
Voorbeeld: (4 - 1) * 128KB = 384KB

Om het simpel te houden: RAID5 kan alleen snel schrijven als het precies met blokjes van die 384KB schrijft (uiteraard is dit getal anders bij een andere stripesize of hoeveelheid schijven). geom_raid5, een softwarematige RAID5 implementatie onder FreeNAS/FreeBSD, haalt zo'n 470MB/s aan raw write dankzij write-combining. Zonder write-combining is dat zo'n 20MB/s. Dat is dus de reden dat RAID5 speciaal is.

RAID3 heeft hiervan geen last, omdat "by design" alle writes automatisch 1-phase writes worden. RAID4, RAID5 en RAID6 hebben wel last van dit probleem. Interessant detail: Sun's ZFS filesystem lost dit probleem op door een variabele stripesize te gebruiken voor elke file. Zodoende kan altijd de full stripe block gebruikt worden voor optimale performance. Althans, dat is de theorie.

[Verwijderd]

dvl-2 schreef op woensdag 05 december 2007 @ 09:19:
Je begrijpt me verkeerd:

raid0 array in ATTO resulteerd in 750MB/s read en 750MB/s write
raid6 array in ATTO resutleerd in 40MB/s read en 750MB/s write

Die 40MB/s valt dus uit te toon mbt de andere resultaten en is ook met jou verhaal door mij niet te verklaren

40MB/s read? Dan zit er iets fout met je array. Misschien draait je array single of double degraded? Misschien test je onjuist? ATTO 256MB is opzich wel een goede benchmark om de doorvoersnelheid mee te meten, maar er blijft één probleem bestaan: door gebrek aan een rustperiode tussen de tests is het mogelijk dat de ene benchmark de andere beïnvloed. Dit komt omdat moderne controllers waaronder Intel ICHxR met write-back een buffer hebben, die dus nog geleegd moet worden zodra de volgende benchmark nog moet beginnen.

Wat krijg je dan: 256MB schrijven gaat heel snel, maar daarna komt de read-benchmark. Tijdens dat deze benchmark nog bezig is, is die 256MB nog niet daadwerkelijk weggeschreven naar de disk. Gevolg is dat je read-benchmark lagere scores krijgt. Een mooi woord hiervoor is benchmark contamination. Voor Windows heb ik geen gemakkelijke workaround, behalve met explorer zelf wat copy-tests uit te voeren van/naar een memory disk. Probeer anders eens tests die alleen lezen, dan zou je dit probleem niet mogen hebben.

Madrox schreef op donderdag 06 december 2007 @ 02:21:
De hamvraag is dus; wat is het beste wat je kan doen om de random I/O op te voeren ?

Door geen mechanische hardeschijven te gebruiken. De lage IOps score hiervan is inherent aan de techniek. Alhoewel schijven sneller worden blijft het probleem bestaan. Pas zodra de volgende generatie SSDs zijn intrede doet kunnen we échte performance verwachten, iets wat al snel 80.000% sneller kan zijn dan met hedendaagse mechanische techniek mogelijk is.

ps: Zie scores van 100MB +, met 1 harddisk. Zijn mijn twee WD 4000YS RE dan zo langzaam of lijkt dat maar zo ?
Vanaf 64kb scoren ze 93/94.000 read en write (Atto (256??)). Softwareraid XP

Post eens wat concrete benchmarks? Bij RAID0 moet je gewoon de max sustained speed halen, punt. Zo niet dan zit er wat fout. Ik ga er wel vanuit dat je geen PCI gebruikt, want dat beïnvloed je performance aanzienlijk.

[Madrox]

Het probleem is al boven water, 1 van de twee heeft maar een "drivefitness" (smart/speedfan) van 85%. Ook WD's quick en full diagnose klappen eruit met fouten. De WD-tool smartstatus rapporteert wel: passed. Vreemd. Iig vertrouw ik die ene disk niet meer en heb al RMA aangevraagt.
De eerste keer trouwens dat ik erachter kom voordat een harddisk de geest geeft, wel kicken

[Verwijderd]

Dit is mijn nieuwe RAID(0) setup

4x Samsung SpinPoint F1 1TB 32MB (op areca 1210)



ps: ben nog niet helemaal uit hoe ik die +2TB in vista 64 voorelkaar krijg

[Verwijderd]

Kwijl

Wel koel dat je met 4 schijven al de 400MB/s kunt halen, dankzij de nieuwe Samsung F1 serie. Alhoewel dat je ook wel met Software RAID0 was gelukt.

Waar ga je de hardware voor gebruiken?

[ Voor 11% gewijzigd door Verwijderd op 17-12-2007 19:05 ]

[webfreakz.nl]

Verwijderd schreef op maandag 17 december 2007 @ 18:46:
Dit is mijn nieuwe RAID(0) setup

4x Samsung SpinPoint F1 1TB 32MB (op areca 1210)

[afbeelding]

ps: ben nog niet helemaal uit hoe ik die +2TB in vista 64 voorelkaar krijg

4TB op een RAID 0 is behóórlijk WTF

http://www.microsoft.com/whdc/device/storage/LUN_SP1.mspx

Note: Disk devices with more than 2 TB of disk space must be converted to GPT format for all of the disk space to be usable. If the device uses MBR format, the disk space beyond 2 TB will be unusable.

http://www.tomshardware.c...14-problems-larger-arrays

You can use an aray with more then 2TB as a data disk, but you need to use GPT arrays, and you CAN NOT BOOT FROM THEM

[Verwijderd]

Hier de resultaten van mijn eerste test met een Gigabyte P35-DS3R / C2D 6750 met 2 x Raptor 150 GB in RAID 0 op de onboard ICH9 controller (write back cache uitgeschakeld):





Ik vraag me alleen af waar die slechte 128 KB read score in ATTO vandaan komt

[ Voor 16% gewijzigd door Verwijderd op 18-12-2007 19:23 ]

[Verwijderd]

Je test op je C-schijf, je resultaten worden dus negatief beïnvloed door achtergrond I/O. Draai de benchmark nog eens, is die lage score dan weg of iig anders? Zo ja dan denk ik dat je je nergens zorgen om hoeft te maken, leuke scores!

[l3p]

oi


Asus maximus formula (ICH9R)
Intel q6600 @ 3.2
4 Gb Corsair pc8500 kit
3 x 150 Gb raptor - raid0 - C partitie / Vista / Games / Downloads ( worden hierna auto uitgepakt naar D
2 x 750 Gb seagate raid0 - D Partitie / Opslag
Overige specs

Ik heb dus alles in raid 0 , dit omdat verlies van data totaal niet erg is ( binnen een uur staat vista er weer op)

---

Hier mijn resultaten met de raptors:











Welke ik vreemd vind

---

Hier mijn resultaten met de Seagates:






Nu heb ik dus enkele vragen als dat mag
Ik ben gamer in hart en nieren en mag graag een filmpje kijken
Ik draai dus al zon 5 jaar op verschillende raid0 setups
nu wilde ik deze week toch eens iets verder dan 2 x raptor in raid 0.


Eerst wilde ik een areca 1220 aanschaffen, later een 8 poorts 3ware 9650, en dat is weer een 3e raptor geworden omdat het schijnt dat beide raidkaarten nog niet erg lekker met de x38 chipset overweg kunnen.

Nu zijn dus mijn vragen :

1. Zijn deze scores een beetje normaal ?
2. Kan dit sneller door alleen al een van de ondergenoemde raidcontrollers aan te schaffen ?
3. Iemand ervaring met het zogenaamde X38 chipset probleem ism raidcontrollers ?
4. Als ik dan volgende maand toch een raidkaart wil aanschaffen, wat is dan beter in mijn geval , een 8 poorts areca 1220 of een 8 poorts 3ware 9650 (nieuwere intel chip?)


Bedankt alvast

[l3p]

Queen of raid, any idea ?

[dvl-2]

Voor zover ik kan oordelen lijken me deze scoren vrij normaal maar met een echte hardware-raidcontroller zal dit nog zeker (iets) beter/sneller kunnen.

Heb zelf geen ervaring met 3ware-controllers maar wel met de 12xx-areca controllers. Deze werken ook allemaal prima op een X38-bord. Gewoon met dezelfde drivers als welk andere chipset dan ook.

Welke keuze beter is; areca-1220 of 3ware-9650 kan ik helaas geen antwoord op geven. Zelf heb ik van (oudere) 3ware kaarten gehoord dat in diezelfde prijsklasse de areca kaarten beter presteerden. Nu met de nieuwe 3ware kaarten vs. de 1j oude areca kaarten durf ik dit niet te zeggen, denk dat je het beste kunt googlen op benchmarck en reviews van die 9650.

[Verwijderd]

@l3p: je scores zijn prima. Denk aan de write-back mogelijkheid van de ICH9R controller, geeft leuke snelheidswinsten bij normaal gebruik.

Een Areca zou nog sneller zijn, maar heb je die snelheid ook echt nodig? ICH9R doet het aardig, zeker met write-back. Test dat eerst eens in de praktijk (en niet benchmarks want de meeste zijn niet geschikt voor jouw controller). Waar ben je concreet nog niet tevreden over? Of ben je verslaafd aan meer performance?

[StarLite]

Specs
Tyan Thunder i7500
2 * Xeon 1.8GHz
2GB ECC RAM
8 * WD 320GB [WDC WD3200JS-00PDB0] @ RAID 5
Areca ARC-1120

Firmware: V1.43 2007-4-17
Write-strategy: Write Back
BBU: Ja
Raid Level Raid 5
Stripe Size 32KBytes
Block Size 512Bytes
Cache Mode Write Back




Ik heb wel eens meer gehaald met atto en iometer [tegen de 600Mb/sec reads], maar op de een of andere manier komt ie nu niet meer boven de 270MB/sec.
Als ik zo naar de scores van Denzeltje kijk zou ik toch meer moeten kunnen halen...

[ Voor 13% gewijzigd door StarLite op 21-12-2007 10:43 ]

[Verwijderd]

En als je het met 128KB stripe probeert? Of staat er al data op de schijf?

Je zou idd hoger moeten halen met 8 schijven in RAID5. Puntje blijft wel dat ATTO geen rustperiode inlast, door de write-back zijn de reads lager omdat eerst de onboard buffer moet worden geleegd. Maar ook qua write zou je hoger moeten kunnen.

Als de stripesize geen verschil maakt, kun je eens kijken of NTFS instellingen (clustersize) effect hebben.

[StarLite]

De array staat al helemaal vol en ik heb geen 2TB backup ruimte beschikbaar om even mijn blocksize te veranderen.

[Verwijderd]

Dan kun je ook niet echt netjes benchmarken, je langzamere snelheid kan namelijk prima komen omdat je op de buitenste tracks zit. Dus reken 35MB/s per schijf max doorvoer ipv 75MB/s. Zou je op een schoon filesystem testen dan zou je hoger moeten komen.

Maar.. heb je ook meer dan 200MB/s nodig? Dat gebruik je namelijk maar zelden. Het draait vaak echt om de IOps.

[Verwijderd]

2x 500 samsung spinpoint ( sata2,7200rpm)
gigabyte x38 dq6
q6600
8 gig geil
vista ultimate 64bit

[ Voor 5% gewijzigd door Verwijderd op 23-12-2007 14:13 ]

[MensionXL]

Verwijderd schreef op zondag 23 december 2007 @ 14:12:
2x 500 samsung spinpoint ( sata2,7200rpm)
gigabyte x38 dq6
q6600
8 gig geil
vista ultimate 64bit

[afbeelding]

Write-back cache niet enabled?

[Verwijderd]

Hij kan beter ATTO-256 eerst proberen, of handmatig testen met die Intel ICHxR controller. Write-back brengt wel risico's met zich mee. Is de data vervangbaar, dan geeft write-back een leuke merkbare snelheidsverbetering: alle writes worden dan eerst naar je RAM geschreven en worden dan als 'voltooid' gemarkeerd. Intel schrijft ze dan weg naar de fysieke disks zodra die mogelijkheid bestaat. Als de stroom uitvalt kun je echter wel veel/alle bestanden op je NTFS-schijf kwijt zijn door MFT-corruptie. Gebruik het dus nooit voor data die je niet wilt verliezen.

[Verwijderd]

stond uit , met :




Zal direct even atto 256 proberen

[ Voor 32% gewijzigd door Verwijderd op 23-12-2007 18:01 ]

[Verwijderd]

[-MD-]

Verwijderd schreef op zondag 23 december 2007 @ 18:10:
[afbeelding]

Dat moet dan toch sneller kunnen?
Zelfde schijven met P5N-E SLI:
MistaDevine in "[Benchmarks] Het grote: "Post hier je RA..."

[Verwijderd]

Welke stripesize heb je gebruikt, linuxserver?

Je zou zo rond de 140MB/s moeten zitten (2x70MB/s)
Met de juiste stripesize (128KB) zou je dat moeten halen, mits juist getest.

[Verwijderd]

stripsize is idd 128 kb, vreemd dat ik niet meer haal dan .

[Verwijderd]

Staat er misschien al aardig wat data op je C-schijf? Zo ja dan is het logisch dat je niet de max haalt omdat de data dan niet aan het begin van de schijven komt. Halverwege de capaciteit zakt de snelheid dan in met 20% en aan het einde 45%.

[Verwijderd]

Nee, 882gb is vrij .


Nog een nieuwe poging .

[Verwijderd]

HDTune is niet erg geschikt voor RAID, zie hier: Why HDTune is unsuitable for RAID arrays.
Om die reden komt het vaak voor dat HDTune een veel lager resultaat geeft, dan wanneer je test via je je filesystem, zoals ATTO doet.

Dan nog kan het zijn dat de benchmark-resultaten ongeldig zijn, omdat ook ATTO geen rustperiode inlast tussen de opeenvolgende tests. Als je de daadwerkelijke throughput via NTFS wilt weten kun je testen met een memory disk van 1GB ofzo, waarop ook een 1GB bestand staat die je kopieert naar je RAID-array filesystem. Meet de tijd met een stopwatch en reken de snelheid uit.

[Verwijderd]

Dus de atto test die ik eerder poste kan ik beter als referentie punt nemen .

[Marc H]

Even een benchmark van mijn nieuwe systeempje:

Gigabyte P35c DS3R
Intel C2Q 6600
4 GB ram
Highpoint Rocketraid 2300
4x Samsung 500 T166 in raid 5