Gå til innhold

Areca 1880ix-24 Battleship! 2GB/s + 140k+ IOPS


Nizzen

Anbefalte innlegg

Videoannonse
Annonse

Haha, jeg har omtrent like gode les tall fra SB850 med 4R0 C300 64GB! De tar meg med 100-150MB/s maks peak read, men jeg knuser de på IOPS.

Jeg passerte 1GB/s les med 3R0... Og klarte ca 100K IOPS med 2R0.

 

EDIT: de fikk grei sekvensiell les ser det ut som, nizzen fikk omtrent samme med 4R0 av 128GB versjonen, men han var rett under 100K IOPS, mens de stoppet rundt 60-70K. Han hadde også mye bedre skriv tall, kanskje pga. 4GB RAM?

Endret av GullLars
Lenke til kommentar

4x Samsung f4 2tb raid-0

 

 

 

 

Greater Two TB Volume Support : 64bit LBA

 

 

 

post-42975-0-37354100-1290955295_thumb.png

 

 

 

 

Greater Two TB Volume Support: 4k Block

 

post-42975-0-02695900-1290955664_thumb.png

 

 

 

 

 

Raid-5 les

 

post-42975-0-98080900-1291625040_thumb.png

 

 

 

 

 

 

 

 

 

 

Skrivehastighet med disse 4 diskene i raid-5 er litt over 300 MB/s. Tok en manuell test med å kopiere ca 6gb med 100Mb filer fra ssd arrayet mitt til raid-5 arrayet. :thumbup:  

 

 

 

 

Får ikkje kjørt noen særlige benchmarks siden write benchmarks har en tendens til å skrive over det som ligger der :p

 

 

Endret av Nizzen
Lenke til kommentar

Har Areca ARC-1880IX-12 med 8 x Hitachi Deskstar 7K2000i raid 6.

 

Gjorde for gøy en test med 4GB i filstørrelse:

post-79843-0-26255800-1290598794_thumb.png

 

Det der er skuffende resultater synes nå jeg. Jeg har et på papiret tregere 8 disker array bestående av Seagate 2TB LP (5900rpm) som kjører Linux software RAID6 på en integrert HBA (tilsvarende LSI 9211-8i) og dette oppnår 704MB/s les og 384MB/s skriv på en 16GB stor fil (har 8GB ECC RAM i filserveren) i bonnie++

 

Om jeg drar en "real life" sekvensiell test med dd (linux) så får jeg følgende tall på en 25GB stor fil (sammen med sync for å fjerne mest mulig effekt av RAM cache):

450 MB/s skriving, 568 MB/s lesing

 

Har dere noen sammenlignbare CLI-tester dere kjører på Linux oppsettene? Jeg er spesielt interessert i å sammenligne RAID6 ytelse mellom Linux software RAID og 1880-kontrolleren.

Endret av marsboer
Lenke til kommentar

Raid-6 Write

 

post-42975-0-80600400-1291625858_thumb.png

 

Raid-6 Read

 

post-42975-0-56212000-1291625859_thumb.png

 

 

 

 

Har ikkje noe særlig å sammenlikne med linuxserveren min da jeg bare har Adaptec 31205 og noen andre HBA der som software raid med EXT4 filsystem. Er vel bare ca 200 Mb write med 6 stk 500gb samsung f1 som jeg kan huske. Dog nå er det lenge siden jeg har sjekka siden den bare surrer og går og er jo bare en filserver og ikkje en benchemaskin.

 

 

 

Real life kopiering:

 

 

 

 

post-42975-0-28575100-1291626183_thumb.png

 

 

Endret av Nizzen
Lenke til kommentar

Basert på de tallene der er det i hvertfall helt klart at RAID6 ytelsen er på topp og at det ikke er noen åpenbar skriveflaskehals tilstede i et 8 diskers array i hvertfall.

 

Man er forøvrig helt avhengig av å tune parameteren stripe_cache_size for å få god skriveytelse med Linux mdadm.

 

Hos meg gir 8192 best resultat:

 

echo 8192 > /sys/block/md0/md/stripe_cache_size

 

(256 er default hos meg)

 

Jeg får 3-doblet skriveytelse bare ved å gi Linux litt mer RAM å håndtere stripes på (dette er ikke det samme som filsystem cache). I praksis gir dette Linux 32MB stripe cache per disk i arrayet (8192x4k). stripe_cache er der all manipulasjon av stripes skjer, dvs f.eks utregning av paritet. Jeg får mye større effekt av denne parameteren på filserveren hjemme med en fire kjerners X3430 CPU enn jeg gjør på min gamle A64 3000+. Sannsynligvis fordi CPUen slipper å vente på nytt innhold i stripe_cache om cachen inneholder mer data.

Endret av marsboer
Lenke til kommentar

Basert på de tallene der er det i hvertfall helt klart at RAID6 ytelsen er på topp og at det ikke er noen åpenbar skriveflaskehals tilstede i et 8 diskers array i hvertfall.

 

