News High Bandwidth Flash: HBF soll 512 GB mit 3 TB/s verbinden

[input_iterator]

Ja im PC Bereich sieht es anderes aus. Da kannst Du aber mit HBF nichts anfangen, weil dieser extra an die speziellen Anforderungen für K.I Workloads entworfen worden ist und auch mit keiner normalen CPU nicht einsetzbar wäre, weil diesen die komplette Controller Logik fehlt. Dazu ist HBF auf Bandbreite und nicht auf Latenzen dominiert und auch die Zugriffsmuster die man so typisch im PC Bereich hat nicht passt. Es ist halt nur eine Zwischenstufe zwischen HBM und SSD in K.I. Systemen.

 

[beckenrandschwi]

Hoffe die Stapel sind austauschbar. Sonst wird es nach paar tausend Schreibvorgängen sehr teuer.

 

[Pringel]

@input_iterator
Als wenn das in ejnem Fall länger als einen halben Tag dauernd würde ein Design des vorherigen SSD-Controllers drauf anzupassen und die Firmware dazu an folgenden 2 Tagen zu schreiben...

 

[input_iterator]

@Pringel Auf so was antworte ich eigentlich nicht, weil es einfach absurd ist was Du schreibst. Man kann einen SSD Controller nicht mal so anpassen, weil HBF keinen SSD Controller hat und auch keinen gebrauchen kann. HBF ist Compute Adjacent Memory über UCIe, ohne NVMe Protokoll, ohne LBAMapping, ohne FTL, ohne Controller DRAM, ohne Queue Handling. Deine Behauptung ist ungefähr so realistisch wie zu sagen, ich baue in zwei Tagen meine CPU zu einer GPU um. Dazu passen die Latenzzeiten überhaupt nicht für die typischen Anwendungszwecke. Diese Latenzen kannst Du nicht mi einem SSD Controller und einer Firmware weg optimieren, weil einfach diese durch den Nand vorgegeben wird und durch einen zusätzlichen SSD Controller auch noch ansteigen würde.

 

[TorenAltair]

Mit 3 TB/sek wäre der Speicher doch erheblich schneller

Mal ein extremes Beispiel:
Ein LKW, der 30000 30TB HDDs von A nach B in 1 Tag transportiert kommt auf über 10 TB/s

 

[Pringel]

Man kann einen SSD Controller nicht mal so anpassen, weil HBF keinen SSD Controller hat und auch keinen gebrauchen kann.

Was für ein Blödsinn... HBF hat keinen SSd Controller. Wow. Genial. Gut daß wir es geklärt haben, Herr Binse.

 

[stefan92x]

Hoffe die Stapel sind austauschbar. Sonst wird es nach paar tausend Schreibvorgängen sehr teuer.

Austauschbar wird das nicht, das sind Chiplets, die gemeinsam auf einem Package sitzen - wo jetzt auch schon HBM-Stacks verbaut sind.

Gleichzeitig hast du natürlich recht, aber darum geht es hier ja auch - selten geänderte Daten sind auf HBF gut aufgehoben, anderes kommt ins HBM. Beim genannten Anwendungsbereich KI-Inferenz bietet sich HBF also an, um das Modell im Speicher zu halten (was ja nur sehr selten neu geladen wird), während der HBM für die jeweiligen Anfragen genutzt wird.

 

[input_iterator]

Was für ein Blödsinn

Du hast doch mit Deinem Unsinn angefangen. Dann wunder Dich nicht wenn andere auf Deinen Troll Beitrag reagieren. ;-)

 

[Pringel]

Du hast doch mit Deinem Unsinn angefangen

Du hast verstanden und dir zurechtgedreht, was dir für das bisschen Klugsch... am besten ins Bild passte.

Von mir aus... Wollen wir dem gerechterweise nicht allzuviel Bedeutung beimessen
Ciao.

 

[Beitrag]

HBF steht da ein wenig zwischen den Stühlen. Ist zwar sehr nahe an der GPU, aber die Latenz wird deutlich höher als bei DRAM sein.

Dache habe ich auch gedacht, wobei ja auch die Schnittstelle eine ganz andere als sonst ist und mit dem Gestapel ein Stück weit auch der Chip-Aufbau.
Welcher Arbeitsschritt macht denn den Löwenanteil der Leselatenz von Flash aus?

 

[input_iterator]

Du hast verstanden und dir zurechtgedreht, was dir für das bisschen Klugsch... am besten ins Bild passte.

Wenn du meinst, ich hätte mir „zurecht gedreht“, was Dir nicht ins Bild passt, ist das Dein gutes Recht. Ändert aber nichts daran, dass Dein Kommentar technisch inhaltsleer war. Wenn Dir dann die sachlichen Antworten von anderen Usern nicht passen, bist du in einem Technikforum falsch aufgehoben.

 

