Was auch logisch wäre, da der IMC diesen hohen Takt nicht mitmacht, von A-Data sind schon DDR5 12600 "angekündigt", dafür reicht ein Teiler absehbar nicht mehr.
Alder Lake: Blockdiagramm zeigt umfangreiche I/O-Optionen
- Ersteller HWL News Bot
- Erstellt am
Was auch logisch wäre, da der IMC diesen hohen Takt nicht mitmacht, von A-Data sind schon DDR5 12600 "angekündigt", dafür reicht ein Teiler absehbar nicht mehr.
Ich hab mich jetzt bei Intel nicht so sehr damit beschäftigt, aber zumindest bei AMD ist das doch sinnlos, AFAIK muss man schon extreme RAM-Taktraten im 1:2 Modus schaffen, um eine bessere Leistung als mit deutlich niedrigen Taktraten, aber besseren Timings im 1:1 Modus zu erreichen (aktuell bei Zen3 AFAIK DDR4-3800 bis DDR4-4000).
Wie sieht es bei Intel aus?
Wie sieht es bei Intel aus?
Es gibt auch wenige Spiele und Anwendungen die mit Bandbreite skalieren, aber für gewöhnlich ist Gear1 mit niedriger Latenz für Spiele besser.
Ja, natürlich. Der RAM hängt ja am IMC und nicht am Chipsatz. Dennoch wird Man vermutlich den anfangs teuren ddr5 für die Enthusiasten (z690) nehmen und alle anderen bekommen günstigen ddr4.
was den Gear Mode angeht glaube ich, das man ddr5 mindestens im 1:2 Modus oder sogar (falls vorgesehen) mit 1:3 oder 1:4 betreiben wird. Mal gucken.
Ceiber3
Urgestein
Ich bin echt schon sehr gespannt auf die neuen Intel CPU. Cool wer, wenn Intel endlich mal bei allen CPU's ECC Ram erlaubt. Ich mag ohne ECC kein Computer mehr kaufen.
Habe ich nicht mal was gelesen das DDR5 immer ECC hat ? Oder gibt es da auch wieder extra ECC Ram ?
Habe ich nicht mal was gelesen das DDR5 immer ECC hat ? Oder gibt es da auch wieder extra ECC Ram ?
schnitzel1979
Profi
- Mitglied seit
- 10.06.2020
- Beiträge
- 432
freue mich auch, werde aber wahrscheinlich bis Anfang nächsten Jahres warten und dann kaufen falls die Verfügbarkeit gut ist und evtl die Nvidia Super Karten rauskommen
das ist richtig. Dabei jedoch zu beachten.
DDR5 supports normal ECC and in chip ECC. In chip ECC protects against bit flips in chip. Normal ECC protects against bit flips in transportation.
Holt
Legende
- Mitglied seit
- 05.07.2010
- Beiträge
- 29.846
DDR5 erlaubt optional On-Die-ECC, aber es gibt auch weiterhin normales ECC RAM mit mehr Datenbreite und wegen der Subchannels haben die dann sogar 80 Bit Datenbreite, statt der bisherigen 72 Bit, jeweils bei 64Bit (bzw. eben bei DDR5 dann 32 Bit für jeden der beiden Subchannel) Nettodatenbreite. Man wird sehen müssen wie verbreitet dieses On-Die-ECC dann bei den Consumer RAM Riegeln sein wird.
Übrigens wird schon seit DDR4 die Datenübertragung per CRC gegen Fehler abgesichert, wobei allerdings fehlerhafte Übertragungen überholt werden müssen, während man sie mit "echtem" ECC RAM ggf. auch durch die Fehlerkorrektur beheben kann, was dann natürlich schneller geht.
Holt
Legende
- Mitglied seit
- 05.07.2010
- Beiträge
- 29.846
Also ich fände es ganz toll, wenn auch bei Intel die Consumer CPUs künftig ECC RAM unterstützen würden, aber da ja DDR5 sowieso schon On-Die-ECC ermöglicht (optional!. man wird sehen wie viele Riegel dies dann bieten und welcher Riegel dies konkret hat), unterstützen in gewisser Hinsicht alle CPUs die DDR5 unterstützen, dann irgendwie auch ECC. Dies könnte natürlich zu einem Missverständnis führen, denn es ist eben nicht das klassische ECC, welches ja im RAM Controller stattfindet und daher auch RAM Riegel mit mehr Datenbreite als den 64 Bit nutzbarer Daten. Bisher waren es 72 Bit, wegen der beiden Subchannels sind es bei DDR5 nun sogar 80 Bit Datenbreite, also 40 pro Subchannel.
Man wird also sehen müssen, ob bei Intel i7 oder i9 dann wirklich ECC RAM mit diesen 80 Bit Datenbreite wirklich komplett unterstützen, wie man es bisher als ECC RAM Unterstützung versteht. Wobei die Frage ist, wie viel mehr an Sicherheit dies dann bietet, denn schon mit DDR4 wurde ja eine CRC zur Absicherung gegen Übertragungsfehler eingeführt und wenn die Riegel dann selbst eine On-Die-ECC haben, so gewinnt man vielleicht eine höhere Sicherheit vor RAM Fehlern, vor allem fallen aber wohl Leggs im Falle von Übertragungsfehlern weg, denn mit der CRC können Fehler eben nur erkannt, anderes als bei einer ECC aber eben nicht korrigiert werden, weshalb die Übertragung dann wiederholt werden muss bis sie fehlerfrei erfolgt ist.
Man wird also sehen müssen, ob bei Intel i7 oder i9 dann wirklich ECC RAM mit diesen 80 Bit Datenbreite wirklich komplett unterstützen, wie man es bisher als ECC RAM Unterstützung versteht. Wobei die Frage ist, wie viel mehr an Sicherheit dies dann bietet, denn schon mit DDR4 wurde ja eine CRC zur Absicherung gegen Übertragungsfehler eingeführt und wenn die Riegel dann selbst eine On-Die-ECC haben, so gewinnt man vielleicht eine höhere Sicherheit vor RAM Fehlern, vor allem fallen aber wohl Leggs im Falle von Übertragungsfehlern weg, denn mit der CRC können Fehler eben nur erkannt, anderes als bei einer ECC aber eben nicht korrigiert werden, weshalb die Übertragung dann wiederholt werden muss bis sie fehlerfrei erfolgt ist.
Intel hat doch selbst den Consumer i3 die bei CFL Refresh noch ECC Support hatten beim Wechsel auf S1200 den ECC Support gestrichen.
Abgesehen von on Die ECC bei DDR5 wird es klassisches ECC IMHO nur noch bei den Xeons bzw. den Prozessoren für WS/Server oder eventuell noch embedded i3 mit ECC geben.
Abgesehen von on Die ECC bei DDR5 wird es klassisches ECC IMHO nur noch bei den Xeons bzw. den Prozessoren für WS/Server oder eventuell noch embedded i3 mit ECC geben.
Holt
Legende
- Mitglied seit
- 05.07.2010
- Beiträge
- 29.846
Das wäre zwar zu erwarten, aber hast Du einen Beleg für diese Aussage?
Mir fehlen leider noch einiges Infos zu manchen Themen hier:
1. Gibt es irgendwo Doks dazu, daß on-die ECC bei DDR5 das klassiche ECC obsolet macht? Vor allem das 2bit-ECC von AMD? Ich dachte der Weg führt eben ehr dahin das auf einen vernünftigen Stand zu erweitern (?)
2. Weil es wie 5Gb degradiertes 10Gb ist, ist das wohl zu kompliziert gewesen wenigstens 2.5Gb direkt zu verbauen?
1. Gibt es irgendwo Doks dazu, daß on-die ECC bei DDR5 das klassiche ECC obsolet macht? Vor allem das 2bit-ECC von AMD? Ich dachte der Weg führt eben ehr dahin das auf einen vernünftigen Stand zu erweitern (?)
2. Weil es wie 5Gb degradiertes 10Gb ist, ist das wohl zu kompliziert gewesen wenigstens 2.5Gb direkt zu verbauen?
Zuletzt bearbeitet:
Damals bei Sockel 775 gab es mindestens ein Board von Asrock, dass DDR2 und DDR3 Slots hatte. Vielleicht wird es auch so was geben.
Das es sowas gab weiß ich ja. Aber hier liest sich dass so, als könnten alle Z690 DDR4 betreiben.
Das gabs jedenfalls Nie.
Gegenfrage: Warum sollte Intel nachdem ECC für die Consumer/Desktop Prozessoren gerade abgeschafft wurde wieder einführen ?
Das klingt für mich alles andere als plausibel, aber klar, nichts genaues weiß man nicht.
Holt
Legende
- Mitglied seit
- 05.07.2010
- Beiträge
- 29.846
Nicht nur beim S.775, auch bei Skylake gab es noch Boards die DDR3 unterstützt haben. Es waren zwar nur wenige, da DDR4 damals kaum noch teuer als DDR3 war, denn die HEDT Plattform von Intel hat schon vorher DDR4 RAM verlangt. Es gab für Skylake auch Boards die DDR3 und DDR4 Sockel hatte, aber man konnte nur entweder oder verwenden, nicht beides gemischt! Sowas dürften wir nun auch wieder sehen.
Wieso liest sich das so? Es ist gerade bei den mobilen CPU in letzter Zeit nicht ungewöhnlich das verschiedene RAM Typen wie eben gerade DDR4 und LPDDR4 unterstützt werden, letzteres gibt es nur verlötet auf dem Mainboard und es gab eben nie Konfigurationen in denen man verschieden RAM Typen gemischt nutzen konnte. Selbst bei Dual-CPU Boards, bei denen ja jede CPU ihren eigenen RAM Controller hat, kenne ich kein Board welches es jemals erlaubt hätte, da unterschiedliche RAM Arten zu verbauen.
Das ist kein Beleg für eine Aussage! Die Aussage nach der K Modelle ECC RAM unterstützen würden, ist zwar auch nur ein Gerücht, aber wenn man dies widerlegen möchte, dann sollte man dafür zumindest einen Beleg haben und sonst kann man allenfalls Zweifel daran äußern.
Dass on Die ECC nicht das selbe ist wie ECC Unterstützung seitens der CPU dürfte ja wohl klar sein, aber anscheinend nicht allen, die entsprechende Gerüchte in Umlauf bringen..
Da es für einen CPU-Seitigen ECC Support auch keine öffentlich zugänglichen Belege gibt könnte ich genau so dich dazu auffordern, Belege zu bringen, was genau so blödsinnig wäre wie
deine Forderung nach Quellen/Specification Sheets, die das Gegenteil belegen.
Selbst für den einzigen i3 für S1200 der noch ECC Support hatte (10100E/10100TE) gibt es ja wohl keinen RKL Nachfolger.
Hier gibt es übrigens ein erstes Foto vom Z690 PCH.
Laut eines Posts im Thread soll es von ASRock ganze 4 Z690 Boards mit DDR5 Support geben, DDR5 Support soll es hauptsächlich für die Flagship Boards geben.
Da es für einen CPU-Seitigen ECC Support auch keine öffentlich zugänglichen Belege gibt könnte ich genau so dich dazu auffordern, Belege zu bringen, was genau so blödsinnig wäre wie
deine Forderung nach Quellen/Specification Sheets, die das Gegenteil belegen.
Selbst für den einzigen i3 für S1200 der noch ECC Support hatte (10100E/10100TE) gibt es ja wohl keinen RKL Nachfolger.
Hier gibt es übrigens ein erstes Foto vom Z690 PCH.
Laut eines Posts im Thread soll es von ASRock ganze 4 Z690 Boards mit DDR5 Support geben, DDR5 Support soll es hauptsächlich für die Flagship Boards geben.
Zuletzt bearbeitet:
Es gibt nun Xeon E-2300 CPUs, die die wegfallenden Core i3s ersetzen.
Holt
Legende
- Mitglied seit
- 05.07.2010
- Beiträge
- 29.846
Man sollte es dann aber trotzdem als Meinung und nicht als gesicherte Erkenntnis formulieren. Wir sind uns ja einig, dass es ein Gerücht ist, ebenso dass es unwahrscheinlich ist das es sich um die gleiche ECC wie bei den Xeons handelt, sondern dass diese hier vermutlich mit der On-Die-ECC verwechselt wurde.
Das ist zumindest am Anfang wegen der Mehrkosten von DDR5 RAM auch so zu erwarten, da werden sich vor allem diejenigen die wirklich die letzten Prozent an Leistung wollen, auch DDR5 RAM gönnen. Aber je geringer der Aufpreis von DDR5 gegenüber DDR4 wird, umso mehr werden auch die günstigeren Boards mit DDR5 RAM Slots erscheinen. Wobei natürlich abzuwarten ist, in wie weit Intel DDR5 für die ganzen CPUs und Chipsätze auch wirklich freigibt, oder ob es am Ende nicht künstlich nur auf Z690er Boards beschränkt wird.
Reflexion
Enthusiast
- Mitglied seit
- 09.12.2014
- Beiträge
- 205
... es gibt rund um ECC Korrekturen mal wieder etwas was ich nicht verstehe, wenn CRC dafür sorgt, dass Daten bei der Datenübertragung vor Fehler abgesichert werden, wieso ist dann ECC Korrektur überhaupt noch relevant bei ZFS oder btrfs/ReFS..im privaten Segment, logisch es muss alles von neu übertragen werden, kostet Zeit, aber wenn man im privaten auf ein (file)Server setzt ist das doch nicht so schlimm wie sonst immer behauptet.
On-Die-ECC bei DDR5 RAM wirkt als würde man dies nur einsetzen, weil vllt. anders nicht mehr stabil eine Übertragung umsetzbar ist, bei derartigen hohen Takt. Ich Hoffe, dass das auch eine Geschichte ist, die unabhängig vom CPU/Mainboard Chipsatz stattfindet, denn mal abgesehen davon, dass ich auch bei 12gen Celeron/Pentium keine Wiederbelebung zu ECC aktiver Nutzung finde, sind passende 11Gen Xeons nicht erhältlich (warte seit Monaten auf den Intel Xeon W-1350, 6C/12T).
Seitens AMD Ryzen gibt es ganz viele die meinen, dass non pros ECC Korrektur durchlaufen, meist enden die Diskussionen aber schon dabei, dass man ECC IM BIOS gesehen hat und keinen Test in der PShell durchfüht.. Was die "pros" betrifft bin ich auch nicht schlauer, können ja, aber nutzten die Mainboard-Hersteller dies auch aktiv (?). Schade, dass das Thema so in Intels 14nm dreifach + untergeht.
On-Die-ECC bei DDR5 RAM wirkt als würde man dies nur einsetzen, weil vllt. anders nicht mehr stabil eine Übertragung umsetzbar ist, bei derartigen hohen Takt. Ich Hoffe, dass das auch eine Geschichte ist, die unabhängig vom CPU/Mainboard Chipsatz stattfindet, denn mal abgesehen davon, dass ich auch bei 12gen Celeron/Pentium keine Wiederbelebung zu ECC aktiver Nutzung finde, sind passende 11Gen Xeons nicht erhältlich (warte seit Monaten auf den Intel Xeon W-1350, 6C/12T).
Seitens AMD Ryzen gibt es ganz viele die meinen, dass non pros ECC Korrektur durchlaufen, meist enden die Diskussionen aber schon dabei, dass man ECC IM BIOS gesehen hat und keinen Test in der PShell durchfüht.. Was die "pros" betrifft bin ich auch nicht schlauer, können ja, aber nutzten die Mainboard-Hersteller dies auch aktiv (?). Schade, dass das Thema so in Intels 14nm dreifach + untergeht.
CRC schützt doch nur die Übertragung, ECC schützt den Zustand im Speicher! D.h. ohne ECC merkt man gar nicht, dass es Bitflip im Speicher gab. CRC schützt davor, dass während er Übertragung ein Bit verändert wird. Beides zusammen ist sinnvoll und wichtig, um das System zu schützen.
Reflexion
Enthusiast
- Mitglied seit
- 09.12.2014
- Beiträge
- 205
Danke Dir.. ..warum wird dann auf On-Die-ECC +ECC Wert gelegt, ersteres wäre dann ja überflüssig.
Holt
Legende
- Mitglied seit
- 05.07.2010
- Beiträge
- 29.846
Bei einem Filesystem ist das etwas anderes als bei RAM, aber HDDs (und auch SSDs) haben am Ende jedes Sektors eine eigene ECC und schicken keine falschen Daten, sondern einen Lesefehler, wenn sie es trotz wiederholter Versuche nicht schaffen die Daten korrekt zu lesen. Es liegt dann an der Anwendung die den Lesebefehl geschickt hat, was sie daraus macht, aber wenn der Lesebefehl von einer RAID Lösung (SW-oder HW RAID, aber kein RAID 0) kommt, dann wird das RAID die Daten von den anderen Platten und der Parität wiederherstellen, den problematischen Sektor überschreiben und die korrekten Daten nach oben an die Anwendung weiterreichen. Die zusätzliche ECC im Filesystem sichert dann nur noch dagegen ab, dass die RAID Lösung da einen Fehler macht, etwa durch einen Bug in der FW eines HW RAID Controllers.
Nein, nicht die Übertragung, die wird schon seit DDR4 mit einer CRC abgesichert, eben mit dem Zeitverlust durch Wiederholung der Übertragung bei Fehlern, sondern wohl wegen der kleineren Strukturen der DRAM Zellen, die offenbar nun so problematisch geworden sind, dass es eben zu oft zu Fehlern kommt und man daher On-Die-ECC eingeführt hat.
Ja, deswegen heißt es ja On-Die-ECC, weil es eben auf dem Die stattfindet und nicht im RAM Controller, der bei neueren CPUs schon lange in der CPU sitzt. Der Chipsatz hat damit also nichts zu tun, außer das eben bei Intel geschaut wird welcher Chipsatz vorhanden ist und wenn es der falsche ist, wird die ECC Funktion des RAM Controller eben einfach nicht aktiviert. Genau wie bei anderen Funktionen wie der Aufteilung der 16 PCIe Lanes für die Graka, die auch nur mit dem passenden Chipsatz möglich ist, obwohl diese PCIe Lanes direkt von der CPU kommen und mit dem Chipsatz direkt gar nichts zu tun haben.
Die klassische ECC gibt es ja weiterhin, jetzt wegen der Subchannels sogar mit 80 Bit statt vorher 72 Bit Datenbreite der Module und die wird sicher auch stärker als die On-Die-ECC sein. Stärker bedeutet, dass unerkannte und unkorrigierbare Fehler weniger wahrscheinlich sind und es gibt ja schon heute unterschiedlich starke ECC Implementierungen, von denen die einfachsten bisher nur Singlebitfehler korrigieren können. Keine Ahnung wie stark die On-Die-ECC bei DDR5 so ist, dazu habe ich bisher noch nichts gefunden und natürlich erspart die ECC im RAM Controller die erneute Übertragung bei RAM Fehlern und man erfährt von den Bitfehlern im RAM auch nichts, da diese ECC ja im Die passiert und damit für den Rechner komplett transparent.
Persönlich hätte ich bisher auch als nächsten Rechner oder Heimserver nur an einen Xeon gedacht, aber mit On-Die-ECC DDR5 könnte ich auch leben, da hat man ja einmal die ECC im Die gegen Bitfehler im RAM und dann die CRC bei der Übertragung gegen Übertragungsfehler. Genau wie im Beispiel der ECC in Filesystemen mit denen wir angefangen haben, hast Du damit nur noch das Risiko ob das auch auf beiden Seiten, also nicht nur beim RAM Controller sondern auch im RAM selbst, korrekt implementiert ist. Bei der klassischen ECC musst Du hingegen nur darauf vertrauen das der RAM Controller diese korrekt ausführt und bei den Xeons würde ich da viel mehr Vertrauen in Intel als jeden einzelnen der Vielzahl von Anbietern von RAM Riegeln haben. Genau wie man bei ZFS, btrfs, ReFS. etc. eben nur darauf vertrauen muss, dass diese die ECC korrekt handhaben und nicht auch jede HDD und der ggf. vorhanden RAID Controller, wobei SAS Lösungen da besonders kritisch sind, da die HW RAID Controller SAS Platten gerne auf 520/528 Byte pro Sektor formatieren um dann in den zusätzlichen Bytes eine eigene ECC abzulegen und dann lassen sie sich beim Lesen direkt die Rohdaten (also ohne deren eigene ECC ) von der Platte geben. Dies vermeiden Verzögerungen durch Versuche der Platten die Daten durch wiederholte Versuche doch noch korrekt zu lesen, der RAID Controllern kann bei Lesefehlern sofort anfangen die Daten der anderen Platten und die Pariy zu lesen um die korrekten Daten wiederherzustellen, aber wehe wenn da ein Bug in dessen FW ist und genau dagegen sichern dann Filesysteme mit eigener ECC ab. Oder eben bei SATA Platten ein Bug in der FW der dafür sorgt, dass doch korrupte Daten geliefert werden, aber das war meines Wissens zuletzt vor mehr als 10 Jahren bei den F4EG der Fall, wo der Cacheinhalt verändert werden konnte, wenn ein ATA IDENTIFY DEVICE Befehl geschickt wurde.
Wer legt darauf Wert? Bisher gibt es nur Alder Lake und davon auch nur die Consumer CPU (und auch nur die K Modelle) ohne ECC Funktion im RAM Controller und damit auch noch gar keine DDR5 ECC RAMs zu kaufen. Ob diese DDR5 RAM Riegel dann auch eine On-Die-ECC haben werden, ist also noch offen. Aber selbst wenn, die CRC hat halt den Nachteil, dass man bei Fehlern die Übertragung wiederholen muss, was ein Performancenachteil ist, erst recht wenn viele Wiederholungen nötig sind bis die Daten korrekt übertragen wurden.
