[Kaufberatung] SSD-Kaufberatung/-Informationsthread + Diskussion (Bitte lesen!)

HMB läuft super, da kann man nichts sagen. SSDs die kein HMB und kein DRAM haben, da trifft die aussage eher zu. die sind einfach langsam. sowas wie SanDisk Plus ist schon sehr langsam im vergleich zur Ultra.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Das wurde hier im Thread schon ausführlich behandelt, selber suchen und lesen wird man ja noch voraussetzen können?
Nur weil jemand bestimmtes, der seine "Fakten" aus uralten (immer gleichen) Quellen bezieht, ohne selbst HMB Hardware zu besitzen geschweige denn praktisch getestet zu haben, hier seine Weisheiten zum Besten gibt, muss man das nicht unbedingt auf die Goldwaage legen. Hier gibt es genügend User die praktisch HMB SSD einsetzen und hoch zufrieden damit sind. Warum also deren Erfahrungswerte immer in Abrede stellen wollen und gleich grundsätzlich ablehnend reagieren? Die DRAM-SSD Verfechter werden eh die nächsten Jahre Probleme bekommen weiterhin ihre Wünsche zu befriedigen, denn der Markt dieser Storage wird sich auf einen verschwindend kleinen Teil minimieren, der dann preislich ferner liefen aufgerufen wird.
 
Zuletzt bearbeitet:
Man muss nicht alles selbst testen. Dass die Performance mit HMB einbricht, sobald die Zugriffe über einen bestimmten Adressbereich hinaus verteilt sind, wurde schon zur Genüge von Testern nachgewiesen. Auch wenn die Tests schon ein paar Jahre alt sind, ändert das nichts an deren Gültigkeit. Dass Nutzer zufrieden sind, ist auch kein Beleg dafür, dass HMB-SSD keine besonderen Schwachstellen haben. Ein Großteil der Nutzer merkt nicht mal den Unterschied zwischen einem SATA- und einem PCIe-SSD der Oberklasse und eine anderer, nicht geringer Teil ist zufrieden, solange Benchmarks, der Bedeutung man sich nicht so recht erklären kann, möglichst hohe Werte zeigen.
 
Der grundsätzliche Tenor hier ist überwiegend: "HMB ist Mist, HMB ist unsicher, HMB ist lahm, HMB SSD traue ich nicht meine sensiblen Daten an".
Wobei gerade der letzte Punkt mal absoluter Schwachsinn ist, denn der NAND, worauf ja letztendlich die Daten gespeichert werden ist nicht selten der gleiche wie bei SSD mit DRAM Cache.

Mir konnte bis dato noch niemand plausibel nachvollziehbar beweisen, wo HMB unsicherer oder unzuverlässiger sein soll oder warum HMB (bei nicht exzessiv multirandom_access) Mist sein soll.

edit: Da ja hier im Forum SSD Tests gerne mit PCM8 gebencht werden, habe ich gestern mal das gleiche mit einer meiner HMB SSDs veranstaltet und den knapp 2,5std. langen Storagebench gestartet:
Gesamtwertung: 854.66 MB/s (zwischen SN580 und P5Plus)

Battlefield3: 668.42MB/s (zwischen VP4000 uns SN580)
WoW: 384.97MB/s (zwischen 990EVO+ und SN5000)
After Effects: 554.18MB/s (zwischen P5Plus und NV7000)
Adobe Indesign: 1061.82MB/s (zwischen NV7000 und P5Plus)
Adobe Illustrator: 605.36MB/s (zwischen SN580 und P5Plus)
Adobe Photoshop: 1639.14MB/s (zwischen MP600 und Exceria Pro)
MS Exel: 821.60MB/s (zwischen 990Pro und SN850X)
MS Powerpoint: 981.95MB/s (zwischen NV7000 und 990Pro)
MS Word: 933.33MB/s (zwischen VP4300 und SN850X)
..wer glaubt das sei ein gefaktes Ergebnis, der darf sich hier aus den Thread gerne die von mir angehangene result.zip in sein PCM8 laden, da bekommt er noch detailiertere Ergebnisse.

