Verständnisfrage zu Raid10, SAS-auf-SATA, Geschwindigkeit

[Khorneflakes]

Diese alten Controller hatten noch keinen HBA-Modus (und auch bei neuen ist das nicht zwingend ein echter HBA-Modus). Andersrum gab es das öfter, für HBAs gabs IR-Firmware mit Raidleveln ohne Parität.

Wenn du größere Zahlen sehen willst, dann musst du mehr und/oder schnellere Laufwerke anschließen und/oder ein Raid 0 machen. Oder eine Kombination aus allem.

 

[Humptidumpti]

RAID10 kann genauso schnell schreiben, wie ein RAID1, aber doppelt so schnell lesen.

Das ist theoretisch möglich, aber in der Praxis konnte mir noch keiner einen Controller zeigen der neuer ist als der SCSI Standard und das auch so implementiert hat.

Und der Controller hat einen SFF8087 Anschluss der 4x 3,0 Gbit/s bereitstellen kann. Wenn man jetzt ein Raid Array und Platten nutzt nutzt die/welche an sich die Datenübertragung limitieren kann man hier auch keine Maxima testen. Versteht sich von selbst.....

 

[kieleich]

probiers mal mit ein anderer benchmark oder lese parallel zwei verschiedene partitionen/dateien. dd ist zum beurteilen der raid performanz zumindest bei software raid nicht aussagekräftig. da die zweite seite zum lesen erst eingespannt wird wenn mehrer prozesse parallel arbeiten, für einen linearen lesevorgang wird der mirror nicht mit eingebunden (beide seiten schreiben, eine seite liest)

 

[wern001]

Dafür, dass du so belehrend auftrittst, kennst du dich aber selbst auch nicht richtig aus..
RAID10 kann genauso schnell schreiben, wie ein RAID1, aber doppelt so schnell lesen.

So ein unfug
Ein Raid 10 schreibt deutlich schneller als ein Raid1. Wenn optimal dann genauso schnell wie ein Raid0 mit 2 Platten

 

[Mr. Smith]

Es sind pro Port 3 Gb/s. Es sind 4 Ports. So funktioniert SAS. Sieht man auch schön im Datasheet.

Ja und nochmals: Das ist die theoretische Bandbreite des bzw. der Port(s).

Diese Datenmenge muss aber aber vom DDR2-RAM, dem CPU-Complex und dem SAS-Core auch verarbeitet werden können. Irgendwas ist immer der Flaschenhals. Und lt. Datenblatt ist das hier eindeutig der 1078er Controller mit SAS1 und x4 PHY's bei maximal 520 MB/s Bandbreite.

Es ist völlig egal, dass die Ports in Summe theoretisch 12 Gb/s hergeben würden.
Das wären 1500 MB/s und somit ungefähr 3x schneller, als das was der Controller mit 4 Platten mitmacht.

 

[Piktogramm]

zum RAID-Cache: 128MB sind nicht sonderlich viel, ist halt ech auch ein altes Ding, dafür kostenlos

"kostenlos", wenn die Betriebskosten ignoriert werden. Diese alten SaS-Controller saufen gern mal derart viel Strom, dass sich damit ein modernes HBA-Kärtchen mit ASMedia-Chip nach ~2..3Jahren gerechnet hat.
Ganz abgesehen davon, Softwareraid ob nun mit mdadm oder ZFS schlägt normalerweilse alle Raidcontroller.

da die zweite seite zum lesen erst eingespannt wird wenn mehrer prozesse parallel arbeiten

Ein Raidcontroller dürfte von Prozessen auf Betriebssystemebene gar nichts wissen.

#######################

Bei deinen Tests, wenn du dd auf die Partition des Dateisystems loslässt, dann kommt da einmal der Overhead vom Dateisystem drauf + Fragmentierung und du weißt auch nicht, wo die Datei auf den Platten liegt. Auch wird dir directIO etwas die Performance versauen.
Das was das Gnome Disk Utility als Graph zeichnet erscheint hingegen halbwegs realistisch zu sein, wenn es Performance bei sequentiellen Zugriff ohne Konkurrenz auf das Raid angeht.

 