[Beitrag]

Optane = bester P/L Cache für ZFS, schade, dass es den nicht mehr gibt.

Optane ist einer der seltenen Fälle, bei dem die Speicherzellen persistent waren, das Produktportfolio aber nicht.

 

[Bright0001]

3 TB/s bei humanen Größen? Da hab ich ja glatt Pipi in den Augen. Bei der Größenordnung wäre wirklich jede Art von (Daten-)Ladezeit ein gelöstes Problem, zumindest im Desktop-Kontext.

Kann man nur hoffen, dass sich die Technologie in den nächsten Jahren Richtung Prosumer/Konsument bewegt, wäre ne schicke Sache.

Und das Register natürlich... sie können die Bits doch nicht direkt vom Cache in die Alus schubsen... das fehlt auch... wen schon dann bitte auch vollständig.

Ich wollte auch gerade noch Stichpunkte wie Paging und TLB/MMUs reinschmeißen, wäre sonst ja auch viel zu simpel.

 

[Pringel]

Ändert aber nichts daran, dass Dein Kommentar technisch inhaltsleer war. Wenn Dir dann die sachlichen Antworten von anderen Usern nicht passen, bist du in einem Technikforum falsch aufgehoben.

Das liegt an den blöden KIs. Die erzählen alle, daß es "konzeptionell und architektonisch" möglich wäre.

Das Thema ist aber neu Deren Bots haben für die nächste Lehrstunde wohl noch nicht deine inhaltsvollen Beiträge auf CB abgegraben. Wird sich aber spätestens nächste Woche ändern. Dann wissen wieder alle bescheid.

 

[pipip]

Es gibt vermutlich noch weitere Segmentierungen

• Accelerator-[Cache -> HBM -> Local DRAM -> HBF] -> Host DRAM -> Local SSD -> Network SSD -> HDD -> Band.

HBF steht da ein wenig zwischen den Stühlen. Ist zwar sehr nahe an der GPU, aber die Latenz wird deutlich höher als bei DRAM sein.

Bei der GTX 960 war das ein Feature 😜

 

[FreshLemon]

Optane = bester P/L Cache für ZFS, schade, dass es den nicht mehr gibt.

Nutzt du den für L2ARC als zusätzlicher ZFS Cache? Bei mir ist noch eine 16GB Optane als ZFS SLOG im Einsatz, habe noch ein HDD-Array bestehend aus 14 600GB 10K SAS-Drives im Server. Aber L2ARC würde bei mir gar nicht genutzt werden, da selten die gleichen Daten mehrfach geöffnet werden. Und ich habe eh genügend RAM-Reserven.

 

[massaker]

Nutzt du den für L2ARC als zusätzlicher ZFS Cache?

Nein, für L2ARC nimmst am besten eine ganz normale große TLC-SSD (mit viel mehr Kapazität), keine Optane. Macht besonders in der heutigen RAM-Krise Sinn, aber bei Dir und "habe eh genügend RAM-Reserven" - evtl. nicht wirklich nötig.
Und für SLOG dann im Idealfall zwei kleine Optanes in einem mirror-pool, 16-32 oder 64 GB reichen vollkommen (je nach dem System-Rest und Szenario).

 

[Mac_Leod]

Das was massaker schreibt, SLOG auf eine gespiegelte Optane und dein ZFS rennt wie verrückt, hast du ja selbst im Einsatz.
Auf einer einzelnen SSD würde ich das Setup nicht betreiben, wenn der SLOG dir weg fliegt hast du ein nicht allzukleines Problem. Dann lieber nicht exra auslagern.
Bei mir ist der RAM sehr knapp, daher hab ich den 1,6TB Opante ausgelagert, die noch rum lag.
Das ist aber eher Spielerei.

Ich frage mich, was das genau an Zellen beim HBF verbaut werden, SanDisk hat dazu bisher nichts geschrieben, vermutlich SLC.
Bei 512 GB Größe und 3 TB/s wie soll das teschnisch mit der Haltbarkeit funktionieren?
Den kann man theoretisch pro Sekunde ~5,8x voll schreiben.
Bei 5 Jahren Betrieb und fast 1 Mrd x lesen, geht das doch auch über die Haltbarkeit.
Also gibt es dann am Ende des Tages ein NAND Speicher, der schneller als alle anderen NANDs Daten liefern.
kann, aber der Software Layer drüber extrem aufpassen muss mit den Schreibvorgängen.
Ungebremmst lebt der Speicher keine 10 Minuten