Und was dieses Ammenmärchen "füllstandsabhängiger Datentransfereinbruch ab ca.90%" sei ein only HMB Feature betrifft: Kein Sorge, dass gilt für DRAM cached SSD nicht weniger. Und warum ist das so?
Kleiner Tipp: Vieleicht weil das eine (HMB vs. DRAM) mal rein gar nichts mit dem anderen (pseudo SLC) zu schaffen hat? ;)
sn850x 90+.png
 
Zuletzt bearbeitet:
beschleunigt rBAR eigentlich auch die M.2-Slots? Ich habe ein Gigabyte B650 und rBAR deaktiviert, dann hatte ich mit meiner
990 Pro 2 TB in CrystalDiskmark beim schreiben ab 4 GiB nur 1200 MB/s bis 2400 MB/s! Die SSD hängt direkt am 7800x3d!
der 2.Slot zeigte das Verhalten nicht, obwohl er auch an der CPU hängt...
 
Auf meine System, Intel LGA1700, hat das Abschalten von rBAR hat keinen Einfluss auf die Schreibleistung in CDM. Würde mich auch wunderen, wenn ein solcher Einfluss korrekt wäre. rBAR dient ja dazu, der CPU direkten Zugriff auf das RAM von PCIe-Geräten zu ermöglichen. Bei SSD wird das eigene RAM fast ausschließlich vom SSD-Controller für den schnellen Zugriff auf die Mappingtabelle genutzt. Die CPU kann diese Tabelle nicht deuten.
Wäre hilfreich, wenn Nutzer mit einem AM5-System deine Beobachtung prüfen.
 
Das OS sollte nicht mal zugriffrechte auf den DRAM Cache der SSD haben. Dieser ist ausschließlich für den Controler der SSD.
 
Zumindest bei Intel hat rBar null Einfluss auf das Storage, würde mich auch wundern wenn es anders wäre.

rbar.jpg


ps: Auch das (große) Buildupdate 23H2 zu 24H2 zeigt nach 1 Tag Praxisnutzung keinerlei der hier beschriebenen Bugs mit WD HMB SSD (ohne FW-Bugfix), wenn diese halt anderer Marke sind:

23h2to24h2.png

..dafür hat 24H2 zahlreiche andere Problemchen die es (für mich) derzeit nicht nutzbar machen, daher wurde es wieder zurück gesetzt auf 23H2.
 
Zuletzt bearbeitet:
aber ich denke aus der Praxiserfahrung es reicht Hauptsache das eine SSD mit DRAM Cache ist... dort wirkt das caching genauso.
So bald alles relevante im DRAM vorgehalten wird ist das flott genug.
Du verstehst immer noch nicht, wozu SSD Controller einen DRAM Cache haben: Der ist zum Cachen der Verwaltungsdaten, nicht der Userdaten! Bei der optimalen Größe von 1GB DRAM Cache pro 1TB Kapazität, passt dann die ganze Mappingtabelle da rein.

Die DRAM-losen haben ja zumindest SLC-Cache das die Daten dann vorhält
Der Pseudo-SLC Schreibcache, wie der volle Name diesen Caches ist, der leider gerne als SLC Cache bezeichnet wird, ist ein reiner Schreibcache und hat damit eine ganz andere Aufgabe als der DRAM Cache. Der eine Cache hat also mit dem anderen nichts zu tun! Wie MoBo 01/04 schon richtig schrieb:

Der SLC-Cache hält eigentlich keine Daten vor, auf die häufig zugegriffen wird. Der puffert lediglich Schreibzugriffe bis diese endgültig im TLC/QLC-Mode ins NAND-Flash geschrieben werden. Lesezugriffe, die bei OS-Operationen wesentlich häufiger auftreten, gehen an diesem Cache gänzlich vorbei.
Eben, der ist zum schnelleren Schreiben von Daten vor allem bei TLC und QLC Client SSDs da, bei SSDs mit MLC NAND war er noch nicht verbreitet, aber ohne wäre die Schreibgeschwindigkeit bei TLC und vor allem QLC NAND sonst sehr langsam, selbst auf dem Datenblatt.