[kieleich]

Ein Raidcontroller dürfte von Prozessen auf Betriebssystemebene gar nichts wissen.

das ist doch egal. es geht mehr ums zugriffsmuster

wenn beide seiten springen müssen (1MiB hüben, 1MiB drüben lesen, 1MiB hüben, 1MiB drüben überspringen, oder eben 64K, oder ...) dann kannst das machen aber bist am Ende doch nicht schneller gewesen, als es nur von einer Seite zu lesen. Weil HDDs nicht gut springen können

wenn die Zugriffe nicht linear sondern chaotisch sind dann macht es schon eher Sinn. die eine Hälfte auf der einen Seite die andere auf der anderen Seite abzuklappern, um IOPS / Geschwindigkeit, auszunutzen

wie es im hardware raid implementiert ist weiss ich nicht. so oder so ist dd nicht unbedingt geeignet als benchmark

 

[Piktogramm]

@kieleich
Wenn ein Raidcontroller gescheit Zugriffe verteilt, dann ist bei 512Byte bzw. 4kB Sektoren von HDDs ein Zugriff von 1MB groß genug um Zugriffe sinnvoll zu verteilen. Vorausgesetz der Controller verteilt Zugriffe überhaupt.
Und der TE hat bs=4M gesetzt, also sind es Zugriffe a 4MB (was die Leserrate zusammen mit directIO etwas einschränken wird)

 

[Khorneflakes]

Es ist völlig egal, dass die Ports in Summe theoretisch 12 Gb/s hergeben würden.

Erst war das garnicht möglich. Jetzt ist es offenbar theoretisch möglich, aber egal? Was du da jetzt erzählst ist nicht konsistent mit dem was du vorher erzählt hast. Erst war 375 MB/s das Limit, jetzt sind es 520? Was stimmt denn nun? Und magst du dann jetzt aufhören irgendwelche Dinge zu erfinden?

Deine Interpretation dieser Tabelle, die du weder vollständig zitiert noch verlinkt hast, sodass Kontext fehlt, ist daher auch nur schwer zu beurteilen und du ignorierst bereits Informationen, die trotz deines selektiven Ausschnitts sichtbar sind.

Warum steht da PCIe Gen 2 in der Tabelle, wenn es vermeintlich um den SAS1078 geht? Warum beziehst du dich auf 4 PHY? Die Tabelle geht ja noch weiter. Es wurde ja bereits vorgeschlagen, dass man für mehr Bandbreite auch immer mehr Devices braucht. An dem "Limit" von 520 MB/s für 4 PHY, sofern es wirklich eins sein sollte, ist der TE ja noch garnicht. Und LSI hat dem Chip nicht umsonst ein PCIe x8 Interface gegeben.

Wenn die Frage lauten soll, ob die kombinierten 12 Gb/s wirklich möglich sind, dann lautet die Antwort darauf ja.

 

[Karl_mags]

So, ich habe nun 2 SSDs an den controller angeschlossen, sonst nix. Ein VD mit Raid0 (Striping) angelegt und das ganze mit ext4 (default) eingebunden. Hier einige Testwerte, die ich nicht ganz sicher interpretieren kann. Vllt. hilfts einigen Parteien, ihre Differenzen anzugleichen?

❯ sudo megacli -LDInfo -L0 -a0                                 
Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :
RAID Level          : Primary-0, Secondary-0, RAID Level Qualifier-0
Size                : 236.554 GB
Sector Size         : 512
Parity Size         : 0
State               : Optimal
Strip Size          : 64 KB
Number Of Drives    : 2
Span Depth          : 1
Default Cache Policy: WriteThrough, ReadAdaptive, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAdaptive, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy   : Disks Default
Encryption Type     : None
Is VD Cached: No


❯ sudo hdparm -tT /dev/sda1
/dev/sda1:
 Timing cached reads:   27952 MB in  1.99 seconds = 14052.73 MB/sec
 Timing buffered disk reads: 1558 MB in  3.00 seconds = 519.12 MB/sec
 

