[RedHat 7.3]Promise FasTrak100TX2 Raid performance

[Oet]

Vraagje:

Ik heb al een flinke tijd een RedHat 7.3 bak, specs: http://tweakers.net/gallery/sys/10732

De Samsung is mijn root schijf waar het OS op staat en de 2 maxtors (160GB & 120GB) heb ik in een RAID-0 staan op de promise controller (array van 240GB).

Het hele idee hiervan is dat ik een snelle schijf heb om aan te spreken via GigaBit netwerk(om downloads snel over te pompen enz). Ik heb de laatste legacy kernel 2.4.20-46.7 en daar ergens vandaan een FasTrak precompiled driver kunnen downloaden. Extra dingetjes aan de grub.conf toegevoegd om er voor te zorgen dat de driver werkt en klaar het werkt. /dev/sda is nu de raid array.
Nu heb ik dus de array volledig gepartitioneerd en geformatteerd met ext3.

hdparm test results:

code:

[root@router root]# hdparm -Tt /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.57 seconds =224.56 MB/sec
 Timing buffered disk reads:  64 MB in  1.17 seconds = 54.70 MB/sec
[root@router root]# hdparm -Tt /dev/sda

/dev/sda:
 Timing buffer-cache reads:   128 MB in  0.48 seconds =266.67 MB/sec
 Timing buffered disk reads:  64 MB in  1.03 seconds = 62.14 MB/sec

/dev/hda is dus mijn standaard schijf, die samsung.

Nu is mijn grote vraag: waarom is het niet zo snel?? De schijven zijn beide aangesloten met een aparte ata-133 kabel aan de poorten van de promise, beide zijn op master gejumperd, beide staan als UDMA-5 in de promise bios weergegeven.

Kan iemand me misschien helpen hierbij?

[_JGC_]

Allereerst draai je een antieke distro met een antieke kernel en een software RAID controler die aangesloten is via de PCI bus.
Verwacht je nou echt met deze verouderde opstelling 120MB/s te halen?

[igmar]

Euh, koop een fatsoenlijke RAID kaart Promise is gewoon troep, je kan beter investeren in een kaart die echt RAID doet ipv in software.

[Oet]

Leuk om te horen dat Promise troep is, dat zag ik in verschillende andere topics ook al, maar is het zo erg dan? ik bedoel, is er dan helemaal géén performance winst uit te halen of komt dat pas al ik ga upgraden naar bv Fedora Core 5 oid.?

Btw: wat is volgens jullie dan wel een echte raid kaart (betaalbaar?)

http://www.gsmhut.net/productenv.php?id=48976 <-- Dit misschien wel iets?

En ik las net iets op een site via google dat wanneer ik software RAID gebruik via de promise kaart er iig een veel betere performance uit te halen is. bron

[ Voor 54% gewijzigd door Oet op 04-08-2006 12:00 ]

[_JGC_]

Sluit die harddisks gewoon aan op je VIA onboard controler en gebruik gewoon de software RAID uit de linux kernel, scheelt je al heel wat overhead omdat je dan direct via V-Link ipv PCI bus tussen chipset en harddisk controler communiceert.

[Oet]

En als ik een extra IDE controller gebruik zoals een gewone UltraTrak 133/TX2 van promise en daar software raid op draai? (heb nog 2 ide devices meer op die bak dus onboard kan wel maar wordt irri met master/slave dingetjes..)
Zou het veel schelen in performance?

[roelio]

Dat zou ik eerst dan gaan testen als je de mogelijkheid hebt Ik heb meer dan eens gezien dat twee schijven op Master op een Ultra133 of Ultra100 kaart van Promise helemaal niet ervoor zorgt dat die beide Masters op volledige snelheid draaien.

(bijv: schijven halen max 50MB/s maar als je ze tegelijk gaat benchen of gebruiken haal je ineens maar 25-30MB/s per schijf)

[_JGC_]

Een 32bit PCI kaart zal altijd slomer zijn dan je onboard interfaces. Daarnaast mag je bij RAID-0 niet zomaar even 2x50MB/s bijelkaar optellen om zo 100MB/s te krijgen, dat haal je in de praktijk natuurlijk nooit. Daarnaast is hdparm een zeer slechte benchmark tool.