Wie schon zuvor geschrieben ist der LPDDR4 SDRAM die zweit teuerste Komponente einer SSD
Die zweitteuerste Komponente dürfte der Controller sein, außer vielleicht bei SSDs mit sehr hohen Kapazitäten die dann auch entsprechend viel DRAM Cache haben.

Hieß es nicht mal ohne Dram sollte mann keine Kaufen. Oder das Diese nicht so gut sind
Wer behauptet sowas? Die haben halt Nachteile bei zufälligen Zugriffen über große Adressräume, vor allem Lesezugriffen, weil der Controller dann eben immer wieder den passenden Teil der Mappingtabelle aus dem NAND nachladen muss, bevor die eigentlichen Daten aus dem NAND geladen werden können. Lesezugriffe aufs NAND dauern eben viel länger als aus dem DRAM Cache zu lesen und selbt als die Daten über die PCIe Anbindung und die CPU aus dem DRAM Hauptspeicher des Rechners zu laden.

Hier gibt es genügend User die praktisch HMB SSD einsetzen und hoch zufrieden damit sind.
Das eine widerspricht dem anderen ja nicht, es kommt immer auf die Nutzung an, was aber leider manche nicht verstehen oder es überfordert sie, Dinge differenziert zu betrachten.
Die DRAM-SSD Verfechter werden eh die nächsten Jahre Probleme bekommen weiterhin ihre Wünsche zu befriedigen, denn der Markt dieser Storage wird sich auf einen verschwindend kleinen Teil minimieren, der dann preislich ferner liefen aufgerufen wird.
Bei den Enterprise SSDs ist ein voller DRAM Cache immer noch Standard. Auf den DRAM Cache zu verzichten, bringt technisch allenfalls durch eine leicht geringere Leistungsaufnahme einen Vorteil, dazu eben den Kostenvorteil, aber sonst keine Vorteil und eben bei den IOPS Lesend über einen großen Adressraum deutliche Performanceprobleme.

Man muss nicht alles selbst testen. Dass die Performance mit HMB einbricht, sobald die Zugriffe über einen bestimmten Adressbereich hinaus verteilt sind, wurde schon zur Genüge von Testern nachgewiesen. Auch wenn die Tests schon ein paar Jahre alt sind, ändert das nichts an deren Gültigkeit.
Eben, dies ist für alle DRAM less SSDs (außer den Optane, aber deren 3D X-Point ist lesen fast so schnell wie DRAM) gleich und wird sich auch nicht ändern, da muss man nichts selbst testen, wenn man die Zusammenhänge versteht. Aber ich weiß das so Manche damit überfordert sind.

Der grundsätzliche Tenor hier ist überwiegend: "HMB ist Mist, HMB ist unsicher, HMB ist lahm, HMB SSD traue ich nicht meine sensiblen Daten an".
Keine Ahnung wer hier sowas behauptet, von mir kommen solche Kommentare jedenfalls nicht!

Und was dieses Ammenmärchen "füllstandsabhängiger Datentransfereinbruch ab ca.90%" sei ein only HMB Feature betrifft:
Auch dies dürfte von Leuten kommen, die immer noch nicht verstanden haben, wozu der DRAM Cache (bzw. alternativ HMB) genutzt wird und was die Aufgabe eines Pseudo-SLC Schreibcaches ist. Dabei ist letzteres schon im Namen, aber wenn man dessen Bezeichnung abkürzt, dann geht der Teil der dessen Aufgabe beschreibt, leider meist verloren.

Das OS sollte nicht mal zugriffrechte auf den DRAM Cache der SSD haben. Dieser ist ausschließlich für den Controler der SSD.
Das OS hat mit den Caches der SSDs nichts zu tun, außer dem HMB, den es über den NVMe Treiber bereitstellt. Aber auch in dem Fall geht es das OS nichts an, was der Controller da dann wo ins DRAM des Rechners schreibt, welches ihm als HMB zugewiesen wurde.
 
