News SupremeRAID SR-1010: SSD-RAID mit 110 GB/s und 19 Mio. IOPS dank GPU

Masamune2 schrieb:
Ist irgendwie etwas Augenwischerei denn die Leseleistung könnte man auch komplett ohne die Karte erreichen, hier ist die PCIe Bandbreite die ein System hat letztendlich der Flaschenhals. Da die Karte selbst ja auch nur ein einem PCIe x16 Slot steckt können die Daten beim lesen da ja nicht durchwandern, sonst wär bei PCIe 4 bei knapp 31GB/s Schluss.
Interessant ist erst die Schreibgeschwindigkeit aber die Zahl ist dann nicht mehr so schön hoch. Da begrenzt eben die Schnittstelle der Karte.
Generell ist die Angabe von Raid10 merkwürdig. Bei Raid10 werden keine Prüfsummen oder Paritäten berechnet. Wozu braucht es da GPU außer für den Umstand, dass da einige GB sehr schneller Speicher als Cache dienen können.
Edit: Beim Lesen wird es dann vollkommen absurd. Die Verifikation liegt da komplett bei der CPU, vorausgesetzt man nutzt ein Dateisystem, welches Checksumming betreibt. Dann kann man die Datenraten aber vergessen...

Nore Ply schrieb:
@madmax2010 : Es gibt ein paar Fälle in denen Daten mit hoher Geschwindigkeit reinkommen und erstmal gespeichert werden müssen. Physik (Simulationen, aber natürlich auch CERN und ko. ) sind da immer ein guter Kandidat.
Beim Cern werden vergleichsweise wenig Daten geschrieben. Da wurde enormer Aufwand betrieben um Daten zu verwerfen. Würden regelmäßig alle Rohdaten auf Festspeichern landen, wäre der Bedarf an Kosten und Bandbreite zum internationel Großrechnerverbund nicht leistbar.
 
  • Gefällt mir
Reaktionen: Unnu, 2Stoned und Nore Ply
Masamune2 schrieb:
Ist irgendwie etwas Augenwischerei denn die Leseleistung könnte man auch komplett ohne die Karte erreichen, hier ist die PCIe Bandbreite die ein System hat letztendlich der Flaschenhals. Da die Karte selbst ja auch nur ein einem PCIe x16 Slot steckt können die Daten beim lesen da ja nicht durchwandern, sonst wär bei PCIe 4 bei knapp 31GB/s Schluss.
Interessant ist erst die Schreibgeschwindigkeit aber die Zahl ist dann nicht mehr so schön hoch. Da begrenzt eben die Schnittstelle der Karte.
Richtig erkannt, beim Lesen wird der Raidcontroller praktisch nicht gebraucht, da wird keine Parität berechnet, gar nichts. Wenn man 32 Drives im Raid0 verbindet kommt man wohl auf ähnliche Datenraten. Könnte aber auch sein dass sie zusätzlich noch was von dem VRAM der Karte für Caching benutzen und die Zahl so um biszu 32gb/s aufblähen.

andr_gin schrieb:
Sehr gut. Brauche ich nur mehr in Board mit 32 PCIe Schnittstellen :D
Es sind ja nur x4 lanes pro SSD + x16 für die GPU. Also 128 Lanes und ein Dualsocket Epyc hat biszu 160 mit Spezialboards, 128 default (sogar schon bei 1P). Viele boards haben zwar maximal 6 oder 7x PCIe Gen4x16 Slots, aber dazu noch SFF-TA-1009 oder ähnliche high density Verbinder. Da sind dann bis zu x16 Dualport, also 2x8 Lanes mit bis zu Gen5 auf einem Stecker etwa in SAS Größe.
Außerdem wird seit SAS24G auch häufig multiplexed, also selbst wenn man nur 16gb/s von der CPU hat (x8), hängt man da 2x 12gb/s SAS dran, also 24gb/s, da die CPU verbindung ohnehin selten das Bottleneck darstellt.
Ich meine 128 PCI Gen4 Lanes sind sind theoretisch 256gb/s - hier erreicht man aber nur 110gb/s.

eastcoast_pete schrieb:
Erster Impuls: Haben wollen! Dann: NVIDIA GPU, und was fehlt in der Mitteilung - der Preis - also auch schon ohne die SSDs mit Sicherheit sehr, sehr teuer. Aber als Technologie schon sehr beeindruckend!
Frage: Sind 110 GB/s überhaupt schon durch eine derzeit erhältliche PCIe Verbindung abgreifbar? Selbst PCIe 5.0 x16 kommt doch da schon nicht ganz hin, also müsste das Ding schon PCIe 6 unterstützen, damit die 110 GB/s auch im System ankommen. Gibt's PCIe 6 schon in der freien Wildbahn?
Beim Lesen geht das direkt an die SSD, der GPU-Controller macht fast nichts.