## Schreibtest direct
❯ sudo dd if=/dev/zero of=/media/user/ssdraid/testssd bs=2G count=1 oflag=direct
0+1 Datensätze ein
0+1 Datensätze aus
2147479552 Bytes (2,1 GB, 2,0 GiB) kopiert, 5,2803 s, 407 MB/s


## Schreibtest dsync
❯ sudo dd if=/dev/zero of=/media/user/ssdraid/testssd bs=2G count=1 oflag=dsync
0+1 Datensätze ein
0+1 Datensätze aus
2147479552 Bytes (2,1 GB, 2,0 GiB) kopiert, 4,89278 s, 439 MB/s


## Lesetest direct 4M
❯ dd if=/media/user/ssdraid/testssd of=/dev/null bs=4M iflag=direct
511+1 Datensätze ein
511+1 Datensätze aus
2147479552 Bytes (2,1 GB, 2,0 GiB) kopiert, 4,02035 s, 534 MB/s

## Lesetest direct 4K
❯ dd if=/media/user/ssdraid/testssd of=/dev/null bs=4K iflag=direct
524287+0 Datensätze ein
524287+0 Datensätze aus
2147479552 Bytes (2,1 GB, 2,0 GiB) kopiert, 51,8951 s, 41,4 MB/s


## fio random 75/25 (r/w)
❯ sudo fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --bs=4k --iodepth=64 --readwrite=randrw --rwmixread=75 --size=4G --filename=/media/user/ssdraid/fiotest
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.28
Starting 1 process
test: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=64.7MiB/s,w=21.1MiB/s][r=16.6k,w=5403 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=5398: Mon Feb  3 17:11:34 2025
  read: IOPS=15.0k, BW=58.5MiB/s (61.3MB/s)(3070MiB/52518msec)
   bw (  KiB/s): min=29248, max=67336, per=99.91%, avg=59805.77, stdev=8714.07, samples=104
   iops        : min= 7312, max=16834, avg=14951.46, stdev=2178.52, samples=104
  write: IOPS=5001, BW=19.5MiB/s (20.5MB/s)(1026MiB/52518msec); 0 zone resets
   bw (  KiB/s): min=10120, max=22040, per=99.89%, avg=19984.23, stdev=2928.08, samples=104
   iops        : min= 2530, max= 5510, avg=4996.06, stdev=732.02, samples=104
  cpu          : usr=8.54%, sys=36.56%, ctx=92017, majf=0, minf=10
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=785920,262656,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=58.5MiB/s (61.3MB/s), 58.5MiB/s-58.5MiB/s (61.3MB/s-61.3MB/s), io=3070MiB (3219MB), run=52518-52518msec
  WRITE: bw=19.5MiB/s (20.5MB/s), 19.5MiB/s-19.5MiB/s (20.5MB/s-20.5MB/s), io=1026MiB (1076MB), run=52518-52518msec

Disk stats (read/write):
  sda: ios=783792/261976, merge=0/10, ticks=2076629/830445, in_queue=2907074, util=68.64%
 
 
## fio direct 75/25 (r/w)
❯ sudo fio --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --bs=4k --iodepth=64 --readwrite=rw --rwmixread=75 --size=4G --filename=/media/user/ssdraid/fiotest
test: (g=0): rw=rw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.28
Starting 1 process
^Cbs: 1 (f=1): [M(1)][82.6%][r=132MiB/s,w=44.7MiB/s][r=33.8k,w=11.4k IOPS][eta 00m:04s]
fio: terminating on signal 2

test: (groupid=0, jobs=1): err= 0: pid=5461: Mon Feb  3 17:12:47 2025
  read: IOPS=33.8k, BW=132MiB/s (138MB/s)(2534MiB/19187msec)
   bw (  KiB/s): min=132024, max=137264, per=100.00%, avg=135318.95, stdev=987.36, samples=38
   iops        : min=33006, max=34316, avg=33829.84, stdev=246.84, samples=38
  write: IOPS=11.3k, BW=44.2MiB/s (46.4MB/s)(849MiB/19187msec); 0 zone resets
   bw (  KiB/s): min=44376, max=46464, per=100.00%, avg=45339.79, stdev=446.97, samples=38
   iops        : min=11094, max=11616, avg=11334.95, stdev=111.74, samples=38
  cpu          : usr=13.04%, sys=60.40%, ctx=36094, majf=0, minf=9
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=648720,217313,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=132MiB/s (138MB/s), 132MiB/s-132MiB/s (138MB/s-138MB/s), io=2534MiB (2657MB), run=19187-19187msec
  WRITE: bw=44.2MiB/s (46.4MB/s), 44.2MiB/s-44.2MiB/s (46.4MB/s-46.4MB/s), io=849MiB (890MB), run=19187-19187msec

Disk stats (read/write):
  sda: ios=646619/216609, merge=578/210, ticks=759573/330841, in_queue=1090414, util=46.87%
 
 
## fio direct 100/0 (r/w)
❯ sudo fio --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --bs=4k --iodepth=64 --readwrite=rw --rwmixread=100 --size=4G --filename=/media/user/ssdraid/fiotest
test: (g=0): rw=rw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.28
Starting 1 process
Jobs: 1 (f=1): [R(1)][100.0%][r=235MiB/s][r=60.2k IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=5481: Mon Feb  3 17:13:14 2025
  read: IOPS=60.3k, BW=235MiB/s (247MB/s)(4096MiB/17403msec)
   bw (  KiB/s): min=236007, max=244528, per=100.00%, avg=241224.44, stdev=1448.41, samples=34
   iops        : min=59001, max=61132, avg=60306.15, stdev=362.16, samples=34
  cpu          : usr=12.95%, sys=62.25%, ctx=38703, majf=0, minf=8
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=1048576,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=235MiB/s (247MB/s), 235MiB/s-235MiB/s (247MB/s-247MB/s), io=4096MiB (4295MB), run=17403-17403msec

Disk stats (read/write):
  sda: ios=1047541/2, merge=392/1, ticks=996453/1, in_queue=996455, util=49.64%
 

## fio seq read default
❯ sudo fio --ioengine=libaio --name=test --bs=4k --readwrite=read --size=4G --filename=/media/user/ssdraid/fiotest
test: (g=0): rw=read, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
fio-3.28
Starting 1 process
Jobs: 1 (f=1): [R(1)][100.0%][r=503MiB/s][r=129k IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=6861: Mon Feb  3 17:33:18 2025
  read: IOPS=127k, BW=496MiB/s (520MB/s)(4096MiB/8262msec)
    slat (nsec): min=1229, max=4312.8k, avg=6362.95, stdev=36731.23
    clat (nsec): min=529, max=111810, avg=834.14, stdev=829.83
     lat (nsec): min=1849, max=4319.3k, avg=7299.00, stdev=37088.83
    clat percentiles (nsec):
     |  1.00th=[  556],  5.00th=[  572], 10.00th=[  572], 20.00th=[  580],
     | 30.00th=[  588], 40.00th=[  588], 50.00th=[  596], 60.00th=[  604],
     | 70.00th=[  620], 80.00th=[  932], 90.00th=[ 1480], 95.00th=[ 1544],
     | 99.00th=[ 3024], 99.50th=[ 5024], 99.90th=[11328], 99.95th=[13504],
     | 99.99th=[15552]
   bw (  KiB/s): min=469832, max=516176, per=100.00%, avg=508007.00, stdev=10673.01, samples=16
   iops        : min=117458, max=129044, avg=127001.75, stdev=2668.25, samples=16
  lat (nsec)   : 750=74.10%, 1000=10.67%
  lat (usec)   : 2=12.24%, 4=2.42%, 10=0.22%, 20=0.34%, 50=0.01%
  lat (usec)   : 100=0.01%, 250=0.01%
  cpu          : usr=17.96%, sys=39.06%, ctx=15854, majf=0, minf=12
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=1048576,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=496MiB/s (520MB/s), 496MiB/s-496MiB/s (520MB/s-520MB/s), io=4096MiB (4295MB), run=8262-8262msec

Disk stats (read/write):
  sda: ios=16160/0, merge=0/0, ticks=11750/0, in_queue=11750, util=46.05%


❯ sudo rsync --progress Schreibtisch/testfile4gb /media/user/ssdraid2/testfile4gb
  4.294.967.296 100%  139,74MB/s    0:00:29 (xfr#1, to-chk=0/1)
 
 
❯ sudo rsync --progress /media/user/testfile4gb Schreibtisch/copy/testfile4gb
  4.294.967.296 100%  130,04MB/s    0:00:31 (xfr#1, to-chk=0/1)

Gnome Disks mit 5x1GB lese-/schreibtest

 

[Humptidumpti]

@Mr. Smith
Keine Ahnung was für eine Tabelle du da hervorgekramt hast und wie du die verstehst. Habe gerade meinen alten IBM Serve Raid MR10i LSI 1078 mal rausgeholt und 4 Festplatten dran angeschlossen. Funny enough steht sogar IBM 8708E drauf.


Das sind deutlich mehr als 520MB/s. So ziemleich genau das was 4 olle 3TB Sata Platten im Raid 0 machen. Benche ich den Controllercache sieht man schön das Limit vom Controller.

 

[gaym0r]

@Mr. Smith
Danke, hast du ne Quelle für das Bild? Würde mich da gerne weiter belesen.

 

[Mr. Smith]

Erst war 375 MB/s das Limit, jetzt sind es 520? Was stimmt denn nun? Und magst du dann jetzt aufhören irgendwelche Dinge zu erfinden?

Lesen und verstehen, dann meckern.
375 MB/s beziehen sich auf die im ersten Post erwähnten"Up to 3Gb/s per Port"... was einfach umgerechnet genau 375 MB/s sind. Wüsste jetzt nicht, was daran so schwer zu verstehen ist/war.

Und die 520MB/s beziehen sich auf das Bottleneck des Controllers als Ganzes...
Hat jetzt ja nichts mehr mit den einzelnen Ports zu tun.

Deine Interpretation dieser Tabelle, die du weder vollständig zitiert noch verlinkt hast, sodass Kontext fehlt, ist daher auch nur schwer zu beurteilen und du ignorierst bereits Informationen, die trotz deines selektiven Ausschnitts sichtbar sind.

Was ignoriere ich denn bitte? Klär mich auf.

Warum steht da PCIe Gen 2 in der Tabelle, wenn es vermeintlich um den SAS1078 geht?

Weil es im gleichen Dokument auch noch um den 2108 ROC geht (PCIe Gen2) und den 2208 ROC (PCIe Gen3). Da es hier weder um den einen, noch um den anderen Controller geht, habe ich mir erlaubt, einen Ausschnitt zu screenshotten, auf dem genau das steht, um das es hier geht: 1078 ROC mit 4 HDD's.

Warum beziehst du dich auf 4 PHY? Die Tabelle geht ja noch weiter.

Weil der TE, wie in Post #1 erwähnt genau 4 Drives angeschlossen hat
(bzw. hatte. Nun sind es ja inzwischen 2 mirrored SSD's)

Es wurde ja bereits vorgeschlagen, dass man für mehr Bandbreite auch immer mehr Devices braucht.

Die aber in Post #1 nicht das Thema waren und daher ist diese "hätte, wäre, könnte"-Diskussion auch nicht zielführend. Die Frage war, warum die Brandbreite mit 4 HDD's so aussieht und nicht, ob sie ggf. noch höher sein könnte, wenn man mehr Drives einsetzt...

Wenn die Frage lauten soll, ob die kombinierten 12 Gb/s wirklich möglich sind, dann lautet die Antwort darauf ja.

Ist das so?!
Dann lies doch den Auszug vom TE in Post #30 durch...
2 SSD in RAID 0 und trotzdem steht der Read bei ~520 MB/s. Schon komisch,oder?

## Lesetest direct 4M
2147479552 Bytes (2,1 GB, 2,0 GiB) kopiert, 4,02035 s, 534 MB/s

---

bw ( KiB/s): min=469832, max=516176, per=100.00%, avg=508007.00, stdev=10673.01, samples=16 (aka 528 MB/s)

---

Run status group 0 (all jobs):
READ: bw=496MiB/s (520MB/s)

Warum dauert das Lesen von 2,0GB dann hier über 4sek, trotz SSD's in RAID0 ?
Das Ding ist am Anschlag. Mehr kann er einfach nicht. Völlig egal, ob 12 Gb/s "theoretisch gehen würden".

• buffered reads: 519 MB/s
• direct read (4M block size): 534 MB/s
• Sequential Read (iodepth=1): 496 MB/s (127k IOPS)

Gerne nochmal 2 SSD's dazuhängen. Da wird sich wenig bis garnichts an den Ergebnissen ändern...
Ist zu 100% ein CPU-Bottleneck des Controllers.

@Mr. Smith
Danke, hast du ne Quelle für das Bild? Würde mich da gerne weiter belesen.

Direkt von Broadcom... denen ja LSI zwischenzeitig gehört.
Ist zwar ein sehr altes Dokument; aber es ist nunmal auch ein sehr alter Controller.
Etwas Aktuelleres gibt es dazu nicht. Bzw. lässt sich beim Hersteller selbst nichts finden.

 

[Khorneflakes]

Was du ignorierst steht schon da, lesen und verstehen und so. Und das Dokument enthälst du uns ja auch weiterhin vor. Die Bandbreite, die der TE mit 4 Disks erreicht, ist das natürliche Limit für die Disks. Es ist weder ein Limit des Ports noch ein Limit des Controllers. Wenn er mehr will, dann braucht er mehr und/oder schnellere Disks.

Dass zwei SSDs im Raid 0 534 MB/s erreichen ist Korrelation, nicht Kausalität. Wenn deine Interpretation stimmen würde, dann wäre das garnicht möglich. Die Tabelle, unter der Annahme dass sie stimmt, legt die Vermutung nahe, dass das über Anzahl der Devices * 150 MB/s skaliert.

Ich habe mit SAS1078-Controllern auch schon vor einer halben Ewigkeit 10G-Verbindungen ausgelastet. Daher, ja, das ist so und da besteht kein Zweifel.

 

[Karl_mags]

Ergänzung, damit keine langsame SSD den Test verfälscht, hier eine der baugleichen ssds im single-betrieb:

❯ sudo dd if=/dev/zero of=/media/sdc1/test2g bs=2G count=1 oflag=dsync
0+1 Datensätze ein
0+1 Datensätze aus
2147479552 Bytes (2,1 GB, 2,0 GiB) kopiert, 9,26291 s, 232 MB/s

❯ dd if=/media/sdc1/test2g of=/dev/null bs=16M iflag=direct
127+1 Datensätze ein
127+1 Datensätze aus
2147479552 Bytes (2,1 GB, 2,0 GiB) kopiert, 5,46196 s, 393 MB/s

... Die Bandbreite, die der TE mit 4 Disks erreicht, ist das natürliche Limit für die Disks. Es ist weder ein Limit des Ports noch ein Limit des Controllers. Wenn er mehr will, dann braucht er mehr und/oder schnellere Disks.

Ich glaube das ist der Kern meines Anliegens: Meine Disks bewegen sich im Singe-Betrieb alle zwischen ~150-180MB/s sequentielles lesen. daher wundert mich dass die zusammen doch "nicht viel" schneller sind bzw. ~das Doppelte an Lesegeschwindigkeit haben, wohingegen bei einem Raid10 4x in der Theorie, 3x in der Praxis drin wären.

 

[Mr. Smith]

Was du ignorierst steht schon da, lesen und verstehen und so. Und das Dokument enthälst du uns ja auch weiterhin vor.

Lesen und verstehen... das Dokument ist in dem Post verlinkt.
Und das schon deutlich länger, als deine Antwort alt ist...

Und wie der Einzelbetrieb der SSD's wieder zeigt: 393 MB/s und 5,46sek.
Ein Raid0 aus 2 dieser SSD's würde dann doch keine >4sek benötigen, wenn der Controller ja so viel mehr kann.
Dann würden wir hier Werte deutlich unter 3sek sehen.

Dass zwei SSDs im Raid 0 534 MB/s erreichen ist Korrelation, nicht Kausalität.

Es ist keine Korrelation, wenn ich bereits um 16:37Uhr die Behauptung aufstelle, das Limit läge bei ~520MB und der TE dann über eine Stunde später genau diese Werte plötzlich 3-fach bestätigt....

Ergänzung (3. Februar 2025)

@Mr. Smith
Keine Ahnung was für eine Tabelle du da hervorgekramt hast und wie du die verstehst. Habe gerade meinen alten IBM Serve Raid MR10i LSI 1078 mal rausgeholt und 4 Festplatten dran angeschlossen. Funny enough steht sogar IBM 8708E drauf.

MR10i nutzt den 1078e (embedded) und hat doppelt so viel Cache...
Ein direkter Vergleich ist daher schwierig.

Du müsstest seinen Controller haben bzw. er bräuchte deine Platten.
Beiden Seiten müssten dann mit dem identischen Tool benchen und dann ist es vergleichbar. So aber nicht.

Benche ich den Controllercache sieht man schön das Limit vom Controller.

Ich benche auch nicht nur den Controller meiner SSD's und ignoriere den lahmen QLC-NAND-Flash, den der Controller dann bedienen muss. Sicher sieht der Bench dann toll aus. In der Realität ist es trotzdem lahm.

 

[Khorneflakes]

Tja, ich bitte um Verzeihung dafür, dass ich nicht regelmäßig alte Posts auf Änderungen prüfe. Als ich zuletzt geguckt hab war das da noch nicht verlinkt.

Jetzt ist mir aber auch klar, warum du aus dem Dokument von Broadcom so selektiv zitierst. Der Rest der Tabelle und die nächste Seite passen ja nicht zu deinem Märchen.

 

[Mr. Smith]

Tja, ich bitte um Verzeihung dafür, dass ich nicht regelmäßig alte Posts auf Änderungen prüfe. Als ich zuletzt geguckt hab war das da noch nicht verlinkt.

Dafür, dass du so langsam schreibst und es nicht gesehen hast, kann ich aber auch nichts.
Die Quelle ist verlinkt und damit ist das Thema gegessen.

Es steht auch nichts widersprüchliches in der Quelle drin. Zumindest nicht, wenn man theoretische Maximal-Bandbreiten und reelle Bandbreiten voneinander zu unterscheiden weiß.

Der Rest der Tabelle und die nächste Seite passen ja nicht zu deinem Märchen.

Ja klar...
Der Hersteller selbst stellt ein PDF zur Verfügung mit der Überschrift "Performance Limits & Bottlenecks" in dem ganz klar 520 MB/s augelistet ist (für genau diesen Controller, genau mit diesem Interface und halt auch genau 4 SATA-HDD's), aber ich erzähle immer noch Märchen.

Von deiner Seite hingegen kam bis dato überhaupt nichts, außer Behauptungen, ohne dass diese auch nur in irgendeiner Form untermauert worden wären. Ich weiß, wer hier der Märchenerzähler von uns beiden ist.
Zeig mir doch bitte ein offizielles Review dieses RAID-Controllers (mit 4 SATA-HDD's o. SSD's), wo er locker die dreifache Leistung auf die Bretter zaubert. Ich les mir das gern durch.

Ab diesem Punkt empfinde ich auch weitere Diskussionen gegebenermaßen als Zeitverschwendung. Es wurde viel geschrieben, aber nichts belegt.

 

[Khorneflakes]

Ab diesem Punkt empfinde ich auch weitere Diskussionen gegebenermaßen als Zeitverschwendung. Es wurde viel geschrieben, aber nichts belegt.

Ich stimme dir zu.

 

[gaym0r]

@Mr. Smith
Warum hast du nicht dieses Bild geteilt?

Bei vier Ports wären es ja dann 1,2GB/s.

Und warum hast du nicht die ganze Tabelle gezeigt?

Wo ist der Unterschied zwischen den ersten drei und den folgenden drei Zeilen? Irgendwie alles bisschen komisch.