Du verstehst immer noch nicht, wozu SSD Controller einen DRAM Cache haben: Der ist zum Cachen der Verwaltungsdaten, nicht der Userdaten! Bei der optimalen Größe von 1GB DRAM Cache pro 1TB Kapazität, passt dann die ganze Mappingtabelle da rein.
Zu meinem eigenen Verständnis mal kurz zusammengefasst:

Pseudo) SLC Cache: Wird genutzt um beim schreiben eine gewisse Datenmenge schnell zu speichern, da SLC schneller ist als das TLC etc. Zur Laufzeit wird dann der SLC in TLC überführt, wenn der SLC voll ist, bricht die Geschwindigkeit ein bis der SLC wieder "geleert.

außer dem HMB, den es über den NVMe Treiber bereitstellt.
Wenn HBM ein Treiberfeature ist, wie macht die Version wo die Mappingtabelle im NAND gespeichert wird zur Laufzeit überhaupt noch Sinn? Oder wird HBM von nem extra Controller auf der SSD gespeichert und somit ist dieser als Hardwarefeature voraussetzung und die ganz billigen Modelle haben nichtmal das und müssen daher NAND nutzen?
 
Der Pseudo-SLC Schreibcache, wie der volle Name diesen Caches ist, der leider gerne als SLC Cache bezeichnet wird, ist ein reiner Schreibcache und hat damit eine ganz andere Aufgabe als der DRAM Cache. Der eine Cache hat also mit dem anderen nichts zu tun! Wie MoBo 01/04 schon richtig schrieb:
Nicht bei allen wird dieser als SLC als Schreibcache erwähnt. Aber du magst schon recht haben dann ist es aber irreführend.
Ganz oft steht unter Cache anstelle von DRAM / SLC
1730724179087.png

Steht zwar SLC-Cached, würde aber die Lesegeschwindigkeit ohne SLC Cache dann genauso schnell sein?
Da sie ja kein DRAM hat?
 
Pseudo) SLC Cache: Wird genutzt um beim schreiben eine gewisse Datenmenge schnell zu speichern, da SLC schneller ist als das TLC etc
Wenn irgendwo von SLC Cache die Rede ist, ist immer der Pseudo-SLC Schreibcache gemeint, denn kein Hersteller fertigt mehr SLC NAND. Also ist es immer Pseudo-SLC, also TLC oder QLC NAND bei dem nur eines der 3 bzw. 4 Bits pro Zelle beschrieben wird, was schneller geht und nebenbei auch viel weniger Strom benötigt. Der Pseudo-SLC Schreibcache dient eben nur als Schreibcache, was klar wird, wenn man seinen vollständigen Namen verwendet, mit dem DRAM Cache oder HMB hat der nichts zu tun und umgekehrt, beides erfüllt komplett unterschiedliche Aufgaben.
Wenn HBM ein Treiberfeature ist, wie macht die Version wo die Mappingtabelle im NAND gespeichert wird zur Laufzeit überhaupt noch Sinn?
Erstens: HMB nicht HBM, denn HBM steht für High Bandwidth Memory, was man z.B. bei Grakas oder in AI Hardware findet) und HMB steht für Host Memory Buffer.
Zweitens ist der HMB und auch der DRAM Cache immer nur ein Lesecache, die eigentlichen Daten stehen immer im NAND und werden auch bei Schreibvorgängen sehr zeitnah im NAND aktualisiert, damit Datenverlust vermieden wird, sollte es zu unerwarteten Spannungsabfällen kommen. Nur Enterprise SSDs mit Full-Power-Loss-Protection können sich dies sparen, da die ja auch bei unerwarteten Spannungsabfällen den Inhalt des DRAM Cache noch ins NAND schreiben können.
Oder wird HBM von nem extra Controller auf der SSD gespeichert und somit ist dieser als Hardwarefeature voraussetzung und die ganz billigen Modelle haben nichtmal das und müssen daher NAND nutzen?
Nein, HMB hat nichts mit der HW zu tun, es ist eine Funktion des Controllers die vom NVMe Protokoll unterstützt wird und vom Host (also z.B. PC) unterstützt werden muss und es steht explizit in der Spezifikation, dass HMB nur als Lesecache genutzt werden darf und bei plötzlichem Verlust von dessen Inhalt kein Datenverlust auftreten darf.