Wenn es um die Leistung geht kriegt man das mit einer schnellen CPU und Raid0 sicher auch hin, wäre vermutlich sogar schneller weil man kein Bottleneck der GPU mit PCIeGen4x16 hat. Kann sein dass DMA viele CPUcycles kostet, aber hardware DMA-Beschleuigung ist auch kein großes Geheimnis und RAM als Cache hat eine CPU auch reichlich. Kostet halt alles nur Energie und CPUleistung.

Problematisch wird es erst einen Raid5 oder 6 über soviele Drives zu machen, weil das Paritäten berechnen da extrem viele CPU cycles kostet. Hardware Raid5-Controller halten schon seit Jahren nicht mehr mit den Geschwindigkeitszuwächsen von PCIe basierten SSDs mit, das ist hoffnungslos veraltet.

21-25gb/s ist schon echt gut für einen Raid5 wenn man bedenkt dass das theoretische Maximum der PCIex16 Gen4 Karte 32gb/s sind.
Von den SSDs her ginge da sicherlich auch mehr.

wern001 schrieb:
Ich weiß gar nicht wie die leute auf die idee kommen 110 GB/sek zur CPU/Ram.
Ich schätze 110 GB/sek zwischen SSD (oder mehreren SSDs) und GPU
Gab es nicht von AMD auch mal so ein Teil wo man 2 SSDs draufpacken konnte?

Als reiner Raid-Kontroller ist eine GPU auch nicht der Hit. Für sowas nimmt man normal ASICs
Das kriegt man schon hin, Epyc hat mit 8ch 205Gb/s Speicherbandbreite.

Naja, Raid Asics werden vielleicht in 90nm oder 65nm hergestellt und haben viel weniger Transistoren und Rechenpower und kaum SRAM. Eine moderne GPU ist dagegen schon fast "general purpose" und bringt außerdem reichlich Speicher mit den man auch als Write Cache benutzen kann.
 
  • Gefällt mir
Reaktionen: Smartbomb, Renegade334, Unnu und 3 andere
lukas12342 schrieb:
Bin nach wie vor immer noch sehr skeptisch Hardware RAID gegenüber.

Das ist kein Hardware Raid, das ist ein Software Raid und wird vom Hersteller auch so beschrieben.

Nore Ply schrieb:
Wo genau sollen da 110 GB/s erreicht werden?

Nicht mit PCIe4x16, was afaik maximal 32 GByte/s "unter Linux" erlaubt.

Die Daten wandern auch nicht über die Karte beim Lesen sondern der Host greift direkt auf die Devices zu. Beim Schreiben gibt es dann den Umweg über die Karte für die ganzen Berechnungen für das Raidgedöns. Daher kann das Schreiben nicht schneller werden als die Gen4 x16 Schnittstelle und wird es laut Hersteller ja auch nicht, selbst im Raid 10 Fall.
 
  • Gefällt mir
Reaktionen: poolk, racer3, Sironardo und 5 andere
Chuuei schrieb:
Die Daten wandern auch nicht über die Karte beim Lesen sondern der Host greift direkt auf die Devices zu.
Das klingt zwar toll - erklärt aber noch nicht über welche Schnittstelle die Daten unter Linux und mit 110 GB/s zum Host kommen.
 
sadofia schrieb:
ist wohl schrott:
Da muss ich zustimmen, kein guten Produkt
 
Nore Ply schrieb:
Das klingt zwar toll - erklärt aber noch nicht über welche Schnittstelle die Daten unter Linux und mit 110 GB/s zum Host kommen.
Die Devices sind immer direkt am Host angeschlossen, je nach Schnittstelle also PCIe, SAS, SATA, kann aber auch NVMe-oF wo die Devices im Netzwerk drin hängen können.

Im Grunde ist das ganze System nichts anderes als jedes andere Softwareraid (es ist kein HW Raid wie einige schreiben) wo man beliebige Devices zusammenfasst, nur dass die notwendigen Berechnungen nicht die CPU übernimmt, sondern über nen extra Treiber auf die Beschleunigerkarte ausgelagert sind.

Das Testsystem ist ja aufgeführt, nen 2x32 Kern Xeon System, damit hat man problemlos die Bandbreite die man brauch für die 110GB/s.
 
  • Gefällt mir
Reaktionen: Smartbomb, Sironardo, Pako1997 und 4 andere
blubberz schrieb:
Ist ja dann schneller als der Arbeitsspeicher, oder?
Nur in der datenrate. Viel höhere Latenzen jedoch und insofern nicht wirklich mit Arbeitsspeicher zu vergleichen.

eastcoast_pete schrieb:
U.u. um Optane zu ersetzen oder verdrängen, aber ich vermute daß die Hauptnutzung als Ersatz für die vielen TB von RAM sein könnte, die sehr große Speicher-residente
Groß ja und für Hana klasse, aber als optane Ersatz würde ich das auf keinen Fall sehen. Die Latenzen von optane liegen ja knapp eine Größenordnung unter denen von klassischem nand. Dank raid werden die Latenzen hier nochmal einen deut höher sein, als es ohne der Fall wäre
 
  • Gefällt mir
