Nein um Fehler zu erkennen und zu melden reicht "Parity" RAM.
Die Korrektur geht nur mit ECC RAM.
Die Rede war auch von DDR4, und da wird bei unbuffered non-ECC nichts gemeldet. Der Speichercontroller würde Fehler erkennen und diese nochmal übertragen, davon bekommst Du aber nichts mit.
Noch ja, aber HBM soll ja auch auf den SoC kommen.
HBM ist dann aber immer noch RAM, und kein Cache. Und nur weil die Bandbreite von HBM wesentlich höher ist als von Beispielsweise DDR3 oder 4 sind die Latenzen noch immer weit entfernt von einem Cache weshalb es diesen auch weiterhin geben wird.
Aber warten wir auf reale Produkte im CPU/APU Sektor mit HBM ab, möglicherweise kann man durch die Geschwindigkeit von HBM die Cache Größen oder Stufen reduzieren. Durch größere Caches kann man jedoch im Umkehrschluß bestimmt nicht die RAM Größe reduzieren.
Klar ich nutze Vollbestückung von ECC weil ich nicht weiß wie es funktioniert?
Was hat es damit zu tun ob Du es nutzt oder nicht und sogar in "Vollbestückung" nutzt daß Du genau weißt wie es funktioniert UND es was das bedeutet bzw. wie man es einsetzt?
Dein Satz daß bei Dir unbuffered-ECC Sinn macht weil Du alte HDDs nutzt die kein Schreib - CRC nutzen deutet darauf hin daß Du es zumindest nicht genau weißt wie man es einsetzt. Deine HDD wird intern bestimmt ebenso Prüfsummen/Fehlerkorrekturen beim Schreiben haben, denn so wie Holt schon erwähnt ist dies bei solchen Datenspeicher wie Festplatten oder optische Medien schon ewig üblich, da dort eben häufig mit Fehlern zu rechnen ist.
So wie pumuckel es erwäht - will man wirklich Gewissheit daß man vor einem Single Bit Error geschützt ist muß die ganze Kette dafür ausgelegt sein. ECC RAM ist nur ein Teil davon. Klar schließt man damit zumindest mal den RAM in der Kette aus, aber ob es sinnvoll ist ECC RAM zu nutzen oder nicht muß man für sich alleine auf den RAM bezogen entscheiden. Ob die Speichermedien dahinter nun gut oder schlecht sind haben mit dem RAM nicht viel zu tun.
Also könnte man auch sagen, dass alle nicht über die Funktion bescheid wissen.
Klar, denn es nutzen bestimmt auch jede Menge Workstations und so gut wie alle (echten) Server ECC, das bedeutet aber nicht daß die Nutzer auch wissen wozu es da ist bzw. wie genau man es am besten einsetzt.
"Row Hammer" sagt dir bestimmt auch nichts?
Was hat eine Hacker Methode um eventuell Zugriff auf ein System zu bekommen mit dem Wissen oder Unwissen über ECC und dessen Einsatz zu tun?
Ja - mit ECC kann man wohl einen Row Hammer Angriff eingrenzen. Bis jetzt ist jedoch so viel ich weiß nicht sonderlich viel bekannt ob so eine Methode tatsächlich erfolgreich genutzt werden kann um wo Zugriff zu einem System zu erhalten a) über das man kaum Informationen hat und/oder b) keinen Physischen Zugriff hat.
Je größer die Daten z.B. eine Blue-Ray Disc umso größer ist die Wahrscheinlichkeit, dass ein Bit kippt.
Spiele sind inzwischen bei weit über 50GByte also auch hier können korrupte Daten zum Problem werden.
[/QUOTE]
Das "kippt" in dem Sinn dann auch nicht, sondern ist eventuell schon falsch geschrieben oder wird falsch gelesen. Dazu gibt es wie schon erwähnt Prüfsummen und Fehlerkorrekturen die es gerade bei so etwas wie optische Medien schon ewig gibt.
Ob es jetzt deswegen Sinn macht ECC für Gaming zu nutzen nur weil die Spiele größer werden und somit mehr Daten im RAM verarbeitet werden müssen?
Gerade bei den vielen Daten sind es bei Spielen wohl am ehesten Texturen oder vielleicht Sound/Musik Daten, wenn da ein Bit kippt fällt das wohl gar nicht auf. Klar, wenn es an der falschen Stelle passiert kann gerne mal ein Spiel abstüzen oder glitchen, in den letzten 26 Jahren die ich an eigenen Spiele PCs spiele ist mir der Bedarf an ECC jedoch noch nicht aufgefallen. Und der Sprung von 1 MB zu 16 GB RAM und einigen zig kB bis zu >= 50 GB die die Spiele benötigen hat sich da schon einiges getan.
Abschließend zu eben Sinn und Unsinn ... JA - auf der einen Seite macht ECC RAM natürlich immer Sinn denn Fehlerkorrekturen sind immer gut. Auf der anderen Seite erhöht ECC etwas die Kosten und ist vielleicht nicht immer notwendig. Also im Endeffekt wäre es schön dem Kunden die Wahl zu lassen, was jedoch leider nicht immer der Fall ist.
@Sir Diablo
Welchen Zusammenhang verstehts du den genau nicht?
Der VLC Player kann z.B. auch Korrupte Medien Dateien erkennen und reparieren, es geht also auch mit der "Software".
Der Fall VLC ist schon wieder eine ganz andere Geschichte. Hat auch noch viel weniger mit ECC (RAM) zu tun. Soviel ich weiß kann der VLC auch keine korrupte Daten reparieren (= wieder in den korrekten Ursprungszustand versetzen), sondern lediglich den Index/Keyframes neu aufzubauen um eine Datei abspielbar zu machen. Fehlende/Falsche/übersprungene Daten bleiben jedoch erhalten.
Und Sir Diablo hat nicht unrecht ... Du springst von ECC RAM zu Prüfsummen u.A. bei Datenspeicher wie HDDs und optische Medien und dann zu Software Methoden um korrupte Daten abspielbar zu machen.
Nö, man muss nix hoffen/glauben oder sonst was. Dieses Board unterstützt ECC seit UEFI Version #1. Offiziell, und auch mehrfach bei Gigabyte schon nachgefragt worden...
Aber gegen AMD zu stänkern ist halt normal... ne?
Wo stänkert er in diesem Post über AMD?
Und ja - es ist wie ich schon erwäht habe etwas komisch wie GigaByte das beschreibt bzw. "bewirbt".
Ich dachte der Threadripper hat 64 lanes? Zumindest steht das sonst überall.
Ja - angeblich hat Threadripper 64 Lanes, und besteht aus zwei 8 Core Zen DIEs welche auch in aktuellen RyZen Modellen am Sockel AM4 verwendet werden. Jeder dieser DIEs soll angeblich 32 Lanes haben, wovon am AM4 allerdings nur 16 + 4 für PCI-E Lanes nutzbar sind. 16 für ein oder mehrere PCI-E Karten und die 4 für z.B. M.2 oder GPP - sprich (einen) weitere
Slot(s).
Auf einigen X399 Mainboardbeschreibungen auf Messen war zu lesen "up to 64 PCI-E Lanes". Irgendwie muß der Chipsatz ja auch angebunden werden, allerdings kann der auch wieder PCI-E Lanes zur Verfügung stellen.
Da müssen wir uns also noch gedulden um zu sehen wie viele denn tatsächlich vorhanden/nutzbar sind. Ist vielleicht je nach Board etwas unterschiedlich.