[Oet]

Nja als ik bench met nu de 2 maxtor schijven als SOFTWARE raid-0 via een ultra133 tx2 controller als addonkaart met hdparm:

code:

/dev/md0:
 Timing buffer-cache reads:   128 MB in  0.47 seconds =272.34 MB/sec
 Timing buffered disk reads:  64 MB in  1.07 seconds = 59.81 MB/sec

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.46 seconds =278.26 MB/sec
 Timing buffered disk reads:  64 MB in  1.14 seconds = 56.14 MB/sec

Erg betreurend dus!

Ook: als ik test met Samba of ProFTPd vanaf mijn werkstation (3com gigabit switch, en netwerkkaarten op beide bakken) dan zie ik als ik upload naar de standaardschijf een ~18MB/s continue+-.. Doe ik het naar de array: eerste 3sec 18MB/s daarna inzakker naar ~5MB/s voor zo'n 6sec, dan weer even 18MB/s en dan weer inzakker, en dat zo aan de lopende band....
Al met al kan ik dus concluderen dat het raid-0 verhaal bij mij geen enkele zin heeft op deze manier, kan iemand me vertellen waar de bottleneck zit? CPU? toch die promisekaart? ik snap er de ballen van, overigens een Chunk size van 32KB voor de raid-0 en een gewone ext3 format over de 2 FD partities heen gemaakt...

ps: ik heb met hdparm de settings van hde en hdg (de 2 drivers van de stripe) aangepast zodat ie op udma draait enz enz:

code:

/dev/hde:
 multcount    = 16 (on)
 I/O support  =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 19929/255/63, sectors = 320173056, start = 0
 busstate     =  1 (on)

/dev/hdg:
 multcount    = 16 (on)
 I/O support  =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 238216/16/63, sectors = 240121728, start = 0
 busstate     =  1 (on)

Iemand enige suggestie?

[Blastpe]

Ook ik ben de gelukkige eigenaar geweest van een A7V333 met onboard raid waarvan de performance om te huilen was. Uiteindelijk de oplossing gevonden in aanpassing van de bios. Het bleek dus een hardware probleem te zijn en niet zozeer een software/driver probleem. De VIA chipset op dit bord heeft IDE performance problemen. Er is zelf voor Windows een VIA patch http://www.viaarena.com/d...1&CatID=1180&SubCatID=118Tot mijn spijt ben ik niet bekend met Linux en kan je ook geen direct antwoord geven. Wat ik je kan vertellen is dat de latency van de RAID controller verhoogd moet worden. Wat je kan proberen is de latency in de bios te verhogen van 32 naar 64. Het meeste effect krijg je door alleen de latency van de controller te verhogen naar 255. Ik hoop je een beetje opweg geholpen te hebben

[Oet]

Thnx voor de tip maar het gaat hier helaas om de A7v333-non raid uitvoering, althans er zit geen raid controller op het bordje zelf. De raid controller en extra ide controller die ik gebruik zijn pci-kaartjes dus ik denk niet dat jou tip me gaat helpen. Toch bedankt voor je informatie

[Blastpe]

Het hardware probleem betreft IDE en PCI en heeft wel betrekking op PCI kaarten. Het was voor mij de onboard raid die het probleem zo duidelijk naar voren bracht, vandaar dat ik het aanhaalde.
http://www.tecchannel.de/...rchiv/401770/index10.html.
Misschien verduidelijkt deze link wat ik bedoel.

[Oet]

Ah ja nu snap ik het, je hebt gelijk.. Helaas bestaat er niet zo'n patch voor een linux systeem..
Daarentegen, als ik de testresultaten op je laatste link bekijk dan haal ik nog niet eens de snelheid die hij zou moeten halen voor dat de patch toegepast was dus is er toch iets meer aan de hand denk ik...

Ik las net ergens dat dit vanaf kernel 2.4.4 er standaard in gebakken zit

[ Voor 11% gewijzigd door Oet op 05-08-2006 12:36 ]

