All rights reserved Sat, 30 Aug 2008 15:53:41 GMT Sat, 30 Aug 2008 15:53:41 GMT http://blogs.law.harvard.edu/tech/rss GoT - list_messages http://gathering.tweakers.net Gathering of Tweakers http://tweakimg.net/g/if/logo.gif nl-nl http://gathering.tweakers.net/rss/list_messages/1193708/9 [Benchmarks] Het grote: "Post hier je RAID scores topic" II - Opslagmedia & I/O Controllers - GoT gathering@tweakers.net (Administrator) Enlightenment http://gathering.tweakers.net/forum/list_message/28851835?data%5Bsource%5D=rss#28851835 dummy@example.com (Enlightenment) zaterdag 06 oktober 2007 13:27 @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. @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. :)]]> http://gathering.tweakers.net/forum/list_message/28851835#28851835 Sat, 06 Oct 2007 11:27:05 GMT Nyarlathotep http://gathering.tweakers.net/forum/list_message/28852636?data%5Bsource%5D=rss#28852636 dummy@example.com (Nyarlathotep) zaterdag 06 oktober 2007 16:22 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. 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


http://i7.photobucket.com/albums/y251/SuperErik/HDTune_Benchmark_Intel___Raid_0_Vol.png

http://i7.photobucket.com/albums/y251/SuperErik/HDTachtest.jpg

http://i7.photobucket.com/albums/y251/SuperErik/ATTOtest.jpg


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.]]> http://gathering.tweakers.net/forum/list_message/28852636#28852636 Sat, 06 Oct 2007 14:22:37 GMT wouter10 http://gathering.tweakers.net/forum/list_message/28853062?data%5Bsource%5D=rss#28853062 dummy@example.com (wouter10) zaterdag 06 oktober 2007 17:42 Hier even een HDtach van de nieuwe Seagate 7200.11 Nu nog even in Raid zetten en dan wordt het leuk. Hier even een HDtach van de nieuwe Seagate 7200.11

http://www.speedy.vuurwerk.nl/hdtach_7200_11.JPG

Nu nog even in Raid zetten en dan wordt het leuk.]]> http://gathering.tweakers.net/forum/list_message/28853062#28853062 Sat, 06 Oct 2007 15:42:20 GMT Enlightenment http://gathering.tweakers.net/forum/list_message/28853101?data%5Bsource%5D=rss#28853101 dummy@example.com (Enlightenment) 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. @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.]]> http://gathering.tweakers.net/forum/list_message/28853101#28853101 Sat, 06 Oct 2007 15:49:38 GMT Nyarlathotep http://gathering.tweakers.net/forum/list_message/28853306?data%5Bsource%5D=rss#28853306 dummy@example.com (Nyarlathotep) zaterdag 06 oktober 2007 18:41 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?
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?]]> http://gathering.tweakers.net/forum/list_message/28853306#28853306 Sat, 06 Oct 2007 16:41:05 GMT Twister336 http://gathering.tweakers.net/forum/list_message/28854324?data%5Bsource%5D=rss#28854324 dummy@example.com (Twister336) zaterdag 06 oktober 2007 22:49 @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 @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 ;)]]> http://gathering.tweakers.net/forum/list_message/28854324#28854324 Sat, 06 Oct 2007 20:49:31 GMT Enlightenment http://gathering.tweakers.net/forum/list_message/28862701?data%5Bsource%5D=rss#28862701 dummy@example.com (Enlightenment) maandag 08 oktober 2007 17:37 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.
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:

http://www.soi.wide.ad.jp/class/20020032/slides/11/img/27.png

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.]]> http://gathering.tweakers.net/forum/list_message/28862701#28862701 Mon, 08 Oct 2007 15:37:09 GMT Twister336 http://gathering.tweakers.net/forum/list_message/28868486?data%5Bsource%5D=rss#28868486 dummy@example.com (Twister336) 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. 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. @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
http://users.pandora.be/twister336/raid.png

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.]]> http://gathering.tweakers.net/forum/list_message/28868486#28868486 Tue, 09 Oct 2007 13:23:00 GMT MensionXL http://gathering.tweakers.net/forum/list_message/28883406?data%5Bsource%5D=rss#28883406 dummy@example.com (MensionXL) 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? 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?]]> http://gathering.tweakers.net/forum/list_message/28883406#28883406 Thu, 11 Oct 2007 18:07:03 GMT RooN http://gathering.tweakers.net/forum/list_message/28909457?data%5Bsource%5D=rss#28909457 dummy@example.com (RooN) dinsdag 16 oktober 2007 17:47 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? Poosje verder, wat dingetjes geprobeerd maar tis nog niet echt zoals het zijn moet volgens mij...even een shotje van mn diskconfig:

http://wwwhome.cs.utwente.nl/~damhuisjr/pics/diskconfig_klein.jpg

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:

http://wwwhome.cs.utwente.nl/~damhuisjr/pics/atto.jpg

http://wwwhome.cs.utwente.nl/~damhuisjr/pics/hdtune.jpg

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?]]> http://gathering.tweakers.net/forum/list_message/28909457#28909457 Tue, 16 Oct 2007 15:47:57 GMT Enlightenment http://gathering.tweakers.net/forum/list_message/28909495?data%5Bsource%5D=rss#28909495 dummy@example.com (Enlightenment) 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. 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. @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.]]> http://gathering.tweakers.net/forum/list_message/28909495#28909495 Tue, 16 Oct 2007 15:54:59 GMT Enlightenment http://gathering.tweakers.net/forum/list_message/28909763?data%5Bsource%5D=rss#28909763 dummy@example.com (Enlightenment) dinsdag 16 oktober 2007 18:44 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 filesysteemDan 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.
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.]]> http://gathering.tweakers.net/forum/list_message/28909763#28909763 Tue, 16 Oct 2007 16:44:21 GMT WOK Paul http://gathering.tweakers.net/forum/list_message/28917530?data%5Bsource%5D=rss#28917530 dummy@example.com (WOK Paul) woensdag 17 oktober 2007 21:35 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 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

http://i23.tinypic.com/rat2j8.jpg

avarage read: 167.4 mb/s]]> http://gathering.tweakers.net/forum/list_message/28917530#28917530 Wed, 17 Oct 2007 19:35:08 GMT RooN http://gathering.tweakers.net/forum/list_message/28930845?data%5Bsource%5D=rss#28930845 dummy@example.com (RooN) vrijdag 19 oktober 2007 23:58 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:
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.]]> http://gathering.tweakers.net/forum/list_message/28930845#28930845 Fri, 19 Oct 2007 21:58:17 GMT the_RJ http://gathering.tweakers.net/forum/list_message/28932416?data%5Bsource%5D=rss#28932416 dummy@example.com (the_RJ) zaterdag 20 oktober 2007 14:37 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 picsHallo, 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)
quote:
WhiteRaver schreef op dinsdag 28 augustus 2007 @ 20:52:
2 x Samsung T166 320GB, ATTO 2.34, Raid 0
http://img206.imageshack.us/img206/831/attoraid02xsamsungt1663qe9.jpg

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:

http://www32.brinkster.com/hethaantje/raid_benchmark.png

Zelfde hardeschijven op hetzelfde mobo alleen de andere controller die op het mobo aanwezig is, geeft dat zoveel verschil? (BIOS is up-to-date)]]> http://gathering.tweakers.net/forum/list_message/28932416#28932416 Sat, 20 Oct 2007 12:37:32 GMT Enlightenment http://gathering.tweakers.net/forum/list_message/28933566?data%5Bsource%5D=rss#28933566 dummy@example.com (Enlightenment) zaterdag 20 oktober 2007 18:45 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. 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.]]> http://gathering.tweakers.net/forum/list_message/28933566#28933566 Sat, 20 Oct 2007 16:45:10 GMT Sir_Mj http://gathering.tweakers.net/forum/list_message/28934938?data%5Bsource%5D=rss#28934938 dummy@example.com (Sir_Mj) zondag 21 oktober 2007 00:29 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) 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:
http://www.notan.nl/2.png