Voraussetzung für HMB ist aber eben NVMe und damit eine PCIe Anbindung, da diese eine Voraussetzung für NVMe ist, SATA SSD haben also kein HMB und meist nur genug SRAM Cache in den billigen DRAM less Controllern, um einen Teil der Mappingtabelle dort vorhalten zu können, der gerade für einen Adressraum von 1GB reicht, genug für Benchmarks wie AS-SSD und CDM in deren Standardeinstellung. Bei HMB waren bisher maximal 64MB üblich, also genug für 64GB Adressraum und damit um auch komplexe Benchmarks wie PC Mark und die Alltagsanwendungen vieler Heimanwender abzudecken. Kommt es aber zu Zugriffen über einen größeren Adressraum, so macht sich das Fehlen des RAM Caches in einer höheren Latenz bei Lesezugriffen bemerkbar. Die Latenz spielt vor allem bei kleinen Zugriffen eine Rolle, weil da die Zeit für die Übertragung der eigentlichen Daten ja recht kurz ist und damit die Latenz besonders auffällt. Liest man viele MB am Stück, dauert dies alleine so lange, dass die Latenz auch nicht mehr ins Gewicht fällt.

Nicht bei allen wird dieser als SLC als Schreibcache erwähnt.
Was sollte es sonst sein? Es ist bei keiner SSD ein extra SLC NAND Baustein verlötet, schon weil kein Hersteller mehr SLC NAND produziert. Außerdem wäre dessen Kapazität dann nicht abhängig vom Füllstand der SSD, wie es aber eben bei allen Pseudo-SLC Schreibcaches der Fall ist, eben weil es ja das normale TLC/QLC NAND ist, bei dem dann eben nur ein Bit beschrieben wird. Würde es da extra einen SLC NAND Chip geben, hätte die billigen SSDs alle keinen "SLC Cache", da dies viel zu teuer wäre und außerdem auch viel zu langsam, wenn man nur ein SLC NAND Die hätte, da die Geschwindigkeit aus der Parallelität kommt.

Steht zwar SLC-Cached, würde aber die Lesegeschwindigkeit ohne SLC Cache dann genauso schnell sein?
Keine Ahnung wie schnell Daten gelesen werden können, die noch im Pseudo-SLC Schreibcache stehen, aber es dürfte so schnell wie aus dem normalen TLC/QLC Bereich sein, da Benchmarks wie AS-SSD und CDM ja die Daten schreiben und danach gleich wieder auslesen, diese dann also noch im Pseudo-SLC Schreibcache stehen werden. Dies würde außerdem nur einen kleinen Teil der Daten betreffen, die Löwenanteil wurde ja sicher schon vor längerer Zeit geschrieben.

Auf die Lesegeschwindigkeit hat der Pseudo-SLC Schreibcache also keinen Einfluss und genauso hat der DRAM Cache (bzw. ersatzweise HMB, sollte die SSD keinen DRAM Cache haben, es gibt keine SSDs die einen DRAM Cache und HMB haben!) keinen Einfluss auf die Schreibgeschwindigkeit. Jedenfalls keinen nennenswerten, denn beim Schreiben ändert sich die Mappingtabelle, die aber eben immer im NAND aktuell gehalten werden muss, da der DRAM Cache genau wie HMB nur Lesecache ist und allenfalls spart der DRAM Cache mal den einen oder anderen Zugriff auf die Verwaltungsdaten, damit der Controller ermitteln kann wo es weitere, freie NAND Pages zum Beschreiben gibt. Dies macht aber beim Schreiben vieler GB den Kohl nicht fett! Deshalb sind der DRAM Cache und der Pseudo-SLC Schreibcache zwei getrennte Dinge mit ganz unterschiedlichen Funktionen und der eine Cache ersetzt den andere nicht und hat mit der Funktion des anderen auch nichts gemein!
 