Man er forøvrig helt avhengig av å tune parameteren stripe_cache_size for å få god skriveytelse med Linux mdadm.

 

Hos meg gir 8192 best resultat:

 

echo 8192 > /sys/block/md0/md/stripe_cache_size

 

Jeg får 3-doblet skriveytelse bare ved å gi Linux litt mer RAM å håndtere stripes på (dette er ikke det samme som filsystem cache). I praksis gir dette Linux 32MB stripe cache per disk i arrayet (8192x4k)

 

Flott å se erfaringene dine med soft linuxraid  :thumbup: Selv er jeg ganske noob med linux eller ubuntu server som jeg bruker. Har noen spillservere, VT, TS og noe anna dill gående på serveren. I tillegg til at det er filserver. Synes det er mest stress med å mounte disker og legge de inn i "boot". Jaja, fikk det til med hjelp  :whistle:

Lenke til kommentar
  • 2 uker senere...

Nice :)

 

Har du fått sjekket 3TB disker på noen av Areca kontrollerene?

 

Litt har de jo fixet på, ikke alt som dreier seg om 1880 (siden juni i år)

 

2010-6-1

1 Add ThreadDelayMs to improve GUI speed of PCI host adapter

2010-6-4

1 Tune ARC1880 performance

2010-6-28

1 Fix ARC1880:1st level attached device's RED LED not on if device removed

2010-6-29

1 Enclosure.c:Add space between E%d and %s

2010-7-2

1 ARC1880:fix zoning problem

2010-7-5

1 ARC1880/1680:Add 6G expander zoning support

2010-7-20

1 Fix TEST_ZONING with log

2 Fix enclousre power off with raidset is initializing or rebuilding...

2010-7-27

1 ARC1880:modify geteon delay stepping,

2010-7-28

1 Add support for mail greet pause, use different tcp_send timeout value

2010-7-29

1 Fix raidset activate problem for rebuilding percentage

2010-7-30

1 Add display of Error Recovery Control Status of SATA hdd

2010-8-19

1 Modify pure SATA's NEW_83782D_HWMON SNMP

2010-8-20

1 Patch ARC1880 bootcode for PLI Phase6/7

2010-8-30

1 Add CheckEesaBlackList to exclude some HDD with error recovery control

problem

2010-9-2

1 Add SUPPORT for ARC1880IXL-8

2010-9-9

1 ARC1880:fix return from BBM with 4G sdram

2010-9-16

1 Fix when many volumes is created for RAID6 and failed two drive, some volume

may still NEED_REBUILD and REBUILDING

2010-9-17

1 Fix SAS devices add/remove routine is invoked before SasDeviceInit is called

2010-10-6

1 Add support for ARC1880LP

2010-10-7

1 Modify GetResource and PostResource

2010-10-15

1 Fix write through problem for IOP348 based HBA

(0) ARC1680/1212/1682/SPT1680/WTN1212

(A) Only ARC1680 reveal the problem

(B) The problme occurred if SUPPORT_PERSISTENT_RESERVE is defined

© The problem is the STACK overflow if write through

(D) Change stack size for All IOP348 models

2010-10-20

1 Fix reportlun command to exclude FAILED and FOREGROUND init volume

2010-10-21

1 ARC1680:Add LARGE_DEV_LBA support

2010-10-22

1 SAS2 target mode:ARC8040/8066/8366

2010-10-28

1 Fix MRVL5182 based more than 2TB hdd support

2010-11-3

1 ARC1682:Add over 2TB hdd support

2010-11-5

1 ARC1680:remove VerifyDrive to support seagate SED drive

2010-11-25

1 Add NO_UPS_STATUS for enclosure.c to remove ENC without UPS status

2 Patch supermicro SES problem, unsupported power state report value 6

2010-11-30

1 Add rename raidset name support

2 Port ARC1880 subsystem

4 Add NEW_MAIL_ALERT_CONFIG to support different mail alert config for

different mail account

2010-12-2

0 V1.49 20101202

1 All PCI/E HBA models (except 1880)

2010-12-10

1 V1.49 20101210

2 ARC1880

Lenke til kommentar
  • 1 måned senere...
  • 3 måneder senere...

Hei og hopp.

 

Som nevnt i SSD diskusjonstråden så har jeg smekka til med 1880ix-12 med 4GB Cache og batteripakke. +1stk Vertex 3 Max IOPS og 1stk Intel 510, samt et WDRE4 1+0 raid.

 

Av bildet her så vises det at jeg ikke er i nærheten av målingene til Nizzen her ....

 

889326.jpeg

 

889952.jpeg

 

 

 

Har aktivert Write back og read ahead cache, samt NCQ.

 

To stk SSD står som single (i praksis raid 0 pr ssd) på en kanal og 4stk RE4 som står i Raid 1+0 på en annen kanal.

 

 

Bruker pr nå siste ofisielle firmware, men hører det finnes en uofisiell (kan noen paste link?). Men det kan da ikke være dèt som gjør at resultatene mine er så way off?

 

Noen idèer?

Endret av JKJK
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...