Areca kaart op Tyan moederbord, PCI bus vol?

[Wolfboy]

Beste Tweakers,

Na een paar flinke bestellingen de afgelopen paar weken heb ik nu een mooi Areca kaartje in mijn systeem... maar, als ik een paar grote bestanden aan het heen en weer aan het kopieren van (zeg.. ~10GB) dan hangt het systeem gewoon volledig waarbij ik nu zit te denken aan een volle PCI bus.
Aangezien mijn systeempje al weer wat ouder is overweeg ik wel om over niet al te lange tijd te upgraden naar bijvoorbeeld een eenvoudig Core 2 Duo systeempje.

Mijn vraag is alleen, gaat dit helpen of zal ik eerder richting een flink Xeon systeem moeten gaan om een pci bus te hebben die dit geweld aan kan. 2 weken geleden bij een benchmark had ik al 600MB/s schrijfsnelheid continu, en dat was met de helft van de harde schijven aangesloten, de leessnelheid kon ik toen al niet eens testen omdat het hele systeem begon te hangen zodra ik dat probeerde. Ook vind ik het booten nogal uitzonderlijk lang duren maar het zou kunnen dat het normaal is voor deze raid kaart, een aantal van de scsi controllers waar ik mee gewerkt heb deden er nog wel wat langer over (5min scannen voor schijven bijvoorbeeld *kuch*oude dell perc's*kuch*).

De relevante specs:
Moederbord: Tyan K8WE (2 PCI-E x16 sloten waarvan 1 voor de raid controller en 1 voor een 6600GT)
Raid kaart: Areca ARC-1280ML

OS info: ik draai Gentoo Linux met 2.6 kernel en de laatste Areca drivers.
Niet dat het erg relevant is aangezien ik met de Windows installer hetzelfde probleem heb

_{Aangezien ik geen 'spam je specs' topic wil hebben zal ik verder even niets plaatsen, mocht je meer willen zien dan staan de specs in mijn sig onder het "workstation" gedeelte.}

Dus... heeft iemand enig idee hoe ik dit zou kunnen oplossen?

[ Voor 5% gewijzigd door Wolfboy op 16-06-2007 22:50 . Reden: info toegevoegd ]

[Verwijderd]

Areca controllers hebben geen PCI interface. Je bedoelt PCI-express. Dat is een wereld van verschil.

Lang duren van booten, mja tijdje firmware initen en dan 5 seconden timeout, wat is lang? Het zal bij elkaar zo'n 20 seconden duren hooguit.

Maar als je systeem hangt zou je toch eens moeten denken aan probleemoplossing, want dat is natuurlijk niet normaal. Dat PCI-express daar de schuldige van is acht ik bijzonder klein zo niet onmogelijk. Heb je al op algehele stabiliteit getest?

[Wolfboy]

Aangezien ik problemen als deze nog niet eerder ondervonden heb en het eigenlijk alleen ondervind bij zwaar lees (en inmiddels dus ook schrijfwerk) naar de controller vermoed ik toch dat een of andere bus vol zit.

Zolang ik zwaar aan het schrijven ben is direct het volledige systeem onwerkbaar, om de paar seconden reageert het systeem of de cursor begint te haperen.
Het systeem zelf is in principe erg stabiel, ik heb af en toe weleens een X crash maar dat is meer door m'n eigen experimenteer werk, het systeem zelf blijft stabiel draaien.

Uiteraard, PCI != PCI-E maar het blijft een bus en elke bus heeft z'n limiet.

Enne... het trage booten is niet zo'n probleem hoor, had alleen wel wat sneller gemogen

[Verwijderd]

Lijkt me eerder als een driver issue, maargoed. Welk OS draai je, welke drivers gebruik je en is het niet een idee om Areca eens te mailen over dit probleem?

PCI-express is overigens geen bus maar point-to-point interface. Maargoed dat is een technisch detail.

En limiet, daar komt Areca niet aan. PCIe x8 betekent 2GB/s in beide richtingen, oftwel 4GB/s totale bandbreedte. Dat verstookt zelfs een Areca niet.

[ Voor 22% gewijzigd door Verwijderd op 16-06-2007 22:27 ]

[JSK]

PCI-express bus is point-to-point, dus die zit niet vol. Hoe groot is de cache op je controller? Mijn ervaring met een Areca Arc-1160 en 1Gbyte cache, is als de cache naar de schijf wordt weggeschreven het hele systeem hangt. Maar dat duurt nooit langer dan 10-20 seconde. Dus wat is precies 'hangen' volgens jou?

[winwiz]

JSK schreef op zaterdag 16 juni 2007 @ 22:30:
PCI-express bus is point-to-point, dus die zit niet vol. Hoe groot is de cache op je controller? Mijn ervaring met een Areca Arc-1160 en 1Gbyte cache, is als de cache naar de schijf wordt weggeschreven het hele systeem hangt. Maar dat duurt nooit langer dan 10-20 seconde. Dus wat is precies 'hangen' volgens jou?

Zelfs dit zou ik absoluut niet willen. Zou toch al te gek zijn dat je systeem niet reageert omdat er een cache geschreven moet worden.

[Wolfboy]

Verwijderd schreef op zaterdag 16 juni 2007 @ 22:26:
Lijkt me eerder als een driver issue, maargoed. Welk OS draai je, welke drivers gebruik je en is het niet een idee om Areca eens te mailen over dit probleem?

PCI-express is overigens geen bus maar point-to-point interface. Maargoed dat is een technisch detail.

En limiet, daar komt Areca niet aan. PCIe x8 betekent 2GB/s in beide richtingen, oftwel 4GB/s totale bandbreedte. Dat verstookt zelfs een Areca niet.

Standaard draai ik eigenlijk Gentoo Linux met een 2.6 en de laatste drivers van Areca, maar ook tijdens een windows install bij het formatteren (om even te testen, het installeren van windows wilde niet lukken aangezien windows de schijven na de reboot niet kon vinden) bleef het systeem "hangen".

JSK schreef op zaterdag 16 juni 2007 @ 22:30:
PCI-express bus is point-to-point, dus die zit niet vol. Hoe groot is de cache op je controller? Mijn ervaring met een Areca Arc-1160 en 1Gbyte cache, is als de cache naar de schijf wordt weggeschreven het hele systeem hangt. Maar dat duurt nooit langer dan 10-20 seconde. Dus wat is precies 'hangen' volgens jou?

Nog niets veranderd aan de cache, alleen de meegeleverde 256MB dus.

En wat ik onder hangen versta, nou... dat het systeem tijdens het schrijven niet/nauwelijks reageert, de cursor kan ik meestal nog wel bewegen maar verder is er niets meer mogelijk, het wisselen van applicaties lukt niet, het intikken van comando's gaat niet (tekens worden tenminste niet weergegeven op het scherm) etc...

Maargoed, dat "hangen" van die Arc-1160 lijkt dus vergelijkbaar te zijn, dat heb ik dus ook op het moment dat de kaart flink bezig is (bijvoorbeeld tijdens het formatteren oid.).

[Verwijderd]

Ja oke maar daarna loopt het systeem dus wel gewoon verder? Je deed het overkomen alsof je systeem hangt; waarmee normaal gezien een permanente vorm verstaan wordt; een crash. Maar wat jij ondervindt is dus dat er geen I/O mogelijk is tijdens dat dat de buffer naar disk wordt geschreven. Dat is normaal.

Je kunt wel A/V mode inschakelen of write through mode gebruiken. Dat verandert de buffer strategie.

[Wolfboy]

Verwijderd schreef op zaterdag 16 juni 2007 @ 23:14:
Ja oke maar daarna loopt het systeem dus wel gewoon verder? Je deed het overkomen alsof je systeem hangt; waarmee normaal gezien een permanente vorm verstaan wordt; een crash. Maar wat jij ondervindt is dus dat er geen I/O mogelijk is tijdens dat dat de buffer naar disk wordt geschreven. Dat is normaal.

Je kunt wel A/V mode inschakelen of write through mode gebruiken. Dat verandert de buffer strategie.

Ik weet niet hoe het met jou zit maar ik vind het niet normaal als ik mijn systeem niet meer kan gebruiken op het moment dat ik naar de raid array aan het schrijven ben
Mijn 3ware 7506-12 haalt bij lange na niet dezelfde snelheid maar ook daarbij heb ik nog nooit dit soort problemen ondervonden.

En mijn uitleg was misschien niet geheel duidelijk nee, maargoed... de vraag is dus nu, hoe kom ik van dit probleem af. Een nieuw mobo + cpu is eventueel een optie in ieder geval, als dit het probleem maar oplost. Write through kan wel, maar wat heb ik dan nog aan de buffers Het is juist fijn om eventjes snel naar de buffer te kunnen schrijven.

[Verwijderd]

Ik gaf je nog een andere optie.

En ik kan mijn systeem nog prima gebruiken hoor, alleen is het zo dat schrijfopdrachten even worden uitgesteld. Misschien dat Windows dan gelijk over de zeik gaat, die weet sowieso aardig wat m.i. overbodige I/O te veroorzaken.

[ Voor 77% gewijzigd door Verwijderd op 16-06-2007 23:36 ]

[John2B]

Bekend probleem bij het schrijven van dit soort omvangrijke bestanden bij gebruik van driver 1.20.

Het probleem schijnt niet te spelen met driver 1.02 die er volgens mij alleen voor Windows is.

[Wolfboy]

Verwijderd schreef op zaterdag 16 juni 2007 @ 23:35:
Ik gaf je nog een andere optie.

En ik kan mijn systeem nog prima gebruiken hoor, alleen is het zo dat schrijfopdrachten even worden uitgesteld. Misschien dat Windows dan gelijk over de zeik gaat, die weet sowieso aardig wat m.i. overbodige I/O te veroorzaken.

Het gaat nu even over Linux, dus Windows is het probleem niet. Het probleem zit ook niet zo zeer in het niet kunnen wegschrijven van de data, want als ik zit te werken op een niet functionerende netwerkschijf dan zal dat programma misschien blijven hangen, maar mijn window manager blijft normaal gesproken gewoon functioneren. Als ik nu iets doe als "dd if=/dev/sda of=/dev/zero" dan kan ik daarna niet eens meer normaal tikken in de console.

Overigens, wat bedoel je precies met A/V mode, achtergrond initialisatie? Alle arrays zijn geinitialiseerd, zelfs met alleen maar raid 0 arrays (die dus geen initialisatie vereisen) komt dit probleem voor.

John2B schreef op zaterdag 16 juni 2007 @ 23:45:
Bekend probleem bij het schrijven van dit soort omvangrijke bestanden bij gebruik van driver 1.20.

Het probleem schijnt niet te spelen met driver 1.02 die er volgens mij alleen voor Windows is.

Hmm, das best vervelend dan, maargoed, ik ga eens een andere driver proberen. Het kan zijn dat het even duurt voor ik het weer fatsoenlijk kan testen want ik heb het wat druk (tentamens enzo...)

[Verwijderd]

Wolfboy schreef op zondag 17 juni 2007 @ 00:11:
Het gaat nu even over Linux, dus Windows is het probleem niet. Het probleem zit ook niet zo zeer in het niet kunnen wegschrijven van de data, want als ik zit te werken op een niet functionerende netwerkschijf dan zal dat programma misschien blijven hangen, maar mijn window manager blijft normaal gesproken gewoon functioneren. Als ik nu iets doe als "dd if=/dev/sda of=/dev/zero" dan kan ik daarna niet eens meer normaal tikken in de console.

Hm ik weet niet in hoeverre de drivers van Linux vergelijkbaar zijn met die in FreeBSD, maar wat jij beschrijft heb ik niet ervaren. Je moet wel weten dat DD standaard met 512-byte blokjes werkt en dat kan dus erg intensief zijn, je zou eerder iets als dit moeten gebruiken:

dd if=/dev/sda of=/dev/null bs=1m

verder hoop ik dat je /dev/null hebt gebruikt ipv /dev/zero.

Niet normaal tikken tikken in de console, mja, interrupt probleem? Wat is je load? Welke systeemprocessen zie je in top (shift+S) etc?

Overigens, wat bedoel je precies met A/V mode

Audio/Video komt het van dacht ik. Je had ook A/V hardeschijven, die zorgen voor een heel gelijkmatige afhandeling van I/O zodat je geen lost frames krijgt enzo. Areca kent ook een A/V functie, maar die is standaard niet instelbaar. Moet je maar even op googlen. Gevolg is dat er anders met de write buffer wordt omgegaan en deze veel gelijkmatiger naar de disk geschreven wordt, om zo te voorkomen dat de I/O tijdelijk blokkeert. Gevolg is echter wel lagere algehele I/O performance.

Maar eigenlijk denk ik dat je een ander probleem hebt, dus daar zou je eerst eens naar moeten kijken. En probeer je het ook eens in FreeBSD/FreeSBIE?

[Wolfboy]

Verwijderd schreef op zondag 17 juni 2007 @ 00:23:
[...]

Hm ik weet niet in hoeverre de drivers van Linux vergelijkbaar zijn met die in FreeBSD, maar wat jij beschrijft heb ik niet ervaren. Je moet wel weten dat DD standaard met 512-byte blokjes werkt en dat kan dus erg intensief zijn, je zou eerder iets als dit moeten gebruiken:

dd if=/dev/sda of=/dev/null bs=1m

verder hoop ik dat je /dev/null hebt gebruikt ipv /dev/zero.

Ik heb meerder blocksizes geprobeerd, tot 1G toe.
Overigens, /dev/null en /dev/zero zijn kwa schrijven hetzelfde, kwa lezen geeft /dev/null alleen niets terug (behalve return 0;).

Ik zou het in FreeBSD even niet uit m'n hoofd weten te vinden (waarschijnlijk ergens in /usr/src/sys/i386/i386/mem.c ofzo maar onder Linux kan je het iig uit /usr/src/linux/char/drivers/char/mem.c halen.

Dit staat er letterlijk in: #define write_zero write_null

Niet normaal tikken tikken in de console, mja, interrupt probleem? Wat is je load? Welke systeemprocessen zie je in top (shift+S) etc?

De load is normaliter rond de 0.1 en tijdens het schrijven varieert het tussen de 1.5 en 2.5 meestal (dual processor systeem, dus dat is wel acceptabel).

Ik zal morgen nog eens wat meer testen als ik de mogelijkheid heb.

Audio/Video komt het van dacht ik. Je had ook A/V hardeschijven, die zorgen voor een heel gelijkmatige afhandeling van I/O zodat je geen lost frames krijgt enzo. Areca kent ook een A/V functie, maar die is standaard niet instelbaar. Moet je maar even op googlen. Gevolg is dat er anders met de write buffer wordt omgegaan en deze veel gelijkmatiger naar de disk geschreven wordt, om zo te voorkomen dat de I/O tijdelijk blokkeert. Gevolg is echter wel lagere algehele I/O performance.

Interessant, ik zal er eens naar kijken

Maar eigenlijk denk ik dat je een ander probleem hebt, dus daar zou je eerst eens naar moeten kijken. En probeer je het ook eens in FreeBSD/FreeSBIE?

Ga ik proberen zodra ik weer wat tijd heb, ik zat er toch al over te denken om over te stappen naar FreeBSD, daar kan ik de Gentoo portage ook wel gebruiken mocht het nodig zijn

[Verwijderd]

Load van 2.5 tijdens schrijven naar hardware RAID? Dat lijkt me niet in orde.

Ik zou hetzelfde maareens proberen met FreeSBIE (FreeBSD livecd) ofzo en als het daar wel normaal werkt (geen hoge load) dan kun je concluderen dat er iets met drivers in linux niet lekker zit.

[ Voor 55% gewijzigd door Verwijderd op 17-06-2007 01:29 ]

[Cergorach]

Heb je toevallig harde schijfen direct aan je moederbord controller hangen (zoals bv. je OS schijf)?
Als dit het geval is zou ik eens proberen om alles aan je areca controller te hangen, dat verhielp bij mij een dergelijk probleem.

[Wolfboy]

Ik heb inmiddels van alles getest maar vreemd genoeg heb ik geen enkel probleem meer, alles werkt nu prima en niets vertraagd meer.

Het kan komen doordat ik nog wat extra harde schijven aan m'n moederbord had hangen (er hing eerst nog 1 extra schijf aan) of de kernel driver was niet helemaal lekker (ik heb een kernel recompile gedaan). Hoe dan ook... alles draait nu gewoon prima en sneller dan ooit

Bij een "ddrescue -b 256M /dev/zero /tmp/nulletjes -s 10G" komt de load op 1.5 te zitten waarbij ddrescue dus 100% van de ene cpu gebruikt en de andere cpu voor ~50% bezig is met IO wait
Hoe dan ook, ik ben tevreden, het draait allemaal zoals het moet werken.