[Oet]

Nou vergeet die FastTrak kaart maar idd, wat een bagger zooi voor onder linux..

Btw: onder Fedora core 5 wordt ie wel goed ondersteund, sort of, iig het array wat je maakt in de kaart wordt netjes gedetecteerd, maar dat komt dan weer door de dmraid functionaliteit die Fedora core 5 heeft Best leuk maar meer dan 66MB/s kon ik er niet uit persen.

Nu heb ik de schijven in software raid op de kaarten geprobeerd:
* Promise FastTrak 100/Tx2
* Promise Ultra 133/Tx2
* Silicon Image 0680a RAID controller
* Onboad via ultra133 controller

Nu bleek dat al deze pci-controllers bagger zijn qua performance behalve de onboard controller!!
Ik heb de 2 schijven nu beide als slave staan (os hdd als primairy master, 160GB van stripe op primairy slave, Plextor 716a als secondary master en 120GB van stripe op secondairy slave).

Dit resulteert in: (in redhat 7.3)
/dev/md0:
Timing buffer-cache reads: 128 MB in 0.47 seconds =272.34 MB/sec
Timing buffered disk reads: 64 MB in 0.57 seconds =112.28 MB/sec

Waar ik dan weer zeer van wordt

Nou ben ik niet zo gecharmeerd van het master/slave principe maar zijn er dan eigelijk wel sneller pci p-ata controllers? Of ligt het aan mijn moederbord dat de performance gewoon zo matig is?

[nzyme]

wat ik even niet begrijp/volg: heb je al geprobeerd de disks aan een pci controller te hangen en via software raid te testen ?
verder is het idd wel vreemd dat je master/slave opstelling het zo goed doet maar aan de andere kant, het zijn maar cd drives, en die spreek je toch niet vaak aan...

[Oet]

Ja, via die Promise Ultra133 was ook niet anders mogelijk, maar ik heb met alle 3 opgenoemde pci kaarten software raid getest en dat bleef meestal zo rond de 60MB/s steken!

Btw: erg offtopic, maar hoe kan ik er nou voor zorgen dat ik via samba ook het maximum van mijn schijf kan halen? haal nu een 15-16MB/s (alles via gigabit 3com) en zou graag wat meer halen..

[nzyme]

samba heeft iets met SOCKET options ofzo.... weet niet pcies hoe dat zat. Verder was samba vroeger altijd traaaaag. Advies was altijd gebruik ftp of nfs... Maar hoe het nu is met samba, geen id

[Oet]

Ja ik heb de send en recieve buffers al aangepast, tenminste die waren nog 8192 maar nu heb ik ze op default gezet aangezien dat betere performance geeft, kopieren naar de machine toe (upload) gaat met een +- 21MB/s nu (ben nog firefox aan het compilen dus zal uiteindelijk wel ietsjes sneller worden nog) en downloaden steekt op ~14MB/s, vreemd eigelijk...

BTW: Nu denk ik toch echt dat het aan mijn moederbord/chipset/pcibus ligt dat die pci-ide-controller kaartjes de snelheid niet halen, idividueel halen de schijven namelijk wel gewoon 55MB/s maar samen in raid-0 niet meer dan 60MB/s.. Nou heeft iemand hier al eerder iets gemeld over een pci latency bug in het chipset van dit bord, maar helaas is hier geen patch voor een linux systeem te vinden, nou had ik wel ergens gelezen dat dat vanaf een bepaalde kernel versie ingebakken zat maar kan het zijn dat dat speciaal geactiveerd moet worden? Of kan ik in de BIOS misschien de pci latency verhogen van 32 naar 64 oid??
Iemand die hier ervaring mee heeft?

[ Voor 48% gewijzigd door Oet op 09-08-2006 13:36 ]

[Kirpeknots]

Hier wat vergelijkingsmateriaal.

/dev/hda intel i855GME (ich4) chipset met Hitachi 7k250 250gb 7200tpm
/dev/sda promise sata150 (software mirror) met 2X Hitachi 7K400 400Gb 7200tpm

Distro: OpenSuSe 10.1

