_Dune_ schreef op dinsdag 19 september 2006 @ 00:06:
[...]
Ik wil niet zeggen dat PCI zozeer aan zijn limiet zit. Jij wilt nu eenmaal extreme dingen doen, waar aandere oplossingen voor zijn bedacht. Bijvooebeeld een bus met meer bandbreedte is PCI64 of PCI-X zoals veel in zwaardere werkstations of servers wordt gebruikt en tegenwoordig ook PCI-e.
Zeker waar, ik heb zelf ook een Areca PCIe RAID controller; dat werkt natuurlijk fantastisch. Het probleem is dat je daar een redelijk duur mobo en vooral dure controller voor nodig hebt. Ik probeer het met een stuk minder.
Zo-ie-zo presteren de onboard S-ATA controllers nu ook weer niet zo heel denderend.
Ik ga geen onboard RAID gebruiken maar Software RAID (geom_raid5).
Maar onboard RAID doet het prima voor RAID0 of RAID1. Alleen het is geen hardware RAID, maar driver-RAID; vrijwel alle dingen worden door de drivers gedaan. Sommige onboard controllers vallen onder de categorie "hardware-assisted" en dat is dan al een luxe versie.
Wat jij probeerd is zogezegd "voor een dubbeltje op de eerste rang zitten".
Dat klopt inderdaad.
Maar hopelijk gaat het nog lukken ook.
Allereerst wordt het gigabit via PCI-express dus ik reken op 70MB/s throughput. Het probleem is meer dat software RAID5 de schijven tegelijk benadert, en je dus bus contention krijgt. Ik denk dat met 4 schijven op een PCI-controller nog wel te doen is, maar hoe hoog de performance zal worden valt nog te bezien.
Vergeet ook niet dat veel andere dingen op PCI draaien: Legacy IO, USB (?), onboard Audio, etc. Volgens mij delen die allemaal dezelfde bus, iig met goedkope consumentenbordjes zoals het mobo wat ik voor ogen heb.
Zo raar is dat niet. Een schoon 2-platter design heeft nou eenmaal minder dingen die stuk kunnen gaan dan een complexe schijf van 4/5 platters die ook nog eens vreselijk warm wordt. Maar bewijs is moeilijk te geven; het duurt nog even voor de Seagate 7200.10 serie lang genoeg meedraait om de RMA statistieken enige waarde te geven.
En ja ik denk dat 2x320GB warmer wordt dan 750GB maar zo heel veel zal het niet schelen, en kijk eens hoe duur die 750GB versie is! Dat is niet te betalen joh. Sowieso ben ik iemand van mainstream: daar krijg je het meeste waar voor je geld. Als je het duurste neemt ben je qua prijs/performance-ratio altijd slechter uit.
Qua prijs zit je wél goed though, maar als je toch 8 shcijven van 320gb kunt betalen, maken die 150 euro voor een PCIe controller weinig uit...
Reken daar ook een duurder moederbord bij he, en dan ook weer duurdere processor. En dan nog snap ik niet goed wat het voordeel is; als ik met 250 euro minder dezelfde capaciteit/performance fileserver kan bouwen.
ing._Buttje schreef op zaterdag 23 september 2006 @ 15:28:
btw als TS RAID 5 overweegt, dan hoop ik dat het voornamelijk leesacties betreft, want schrijfacties met een softwarematige RAID 5 schiet niet erg op! (~25MB/s) Beetje fileserver waar je performance van vraagt moet RAID 0+1 hebben.
Dat is niet helemaal waar.
Je moet alleen een slimme RAID-class hebben die niet klakkeloos 2-phase writes doet maar 1-phase writes.
Dat veel (softwarematige) RAID5 arrays zo'n lage write-performance hebben, komt door wat Sun de 'RAID5 write hole' noemt. Stel je hebt een stripesize van 32KB en je hebt 4 schijven, dan heb je een 'full stripe' van (4-1) * 32KB=96KB. Als je 96KB schrijft dan kan dat optimaal, je kunt de parity uitrekenen en die schrijf je naar de parity schijf (schijf 4), maar als je bijvoorbeeld 64KB schrijft, hoe kun je dan de parity uitrekenen? Het antwoord: je moet de resterende 32KB lezen en daarna de parity uitrekenen. Gevolg is dat voor veel schrijf-acties je moet lezen om te kunnen schrijven. Dat is natuurlijk desastreus voor je write-performance.
De RAID-class die ik wil gebruiken, GEOM_RAID5, heeft echter een geavanceerde write-queue die requests samenvoegt zodat full stripes ontstaan, en je dus geen write hole meer hebt; in elk geval niet voor sequential writes. Laat ik je een sneakpeek van mijn benchmarks presenteren:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| graid5 (4 disks, 64KB stripe, rawdevice, ufs-bypass, write-queueing enabled, 14sep)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
DD benchmark(1GB) Results in MB/s avg
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
4k READ 40.2 40.2 40.1 40.1
WRITE 32.8 32.4 32.5 32.5
16k READ 83.4 83.7 83.7 83.6
WRITE 100.2 101.1 100.0 100.4
64k READ 114.0 114.2 114.7 114.3
WRITE 195.7 195.2 194.8 195.2
128k READ 173.9 179.5 177.9 177.1
WRITE 203.3 203.4 201.8 202.8
1m READ 177.1 177.3 177.8 177.4
WRITE 197.2 195.2 194.6 195.6 |
Zoals je ziet doet graid5 tegen de ~200MB/s write speed aan (sequentieel). Random IO performance is ook hoger iig dan een enkele disk (45%). Ik maak me dus weinig zorgen over de performance die ik krijg, zolang een bus-bottleneck maar geen roet in het eten gooit. geom_raid5 is overigens nog in ontwikkeling.
:strip_icc():strip_exif()/u/137443/ronavatar2.jpg?f=community){kind=avatar}
:strip_icc():strip_exif()/u/32232/laupro60x60.jpg?f=community)
:strip_icc():strip_exif()/u/48952/Ultraman-60x60-Ray-Animated.jpg?f=community)
knop als je zelf de afgelopen 24u de laatste post hebt geplaatst./u/79923/DUT11.png?f=community)
:strip_icc():strip_exif()/u/92085/crop5aa165833d640_cropped.jpeg?f=community)
/u/41398/halo_icon_bll.JPG?f=community){kind=icon}
:strip_icc():strip_exif()/u/96648/shakira.jpg?f=community)
:strip_exif()/u/37472/90-2.gif?f=community)
damn 
:strip_icc():strip_exif()/u/96899/blackberry_lp.jpg?f=community)
/u/102837/Windows%25208%2520logo.png?f=community)
/u/154493/Moderat_ii.png?f=community)