Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsSamsung SmartSSD: Schlauer Datenträger soll CPU fast überflüssig machen
Zum glück sind wir hier ja nicht auf "heimcomputer-base" da dürfen auch gerne mal news zu datacenter dingen sein^^
btt: Den meisten ist vermutlich nicht klar wie viel Rechenleistung im Storage-Bereich "verbrannt" wird. Es sind teils dual-socket systeme nötig, deren einzige aufgabe es ist, die daten die von den Platten kommen oder gehen zu verarbeiten und zu koordinieren.
Smarte SSDs die entweder die last verringern oder den (i/o) durchsatz steigern, bieten dort sehr interessante möglichkeiten
Die selbe Frage wollte ich auch stellen. Im Prototypen? Ok. Aber im fertigen Produkt wäre doch ein maßgeschnittener Chip sinnvoller, solange man nicht mit "KI" im laufenden Betrieb den Chip dauernd umschreibt...
Die selbe Frage wollte ich auch stellen. Im Prototypen? Ok. Aber im fertigen Produkt wäre doch ein maßgeschnittener Chip sinnvoller, solange man nicht mit "KI" im laufenden Betrieb den Chip dauernd umschreibt...
FPGAs können von den Betreibern der Datacenter flexibel programmiert werden und damit können diese festlegen, welche Funktionen genau wie umgesetzt werden.
Netflix hat vll eine andere Infrastrukur als als der Flughafen Singapur und möchte daher die SSDs auf eine andere Art und Weise laufen lassen.
ASICs sind da viel zu unflexibel und man müsste sich auf einen Usecase festlegen. Warum nicht dem Kunden die Flexibilität geben und ihn selber entscheiden lassen, was genau die SSD machen soll?
Simples Beispiel: Du bastelst einen ASIC der HEVC (H.265) dekodiert und damit die CPU offloaded. Du verkaufst dann die SSD mit diesem ASIC an einen Betreiber von Kameraüberwachung. Die Streams der Kameras benötigen aber AV1 -> shit luck, dein ASIC ist unbenutzbar.
Entweder man macht also die ASICs so fett, dass sie alle Eventualitäten abdecken und damit werden sie groß und teuer und aufwändig. Oder man bastelt einfach FPGAs rein und sagt den Kunden, entscheidet einfach selber was ihr damit machen wollt.
Bezweifle ernsthaft dass dies etwas bringen wird für den Ottonormalverbraucher.
Ob die Berechnungen in der SSD stattfinden oder in der CPU: sie finden statt
Nun sollte mal jemand ein 2000eur System nehmen und testen wieviel CPUload eine SSD aktuell hat?
lohnt sich die Verschiebung? wieviel Mehrkosten für Verbraucher? wieviel Stromkosten gespart? usw. halt..
Wie viel CPU kosten denn SSD Zugriffe üblicherweise, davon dann 97% weniger? 0.5%? Werden Daten nicht ohnehin in den RAM geschoben, wenn genug frei ist ?
Bezweifle ernsthaft dass dies etwas bringen wird für den Ottonormalverbraucher.
Ob die Berechnungen in der SSD stattfinden oder in der CPU: sie finden statt
Das werden wir für Consumer auch noch lange nicht sehen...
Der große Vorteil ist tatsächlich der Energieverbrauch, denn FPGA sind für ihre sehr spezifischen Anwendungsfälle effizienter als CPUs und es entfällt der Datentransfer zur CPU. Und gerade das macht einiges aus, IO wie PCIe verbrät immer mehr und mehr mit jeder Generation.
Lohnenswert könnte das im Hausgebrauch wohl nur für Videoschnitt oder ähnliches sein, wenn man dem Schnitt auf der CPU macht und das Resultat dann innerhalb der SSD transkodiert in andere Formate, da dafür die Daten die SSD nicht mehr verlassen müssten.
Geht es da um die reinen Transaktionen um Register über den Bus zu schieben, den Aufwand um das Dateisystem zu verwalten, oder, irgendwo dazwischen, schieben die SSDs Arbeit die vormals der Controller gemacht hat (Wear Leveling, Buffer, Address Tables verwalten, etc) auf die CPU?
Nachtrag:
Hito360 schrieb:
Bezweifle ernsthaft dass dies etwas bringen wird für den Ottonormalverbraucher.
Da braucht es nicht nur eine spezielle Software für, sondern eine komplette angepasste Software-Architektur. Das baut man nicht eben in Windows oder in Steam ein, und es wäre den Aufwand vermutlich nicht wert. Wenn man hingegen irgendwann Workloads quasi wie mit Kubernetes auf tausende SSDs pro Cluster statt auf hunderte Server pro Cluster schieben kann könnte das für Analyse und sonstige HPC-Aufgaben durchaus interessant sein. Die CPUs in den Servern können in der Zeit etwas besseres tun, oder man spart sich viel Geld weil weniger oder kleinere CPUs reichen. Das Tooling ist teilweise schon vorhanden, und die Algorithmen werden oft ohnehin parallel auf vielen Tausend Workern verteilt. Ob dann eine CPU, ein Server, eine VM, oder eine SSD die Arbeit macht könnte elegant wegabstrahiert werden und interessiert eigentlich nicht mehr.
Da von Samsung Datenbanken explizit als Anwendungsfall genannt wurden, geht es vermutlich darum die Anzahl an System Calls zu reduzieren. Mit optimierten Systemen bekommt man ein paar Millionen IO/s hin und lastet dabei ordentlich die CPU aus. Die meiste Leistung geht dabei im Übergang vom User Space zu Kernel Space drauf. Mit mehr "Intelligenz" im Drive kann man mit weniger Calls mehr erreichen, weil mehr Verhalten von der Anwendung zum Drive übertragen wird. Achieving 11M IOPS & 66 GB/s IO on a Single ThreadRipper Workstation
Since issuing so many block I/Os on my 16-core CPU keeps it 100% busy, I had to find other tricks to reduce the CPU usage of fio and I/O handling layer in general
Geht es da um die reinen Transaktionen um Register über den Bus zu schieben, den Aufwand um das Dateisystem zu verwalten, oder, irgendwo dazwischen, schieben die SSDs Arbeit die vormals der Controller gemacht hat (Wear Leveling, Buffer, Address Tables verwalten, etc) auf die CPU?
hier ein Haufen an Videos, die das Thema ansprechen. Die sind wie ich weiß, dass CPU-Performance für SSD Storage ein echtes Problem sein kann.
YouTube
An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.
An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.
An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.
An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.
An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.
Die Followup-Videos zum 1-Millionen-$-SSD-Server sind btw noch nicht erschienen, keine Ahnung was da so lange dauert. Vermutlich technische Schwierigkeiten mal wieder.
Aber auch mal ganz stümperhaft: Wenn die summierte (theoretische) Geschwindigkeit der verbauten SSDs in die Nähe der Bandbreite des verbauten RAM kommt, jedoch Datenredundanz eine Mehrzahl an Speicherzugriffen erfordert (und zwischendurch auch noch Berechnungen) - ja, dann wundert es nicht, dass das nicht so einfach ist.
Der große Vorteil ist tatsächlich der Energieverbrauch, denn FPGA sind für ihre sehr spezifischen Anwendungsfälle effizienter als CPUs und es entfällt der Datentransfer zur CPU. Und gerade das macht einiges aus, IO wie PCIe verbrät immer mehr und mehr mit jeder Generation.
In der Tat wäre es da bemerkbar, wenn man passende Workloads hätte. Aber die sind eher selten.
jau, das sehe ich als offensichtlich(Energieverbrauch).
Ich hätt gern einen Test in dem SSD-CPU-load in Watt übersetzt wird, und dann SmartSSD zeigen kann wieviel Strom man spart.
Das Ganze dann aber bitte auch mit 1bis4 SmartSSDs vs. 1bis4 nonSmartSSDs vs 1smartSSD1nonSmartSSD2HDDs
Ab wann verpuffen Vorteile eventuell? usw.
Nicht nur Calls, hier geht es auch wirklich anwendungsspezifische Tasks. Ein Beispiel bei Datenbanken wäre die Erstellung von Indizes - da muss einmal die ganze Tabelle (zumindest die relevanten zu analysierenden Spalten) von der Platte durch die CPU geleitet werden, die daraus den Index erstellt. Das ist ein enormer Durchsatz bei großen Datenbanken.
Stattdessen kann man hier der SSD sagen "bau mir mal einen Index" und muss dann nur den um Größenordnungen kleineren Index Richtung CPU/RAM schieben, nicht die ganze Tabelle die indiziert wurde.
Genau für solche Anwendungsfälle ist es übrigens sehr sinnvoll, dass hier ein FPGA und kein ASIC verbaut ist - jeder kann seinen eigenen Code da rein kippen, wie seine Anwendung es braucht.
Ergänzung ()
Hito360 schrieb:
Ich hätt gern einen Test in dem SSD-CPU-load in Watt übersetzt wird, und dann SmartSSD zeigen kann wieviel Strom man spart.
Ein Test für sowas wäre sicherlich spannend, aber um das wirklich zu zeigen, müsste man das wohl ziemlich groß aufziehen.
Jetzt mal wild spekuliert, angenommen ein System mit CPU+SSD wäre mit 2x CPU und 10xSSD am Maximum der CPU-Auslastung angenommen, und mit SmartSSD wäre stattdessen für den Anwendungsfall 2xCPU und 30x SmartSSD möglich als Architektur um alle Komponenten voll auszulasten. Wenn man nur ein Drittel der Nodes braucht wird ja auch die ganze Infrastruktur drum herum einfacher, günstiger und sparsamer.
Na FPGAs kommen entweder von AMD (vom gekauften XILINX) oder von Intel (vom gekauften Altera) .. Samsung hat sich hier offenbar für Xilinx entschieden. Das muß aber ein anderer SSD Hersteller nicht genauso sehen ..
Die FPGAs müssen mit ihrer Konfigurationsdaten (Konkrete Verschaltungen von Dingen wie Flipflops, Speicher, Gattern, ALUs, etc) geladen werden. Ähnlich wie Software in die CPU. Das geht aber durchaus auch für Teilbereiche - typ. unter Kontrolle der System CPU. Auch enthalten FPGAs öfter kleinere CPUs (ARM, Mips, Power, ..) für die dann natürlich Software als Bestandteil der Konfigurationsdaten fällig wird.
Ergänzung ()
Somerset schrieb:
Spannend. Aber FPGA sind nur in recht spezifischen Fällen "besser/ökonomischer".
FPGAs sind recht teuer für die Leistung die man später bekommt. Der Vorteil liegt in der möglichen Rekonfiguration. Nun verstehe ich nicht so ganz, wieso man das bei I/O braucht.
Entweder tut man so ziemlich oft dasselbe, dann wäre eine ASICs besser.
Oder man hat wechselnde Aufgaben und nutzt CPUs. Hash-check, Encoding, Encryption. All das sind Dinge die wir heute schon als ASICs auf CPUs haben.
Ich bin sicher das sich Samsung was dabei gedacht hat, aber mir fällt kein usecase ein in welchem ein "dynamischer ASICs" auf der SSD sinnvoll wäre.
Das kann ich schon eher verstehen. Jedoch, nur wenn die Standards recht offen bleiben und man damit nicht so ein Käse macht wie Apple :/
Laufwerke haben in der Regel einen kürzen Lebenszyklus als CPUs.
ASIC oder FPGA ist meist ne Frage der Stückzahl. Wenn du von einem Gerät das eins von beiden nur 100 oder 1000 sprich ne Speziallösung an wenige Kunden verkaufen kannst und für den nächsten Kunden wieder irgend was anpassen mußt bist du mit einem FPGA besser beraten. Vor allem kannst du auch noch Anpassungen nachreichen - denn wenn der Kunde sich mal ne Speziallösung hat machen lassen - dann kommen die Anpassungswünsche garantiert auch noch nach der Auslieferung. Und ein Asic zu machen dauert .. und vor Ort mal eben einbauen ist meist schwierig .. noch schwieriger wenn du dafür den Hersteller der SSD brauchst ..
FPGAs können gegenüber CPUs insbesondere Vorteile bei Echtzeitverarbeitung (Latenz/Takt) ausspielen - ein CPU muß immer irgendwie auf einem Block von Daten arbeiten weil ein Thread/Prozessaktivierung unter 1us nicht zu haben ist, und so Latenzen unter 1..10ms bei einer irgendwie ausgelasteten CPU nicht zu machen ist. Während in den FPGAs quasi herkömmliche verdrahtete Schaltkreise aus ALUs, Speicher, Flipflops etc. auch verzugsfrei in ns getaktete Schaltkreise in Wartestellung nur für diese Aktion stehen. Kleines Detail - FPGAs können meist mehrere physische GHz Takte auf denen die Logik/Datenströme dann direkt arbeitet - das schafft definitiv keine CPU.
Also kann man mit FPGA z.B. auch A/V Interfaces direkt implementieren statt auf fertige Chips oder in die CPU eingebautes setzen zu müssen. Und zusätzlich die Verarbeitung im Detail auf Kundenwünsche anpassen - die vorgefertigten Chips haben hier oft ihre Grenzen.
Beispiele die mir heute einfallen würden wär z.B. Streaming vom Server an 1000 Abnehmer gleichzeitig direkt von der SSD - ganz an der CPU vorbei. Mit oder ohne Umkodierung, Bitratenanpassung oder Samplerateanpassung. Die CPU vergibt nur die Arbeitsaufträge.
Oder eben die im Artikel genannten low level 1000nde Datenbankzugriffe der Clients im Internet - an der Server CPU&Ram vorbei auf die SSD.
Ergänzung ()
Somerset schrieb:
Spannend. Aber FPGA sind nur in recht spezifischen Fällen "besser/ökonomischer".
FPGAs sind recht teuer für die Leistung die man später bekommt. Der Vorteil liegt in der möglichen Rekonfiguration. Nun verstehe ich nicht so ganz, wieso man das bei I/O braucht.
Entweder tut man so ziemlich oft dasselbe, dann wäre eine ASICs besser.
Oder man hat wechselnde Aufgaben und nutzt CPUs. Hash-check, Encoding, Encryption. All das sind Dinge die wir heute schon als ASICs auf CPUs haben.
Ich bin sicher das sich Samsung was dabei gedacht hat, aber mir fällt kein usecase ein in welchem ein "dynamischer ASICs" auf der SSD sinnvoll wäre.
Das kann ich schon eher verstehen. Jedoch, nur wenn die Standards recht offen bleiben und man damit nicht so ein Käse macht wie Apple :/
Laufwerke haben in der Regel einen kürzen Lebenszyklus als CPUs.
ASIC oder FPGA ist meist ne Frage der Stückzahl. Wenn du von einem Gerät das eins von beiden nur 100 oder 1000 sprich ne Speziallösung an wenige Kunden verkaufen kannst und für den nächsten Kunden wieder irgend was anpassen mußt bist du mit einem FPGA besser beraten. Vor allem kannst du auch noch Anpassungen nachreichen - denn wenn der Kunde sich mal ne Speziallösung hat machen lassen - dann kommen die Anpassungswünsche garantiert auch noch nach der Auslieferung. Und ein Asic zu machen dauert .. und vor Ort mal eben einbauen ist meist schwierig .. Und als Serverbetreiber hast du oft viele kleine ganz verschieden gestrickte Kunden. Und morgen andere. Time to Market ist natürlich auch ein Aspekt.
FPGAs können gegenüber CPUs insbesondere Vorteile bei Echtzeitverarbeitung (Latenz/Takt) ausspielen - ein CPU muß immer irgendwie auf einem Block von Daten arbeiten weil ein Thread/Prozessaktivierung unter 1us nicht zu haben ist, und so Latenzen unter 1..10ms bei einer irgendwie ausgelasteten CPU nicht zu machen ist. Während in den FPGAs quasi herkömmliche verdrahtete Schaltkreise aus ALUs, Speicher, Flipflops etc. auch verzugsfrei in ns getaktete Schaltkreise in Wartestellung nur für diese Aktion stehen. Kleines Detail - FPGAs können meist mehrere physische GHz Takte auf denen die Logik/Datenströme dann direkt arbeitet - das schafft definitiv keine CPU.
Also kann man mit FPGA z.B. auch A/V Interfaces direkt implementieren statt auf fertige Chips oder in die CPU eingebautes setzen zu müssen. Und zusätzlich die Verarbeitung im Detail auf Kundenwünsche anpassen - die vorgefertigten Chips haben hier oft ihre Grenzen.
Beispiele die mir heute einfallen würden wär z.B. Streaming vom Server an 1000 Abnehmer gleichzeitig direkt von der SSD - ganz an der CPU vorbei. Mit oder ohne Umkodierung, Bitratenanpassung oder Samplerateanpassung. Die CPU vergibt nur die Arbeitsaufträge.
Oder eben die im Artikel genannten low level 1000nde Datenbankzugriffe der Clients im Internet - an der Server CPU&Ram vorbei auf die SSD. Oder gepuffert durch das DRAM das am SSD klebt - statt den laangen Umweg über den CPU Hauptspeicher zu nehmen. Wobei sich so eine CPU und FPGA durchaus mal über moderne Schnittstellen wie CXL auch mal einen Pufferspeicher(Cache) in CPU oder am FPGA auch mal kohärent teilen können.
Eine SSD mit FPGA wird's für meinen Laptop oder Desktop wohl nicht so schnell werden, aber die Idee, die Daten schon durch den SSD Controller vorzukauen, macht viel Sinn. Die Controller sind ja meist schon um ARM Cortex oder ähnliches herum gebaut, und da etwas größere Prozessoren mit mehr Leistung und Fähigkeiten zu verbauen würde nicht die Welt kosten, aber mehr Vorarbeit ermöglichen.
Das erinnert mich an die alten Diskettenlaufwerke von Commodore.
Der Computer(C64/C128... ect.) übertrug nur ein Kommando an das LW und führte es völlig selbständig aus.
ZB das Kopieren einer Datei von einem LW auf ein anderes musste nur vom Computer 'angeordnet' werden. Danach konnte man das Kabel zum Computer ziehen und die Laufwerke kopierten munter weiter.
Im Prinzip waren das damals vollständige Computer(CPU, RAM, IO Bausteinen, OS im ROM, ect.) mit teilweise höherer oder gleichwertiger rechenleistung wie der Computer an den sie angeschlossen waren.
Ist somit eigentlich nichts neues. Gab es schon vor rund 40 jahren zu kaufen😛
Die SSDs sind deutlich schneller geworden, nur die Game Engines können nicht damit umgehen.
So lange Games theoretisch auch auf HDDs oder SATA SSDs laufen müssen, ist das Object Streaming der Game Engines nicht in der Lage, die Geschwindigkeit von NVMe SSDs zu nutzen.
Erst, wenn Games auf SATA SSDs oder HDDs gar nicht mehr lauffähig sind und NUR noch für NVMe SSDs programmiert werden, wird auch die Geschwindigkeit von NVMe SSDs genutzt werden.
Das Streaming muss völlig anders programmiert werden, wenn man statt einer HDD eine NVMe ausnutzen möchte. [...}
Wäre mehr RAM nicht nach wie vor tausendmal besser als flinke NVMe-SSDs und eine völlige Umprogrammierung von Spiele-Engines? Soll das Spiel doch 25 von 32 GB oder 56 von 64 GB RAM belegen, na um so besser! Dazu ist RAM doch da!
Nein. Das Bottleneck ist nicht der RAM, sondern wie schnell die Engine Daten in den RAM läd. Mehr RAM mit Daten vorsorglich vollrortzen wäre genau so eine Änderung wie einfach nicht mehr von HDD Geschwindigkeit auszugehen.
Viele Games enthalten Daten übrigens mehrfach, um random reads zu vermeiden, die HDD brutal ausbremsen. Wenn man von sowas weg kommt, ist in jeder Hinsicht viel gewonnen.
.
im laufenden Betrieb den Chip dauernd umschreibt...