hdparm -Tt /dev/hda

/dev/hda:
Timing cached reads: 2152 MB in 2.00 seconds = 1075.18 MB/sec
Timing buffered disk reads: 72 MB in 3.30 seconds = 21.80 MB/sec
Server:/dev # hdparm -Tt /dev/sda

hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads: 2164 MB in 2.00 seconds = 1080.96 MB/sec
Timing buffered disk reads: 176 MB in 3.03 seconds = 58.15 MB/sec

Settings

hdparm /dev/hda

/dev/hda:
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 1024 (on)
geometry = 30401/255/63, sectors = 488397168, start = 0

hdparm /dev/sda/

/dev/sda:
IO_support = 0 (default 16-bit)
HDIO_GET_UNMASKINTR failed: Inappropriate ioctl for device
HDIO_GET_DMA failed: Inappropriate ioctl for device
HDIO_GET_KEEPSETTINGS failed: Inappropriate ioctl for device
readonly = 0 (off)
readahead = 1024 (on)
geometry = 48641/255/63, sectors = 781422768, start = 0


Ik vind jouw waarden helemaal niet zo gek eigenlijk. En mijn onboard ich4 presteerd helemaal bagger. Schijf hangt er als primary master aan zonder andere meuk aan deze bus. Misschien moet ik ook nog wat met de hdparm parameters spelen.

[ Voor 46% gewijzigd door Kirpeknots op 10-08-2006 07:48 ]

[_JGC_]

Wat denk je van hdparm -u1d1c1m16k1 /dev/hda om maar eens mee te beginnen, ik zie dat je nog 16bit IO doet. Voor dat SATA ding kan je dat helaas niet instellen.

Wat betreft performance met PCI controlers: dit is niet alleen op VIA borden zo. Je deelt een slome PCI bus van bruto 133MB/s met allerlei andere apparaten, uiteindelijk blijft er netto 100MB/s van over. Deze 100MB/s deel je met dingen als je geluidskaart, netwerkkaart, TV-kaart en al dat andere wat op de PCI bus zit. De onboard VIA IDE controler zit niet aan de PCI-bus, maar zit gewoon rechtstreeks in de southbridge van de chipset verbonden met de rest van het systeem. De southbridge heeft over het algemeen een koppeling met je northbridge die varieert van 266MB/s tot 1,2GB/s, wat iig een stuk sneller is dan je slome PCI bus.
De enige redelijk "recente" chipset die ik ken die nog de PCI bus gebruikte om northbridge en southbridge te koppelen was de intel i440BX.

[Kirpeknots]

hdparm -u1d1c1m16k1 /dev/hda

/dev/hda:
setting 32-bit IO_support flag to 1
setting multcount to 16
setting unmaskirq to 1 (on)
setting using_dma to 1 (on)
setting keep_settings to 1 (on)
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 1 (on)

hdparm -Tt /dev/hda

/dev/hda:
Timing cached reads: 2120 MB in 2.00 seconds = 1059.72 MB/sec
Timing buffered disk reads: 72 MB in 3.27 seconds = 22.01 MB/sec

Hmm. Dat maakt helaas niet heel veel uit. Heeft het zin om wat met PCI latency en zo te doen? Of is dit niet nodig bij een intel i855GME?

/dev/hda is overigens EXT3
/dev/sda is reiserfs

[_JGC_]

PCI latency heeft niet veel effect op je southbridge. Als ik deze waarden zie denk ik eerder aan dingen als stervende disks of brakke bekabeling. Heb zelf een Maxtor gehad die het nog superbetrouwbaar deed, maar wel op 3MB/s... kon je je handen ook aan branden overigens .

Neem eens een kijkje in dmesg voor evt meldingen.

[Kirpeknots]

dmesg geeft geen meldingen voor hda. Wel voor sdb overigens maar dat staat hier los van.

Ik ga vanavond ff een ander kabeltje aan die schijf hangen. Een 7k250 zou niet echt langzamer dan een 7k400 moeten zijn. Zeker niet als die 7k250 aan de ich4 hangt en de 7k400 aan zon brakke promise.

[Oet]