Deze is met de laatste drivers van siliconimage.com:
http://www.notan.nl/1.png


-update - Ook nog een ATTO-benchmark:
http://www.notan.nl/3.jpg

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)]]> http://gathering.tweakers.net/forum/list_message/28934938#28934938 Sat, 20 Oct 2007 22:29:11 GMT Enlightenment http://gathering.tweakers.net/forum/list_message/28935042?data%5Bsource%5D=rss#28935042 dummy@example.com (Enlightenment) zondag 21 oktober 2007 01:12 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. 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.]]> http://gathering.tweakers.net/forum/list_message/28935042#28935042 Sat, 20 Oct 2007 23:12:25 GMT Sir_Mj http://gathering.tweakers.net/forum/list_message/28935280?data%5Bsource%5D=rss#28935280 dummy@example.com (Sir_Mj) zondag 21 oktober 2007 08:24 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? 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?]]> http://gathering.tweakers.net/forum/list_message/28935280#28935280 Sun, 21 Oct 2007 06:24:29 GMT Enlightenment http://gathering.tweakers.net/forum/list_message/28936819?data%5Bsource%5D=rss#28936819 dummy@example.com (Enlightenment) zondag 21 oktober 2007 14:49 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. 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.]]> http://gathering.tweakers.net/forum/list_message/28936819#28936819 Sun, 21 Oct 2007 12:49:17 GMT Sir_Mj http://gathering.tweakers.net/forum/list_message/28937046?data%5Bsource%5D=rss#28937046 dummy@example.com (Sir_Mj) zondag 21 oktober 2007 15:26 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! 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!]]> http://gathering.tweakers.net/forum/list_message/28937046#28937046 Sun, 21 Oct 2007 13:26:02 GMT Sir_Mj http://gathering.tweakers.net/forum/list_message/28956608?data%5Bsource%5D=rss#28956608 dummy@example.com (Sir_Mj) woensdag 24 oktober 2007 14:34 Nu een adaptec 1220SA pci-express kaartje geïnstalleerd en het gaat stukken sneller! ter vergelijking met de sweex-pci controller: edit: typo Nu een adaptec 1220SA pci-express kaartje geïnstalleerd en het gaat stukken sneller!
http://www.notan.nl/atto_nieuw.jpg

ter vergelijking met de sweex-pci controller:
http://www.notan.nl/3.jpg

edit: typo]]> http://gathering.tweakers.net/forum/list_message/28956608#28956608 Wed, 24 Oct 2007 12:34:47 GMT Enlightenment http://gathering.tweakers.net/forum/list_message/28957023?data%5Bsource%5D=rss#28957023 dummy@example.com (Enlightenment) woensdag 24 oktober 2007 15:26 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. 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.]]> http://gathering.tweakers.net/forum/list_message/28957023#28957023 Wed, 24 Oct 2007 13:26:11 GMT Sir_Mj http://gathering.tweakers.net/forum/list_message/28960411?data%5Bsource%5D=rss#28960411 dummy@example.com (Sir_Mj) woensdag 24 oktober 2007 23:26 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!! Bij deze dan!! ;)
http://www.notan.nl/5.jpg

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!! _/-\o_]]> http://gathering.tweakers.net/forum/list_message/28960411#28960411 Wed, 24 Oct 2007 21:26:01 GMT WOK Paul http://gathering.tweakers.net/forum/list_message/29025399?data%5Bsource%5D=rss#29025399 dummy@example.com (WOK Paul) zondag 04 november 2007 21:38 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 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
http://i24.tinypic.com/24etg08.jpg
avarage read :192 mb/s

atto 3x320gb perc5i raid0 strip size 32kb cluster 64kb NO read ahead.JPG
http://i20.tinypic.com/o6jjvt.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 :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
http://i20.tinypic.com/znwx84.jpg

edit:
was vergeten te zeggen dat read ahead aan of uit in de banchmark progjes nauwelijks verschil maakte]]> http://gathering.tweakers.net/forum/list_message/29025399#29025399 Sun, 04 Nov 2007 20:38:00 GMT