Reaktionen: Smartbomb und Renegade334
Linus hat das auch vor kurzem getestet. (Andere Grakas als die mitgelieferte gingen übrigens nicht. Könnte aber an der Lizenzbindung an die gelieferte GPU liegen.) Wie schon beschrieben, splittet der Treiber die Arbeit. Beim Lesen gehen die Daten direkt je SSD an die CPU (vermutlich per NVME). Beim Schreiben laufem die ein Mal durch die GPU, welche via CUDA die nötige Parität prüft und dann den Kram auf die SSDs schiebt. So wurde es jedenfalls bei LTT beschrieben/so hab ich das verstanden. Als Dateisystem kommt eine Eigenentwicklung zum Einsatz. ("ZFS ootb" geht also nicht.)

Regards, Bigfoot29

Nachtrag: @Titanx : Danke. Das Video meinte ich. :D
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ofenheiz, Sironardo, konkretor und eine weitere Person
Blackvoodoo schrieb:
Was kostet der Spaß?
Frage ich mich auch grade. Würde so etwas nicht kaufen, aber wäre doch mal interessant zu wissen.
 
Potentieller Anwendungsfall :)
 
  • Gefällt mir
Reaktionen: EinUser1, Sironardo, konkretor und 5 andere
madmax2010 schrieb:
Nutzrt man sie im CDN, braucht der server eine Anbindung von mindestens 1 Tbit/s und am Ende limitiert dann doch die CPU :D

Irgendwas wird immer limitieren.
Wenn diese Geschwindigkeiten nur halbwegs im Rechner bei mir wären xd.
Oder gleich über den Ram alles laufen lassen, nur eben einen haben, der auch dauerhaft alles speichern kann.
 
Ltcrusher schrieb:
Frage ich mich auch grade. Würde so etwas nicht kaufen, aber wäre doch mal interessant zu wissen.
Genau. Kaufen würde ich das nie, brauche ich nicht. Aber neugierig bin ich halt schon.
 
Bis zu 32 NVMe-SSDs können so über die PCIe-Schnittstelle in den RAID-Modi 0, 1, 5, 6 oder 10 miteinander verbunden werden, stecken aber nicht selbst in der Adapterkarte.
Wo sind die denn untergebracht?

wern001 schrieb:
Gab es nicht von AMD auch mal so ein Teil wo man 2 SSDs draufpacken konnte?
Das war aber als Zusatzspeicher, für eine FirePro Karte

0x8100 schrieb:
wozu ein 70W gpu-controller mit 19Mio iops wenn man schon mit einem einzelnen cpu-core 14Mio schafft?
Um die Arbeit von der CPU weg zu lotsen
 
  • Gefällt mir
Reaktionen: Unnu
andi_sco schrieb:
Um die Arbeit von der CPU weg zu lotsen
wie einige hier schon geschrieben haben, bringt dieser "controller" beim lesen von daten rein gar nichts - die cpu last wird nicht verringert. die karte wird nur beim schreiben genutzt - beim berechnen von checksummen ist eine gpu natürlich gut geeignet. allerdings ist die datenrate dann aber auch auf die bandbreite von pci 4.0 x16 begrenzt und diese bringt eine cpu auch nicht zum schwitzen. zusätzlich sind server mit schreib/leseraten in dieser grössenordnung mit cpus mit genug cores bestückt.
 
  • Gefällt mir
Reaktionen: andi_sco
Das Level1Tech Video hat das meiner Meinung perfekt zusammen gefasst.


Bei einen guten RAID muss ich den error reporting der Datenträger nicht vertrauen hier aber schon.

Ich kann ein RAID aus guten und maliziösen/fehlerhaften Datenträgern bauen und ein gutes RAID System egal ob Hardware oder Software sollte recht schnell mir die problematische Datenträger nennen.
Dieses System hier vertraut aber blind dem maliziöse Datenträger. Wenn die kein Problem melden dann ist der RAID vermeintlich healty.

Die Performance ist halt beeindruckend gut weil es schlicht weniger tut als andere RAID Systeme.
 
  • Gefällt mir
Reaktionen: Masamune2 und madmax2010
Die ganze Praesentation wirkt fuer mich nicht serioes. - Dass die oben aufgefuehrten Yter sofort anspringen verstaerkt meinen Eindruck noch zusaetzlich.
 
@Biedermeyer : Schau Dir eins der genannten Videos an und Du wirst sehen, wie sie das bewerten. - Nicht immer gleich motzen, erstmal nachdenken. ;)
(Fazit: So grün wie die Wiese gemalt wird, ist sie natürlich nicht. Aber zumindest ein erster PoC ist es durchaus.)

@andi_sco : Bei LTT wird ein Dual-Epyc-System genutzt. Die Lanes da dürften reichen. ;) Schau Dir das Video einfach an. Wird da alles erklärt. (Natürlich braucht es dafür noch Adapter von PCIe-"Slot" auf M2.)

Regards, Bigfoot29
 
Zurück
Oben