Ik weet niet of het iets helpt, maar ik vind de readahead best hoog voor jou schijven, bij mij issie in redhat7.3 standaard 8, in fedora core 5 issie 256, maar 1024 is wel een groot verschil, je zou eens kunnen proberen om die aan te passen? Verder is het idd maar vreemd dat het zo zwakjes presteerd. Toch niet zo dat er nog een slave device aan dezelfde kabel hangt die de boel misschien ophoud?

[_JGC_]

Die cached read is gewoon de snelheid waarmee linux je geheugen kan uitlezen, met een beetje flinke DDR dualchannel geheugensetup rag je daar zo 1000MB/s doorheen. Ik zie een oude Mac G4 466 met SDRAM zowat een Athlon XP 2600+ met DDR400 geheugen voorbij vliegen op die test, zegt niet veel over de performance van je disk.

[Kirpeknots]

Grmbl... kabeltje vervangen. Schijf in andere positie gehangen. Reboot.... Nog steeds traag.

Er hangen geen andere devices aan het IDE kabeltje btw.

[Oet]

Doe eens een hdparm -i /dev/hda en post de output eens?

[Kirpeknots]

_JGC_ schreef op donderdag 10 augustus 2006 @ 10:33:
PCI latency heeft niet veel effect op je southbridge. Als ik deze waarden zie denk ik eerder aan dingen als stervende disks of brakke bekabeling. Heb zelf een Maxtor gehad die het nog superbetrouwbaar deed, maar wel op 3MB/s... kon je je handen ook aan branden overigens .

Neem eens een kijkje in dmesg voor evt meldingen.

En wat is er vandaag gebeurd? De 7K250 died on me! Gelijk RMA aangevraagd. Ding gaat morgen op de post. Ik ben nu het OS aan het installeren op een 4.3Gb Maxtor Diamondmax 3400 90430D3 (uit een deskpro EP gesloopt). UDMA33 en 5400tpm w000t w00t. Ik zal zo ff de uber hdparm stats van dit dingetje posten.

[Kirpeknots]

Roflol

hdparm -Tt /dev/hda

/dev/hda:
Timing cached reads: 2028 MB in 2.00 seconds = 1012.68 MB/sec
Timing buffered disk reads: 38 MB in 3.08 seconds = 12.35 MB/sec

Dat is zo'n maxtor schijfje die standaard in de eerste deskpro EP's zat. Ik moet het hier maar ff mee doen totdat ik mijn 7k250 terug heb.

[Oet]

Tja, je kunt niet alles hebben hé

Om zeker te zijn van je settings kun je altijd hdparm -i <device> doen, hier zie je dan een mooie opsomming van de huidige settings van de drive en de settings die de drive aan zou moeten kunnen volgens de detectie. Bij de udma settings staat er een * voor de setting die gebruikt wordt: bv *udma6 ofzo.

[Oet]

Om nog maar even een soort van afsluiter voor het topic te maken:

VIA chipset, PCI performance == Ultiem brak!

Ik heb nu een cheap ASRock NForce2 moederbord gekocht en dat loopt als een trein, geheugen lekker op dual channel wat dus ook al 2x zo snel is en met een simpele Promise UltraTrak 133tx2 (ide controller) de 2 schijven in software RAID-0 gezet, loopt als een tiet: 112MB/s :D:D

Dus doei via meuk en daag Software raid controllers (hoewel de meeste software raid controllers in nieuwere distro's via dmraid goed ondersteund worden, ook de promise)

Voila, misschien heeft iemand er nog wat aan

[igmar]

Oet schreef op vrijdag 04 augustus 2006 @ 00:21:
Nu is mijn grote vraag: waarom is het niet zo snel?? De schijven zijn beide aangesloten met een aparte ata-133 kabel aan de poorten van de promise, beide zijn op master gejumperd, beide staan als UDMA-5 in de promise bios weergegeven.

Kan iemand me misschien helpen hierbij?

Omdat je een antieke kernel draait met een extreem brakke controller ? Koop een fatsoenlijke (echte) RAID controller, daarmee is je probleem in een keer verholpen.