@PeterPan62 : Ich bin zwar nicht @Holt, aber antworte trotzdem mal auf Deine Frage ;)
Allerdings mit 3 Gegenfragen:
  1. Welchen Grund gibt es, dass Du das System und die Programme von einander trennen willst? Denn objektiv gesehen gibt es nicht unbedingt einen Grund beides von einander zu trennen.
  2. Wie sieht das restliche Sys von Dir aus?
  3. Was machst Du hauptsächlich mit Deinem Sys? Wenn Du sehr oft tonnenweise Daten hin und her schaufelst, oder große Videos bearbeitest, sieht eine Empfehlung anders aus, als bei einem reinen Office- PC oder bei einem PC, der hauptsächlich zum Gaming genutzt wird.
 
Das eine widerspricht dem anderen ja nicht, es kommt immer auf die Nutzung an, was aber leider manche nicht verstehen oder es überfordert sie, Dinge differenziert zu betrachten.
Bei den Enterprise SSDs ist ein voller DRAM Cache immer noch Standard.
Und in den Enterprise Segment wird sich (aus Kostengründen) DRAM SSD immer mehr verlagern.
Ich habe als registrierter LS bei TI Zugriff auf die NTR und MDTR (Stand 09/24) und darf daher die Prognose abgeben, mehr aber dann auch nicht.

TIP.png

Auf den DRAM Cache zu verzichten, bringt technisch allenfalls durch eine leicht geringere Leistungsaufnahme einen Vorteil, dazu eben den Kostenvorteil, aber sonst keine Vorteil und eben bei den IOPS Lesend über einen großen Adressraum deutliche Performanceprobleme.
Wobei man fairerweise eigentlich auch dabei erwähnen sollte, dass diese Adressräume schon sehr groß sein müssen, damit Normaluser dieser signifikante Nachteil überhaupt auffällt.
Denn ansonsten hinterläßt das einfach nur den Eindruck, dass schon kleine Zugriffeinheiten ausreichen würden um den Unterschied DRAM vs. HMB zu bemerken, was aber nicht der Fall ist.

Die zweitteuerste Komponente dürfte der Controller sein, außer vielleicht bei SSDs mit sehr hohen Kapazitäten die dann auch entsprechend viel DRAM Cache haben.
Die Cost Notes Teardown welche ich hier mal zu der 990Pro gepostet hatte bezogen sich natürlich auf das 4TB Model. Bei 2TB ist der Controller dann die zweitteuerste Komponente, dass stimmt.

$166.16 - Multichip Memory - 2 TB 3D TLC V-NAND Flash - Samsung - K9DYGY8J5B-CCK0 - (QTY: 2)
$9.52 - Multichip Memory - 4 GB Mobile LPDDR4 SDRAM - Samsung - K4FBE6D4HM-BGCH - (QTY: 1)
$9.18 - SSD Controller - Samsung - S4LV008 - (QTY: 1)
$1.60 - Power Management - Samsung - S2FPS06 - (QTY: 1)
$0.87 - Top Enclosure - - - (QTY: 1)
$0.85 - 12 Layer Conventional FR4 / HF - Unknown - - (QTY: 1)
$0.55 - Small Passive: Cap, Res, Ferrite - - - (QTY: 137)
$0.48 - Bottom Enclosure - - - (QTY: 1)
 
Zuletzt bearbeitet:
Abgesehen von Performance sind PCIe Gen5 derzeit kaum zu empfehlen. Die bisher verfügbaren Modelle basieren alle auf dem Phison-E26-Controller. Der ist in 12nm gefertigt und hat so hohe Verlustleistung, dass die SSD ohne aktive Kühlung umgehend gedrosselt werden. In den nächsten Monaten werden Modelle mit effizienteren Controllern erscheinen.
 
