Gathering of Tweakers

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

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.

Nyarlathotep wijzigde dit bericht 06-10-2007 16:23 (6%)

Hier even een HDtach van de nieuwe Seagate 7200.11



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

wouter10 wijzigde dit bericht 06-10-2007 17:42 (3%)

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

quote:

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

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

quote:

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

Ik wacht met spanning

quote:

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.

quote:

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.

quote:

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.

quote:

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.

quote:

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.

quote:

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

quote:

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.

quote:

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.

quote:

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.

quote:

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.

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

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?

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?

RooN wijzigde dit bericht 16-10-2007 17:52 (11%)

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

quote:

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.

Enlightenment wijzigde dit bericht 16-10-2007 17:57 (66%)

quote:

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.

quote:

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.

quote:

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.

quote:

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.

quote:

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

quote:

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.

quote:

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.

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

quote:

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

quote:

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)

the_RJ wijzigde dit bericht 20-10-2007 14:40 (7%)

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.

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)

Sir_Mj wijzigde dit bericht 21-10-2007 00:58 (5%)

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.

Enlightenment wijzigde dit bericht 21-10-2007 01:12 (5%)

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?

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.

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!

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


ter vergelijking met de sweex-pci controller:


edit: typo

Sir_Mj wijzigde dit bericht 24-10-2007 14:36 (3%)

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.

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

Sir_Mj wijzigde dit bericht 25-10-2007 04:18 (12%)

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

WOK Paul wijzigde dit bericht 04-11-2007 21:43 (4%)