@PeterPan62 : Ich bin zwar nicht @Holt, aber antworte trotzdem mal auf Deine Frage ;)
Allerdings mit 3 Gegenfragen:
  1. Welchen Grund gibt es, dass Du das System und die Programme von einander trennen willst? Denn objektiv gesehen gibt es nicht unbedingt einen Grund beides von einander zu trennen.
  2. Wie sieht das restliche Sys von Dir aus?
  3. Was machst Du hauptsächlich mit Deinem Sys? Wenn Du sehr oft tonnenweise Daten hin und her schaufelst, oder große Videos bearbeitest, sieht eine Empfehlung anders aus, als bei einem reinen Office- PC oder bei einem PC, der hauptsächlich zum Gaming genutzt wird.

1. Mache ich immer so und es bleibt beim trennen.
2. Ein 650E mit zukünftig 9800 x3d und min.48gb ram
3. 2D CAD und Gaming.
Das 2D CAD verdient Geld.

Es soll nicht unbedingt billig sein, dafür habe ich kein Geld.
Meine Favoriten sind 980/990 pro bzw. die WD sn850.

Nach Möglichkeit nicht dram less!
 
@PeterPan62 : Naja, "es schon immer so gemacht zu haben und das es daher auch so bleibt" ist natürlich ein starkes Argument ;) Aber jatzt davon ausgegangen, würde ich dann eine SSD mit 1 TB für das System nehmen. (Ich gehe mal ganz frech davon aus, dass es sich um Windows handelt.) Wobei für das reine Windows auch schon 500GB reichen sollten.
Und für die Programme und Spiele würde ich heute eigentlich nicht mehr unter 4TB gehen. Ausser Du hast die Möglichkeit eine dritte nvme einzubauen, wenn der Platz eng wird.
Ich selber habe seit es sie gibt zwei WD_Black SN 850X in meinem System. Und später kam noch eine dritte hinzu. Sind PCIe 4.0- nvme's. Egal ob Videos rendern, zocken, oder BIldbarbeitung (das sind so meine Schwerpunkte), ich war mit der Leistung immer zufrieden. Manche Leute sagen, die SN850X würden zu warm werden. Das kann ich in keiner Weise bestätigen. Meine Sys- Platte liegt direkt unter der GraKa. Das Case ist hier auch eher etwas unvorteilhaft, das das Mobo insg. etwas "eingebettet ist - Case ist das Phanteks NV9). Aber die nvme ist bei mir nie über 55°C gekommen. Die 2. nvme (mein Datengrab) von WD hatte nach etwa 18 Monaten einen Totalausfall. Garantie angestoßen und ca. 2,5 Wochen später hatte ich eine neue in Händen ohne Rumgeier. Ich hatte die aber im Sale auch direkt bei WD gekauft.
Also ich würde die immer wieder empfehlen.
 
Ich danke dir für die Empfehlung.
So in etwa hatte ich das auch vor. Sys. 500GB und Rest 4TB und bei Bedarf noch eine 4 TB, wobei ich ein NAS mit Sicherung als Datengrab und für Plex nutze.
 
Moin,

brauch ein paar günstige "Enterprise" SATA-SSDs bzw. NVMes, d. h., welche mit PLP und möglichst hohem TBW-Wert. Neu sind im Geizhals nur die Samsung PM883/893 und die Micron 5300 Pro bezahlbar, beide "read intensive", sprich die TBW haut mich jetzt auch nicht vom Hocker. Bin durchaus willig, Hersteller-recertified bzw. gebraucht zu kaufen, nur kenn ich mich zuwenig aus.
  • Was will man denn momentan haben? Gibt's z. B. gute Modelle, die gerade en masse ausgemustert werden? Ohne konkrete Modellnummer am eBay suchen is nämlich fürn Hugo ...
  • Irgendwelche guten Quellen?
P.S. Oder gehört die Frage ins Homeserverforum?
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh