News Gigabyte Aorus RGB: „Memory Boost“ hebt DDR4-RAM eine Taktstufe an

scooter010 schrieb:
Werden diese aus dem Slot gespeist (Energie/Information)?

Ja werden Sie.

scooter010 schrieb:
Wenn ja, über dedizierte Pins

Nein, es ist gant normaler DDR4-RAM.

scooter010 schrieb:
Speicherbereich für RGB reserviert (aka MMIO) oder wie läuft das?

Da man dafür eine Software benötigt läuft das denek ich so ab:

1. Man stellt Farbe X und Leuchtmodi in der SW ein.
2. Beim speichern wird dies in einen Bereich des RAMs gespeichert, der Frei ist.
3. Dem RGB-Controller wird gesagt, "ey, scann man Bereich X-Y da findest du neue Infos".
4. Der Controller findet den "code" und speichert diesen bei sich im EPROM ab.
 
icetom schrieb:
am besten noch auf den eigenen Boards einen Turbo Knopf auf die Gehäusevorderseite führen. wie früher mit cpus :D

Quirin_1 schrieb:
Bring die nicht noch auf solche Ideen.🤣

Gibt es immer wieder. Beschränkt sich bisher aber nur auf Notebooks. Übertaktung auf Knopfdruck. Nennt sich aber nicht immer "Turbo".
MSI hatte auf jeden Fall mal Modelle mit einem Turbo Knopf.

Rickmer schrieb:
Wird dabei auch der Infinity Fabric automatisch auf 1866 MHz angehoben? Weil sonst ist's eher sinnlos...
Nur wenn die CPU das mitmacht, sonst hast du Pech gehabt.
 
Dummy Dimms also. Wir haben auch noch nicht genug Erdöl verbraucht.

Nettes Ding allerdings für den eBay-Scammer des Vertrauens. 💁
 
  • Gefällt mir
Reaktionen: lkullerkeks
Cool Master schrieb:
Dem RGB-Controller wird gesagt, "ey, scann man Bereich X-Y da findest du neue Infos".
Soweit, so logisch. Bleibt die Frage, über welche Pins/Protokoll dieser RGB Controller angesprochen wird. Schließlich kann der ja nur "echte" Adressen lesen und die Software unter Windows kann prinzipbedingt nur virtuelle Adressen sehen. Also muss es neben den reinen Datenaustausch Leitungen auch noch Verwaltungsleitungen geben (muss es eh, woher soll das MB sonst das XMP Profil her bekommen oder die Bezeichnung/Spezifikationen des Speichers), wo die JEDEC festgelegt hat, dass darüber neben technischen Informationen auch Hersteller spezifische Informationen drüber laufen dürfen, gesteuert vom Betriebssystem über eine API die vom RGB Softwaretreiber angesprochen wird.
 
@scooter010

Die Infos die du ansprichst (XMP, Timings, JEDEC usw.) kommen aus dem Serial Presence Detect (SPD). Der RGB-Controller kann direkt über den RAM angesprochen werden, da dort ja Datenleitungen hingehen. Das muss aber wie gesagt jeder Hersteller selber mit seiner Software programmieren, außer man setzt auf ein "Standard" der auf div. Boards vorhanden ist. Also so etwas wie AuraSync oder ähnlich. Dann kann dies direkt vom Motherboard gesteuert werden. Das ist dann aber keine RAM-Hersteller Lösung mehr sondern der RAM-Hersteller muss sich an die Vorgaben des MoBo-Hersteller halten. Wobei das gleiche Prinzip noch gilt. Die Datenleitungen sind ja schon da sie werden nur auf einer anderen Eben (UEFI) angesprochen.
 
Das Problem was ich meine, ist folgendes: Software kann unter Windows nicht gezielt auf physische Adressen schreiben, wegen der Speichervirtualisierung. Wie soll nun der RGB Controller im RAM diese Information finden bzw. gesagt bekommen? Alle "normalen" Schreib- und Lesezugriffe im RAM münden ja in einem Schreib- oder Lesevorgang auf einem Speicherchip, nicht im Eingang des RGB Controllers. Dieser kann auch unmöglich unterscheiden, ob ein Byte jetzt für ihn bestimmt ist oder für den Speicherchip. Auch eine spezielle Bytesequenz kann nicht genutzt werden, Virtualisierung. Wer sagt, dass zwei Byte, nur weil virtuell fortlaufend auch physisch fortlaufende Adressen haben? Ist zwar wahrscheinlich aber nicht garantiert.
 
@scooter010

Ist zwar schon etwas her, dass ich unter Windows programmiert habe aber ich würde das mit einem Pointer lösen, damit sollte es in der Theorie machbar sein. Aber wie gesagt ich hab keine Ahnung wie das aktuell laufen würde unter Windows 10. Ich hab das letze mal 2012 oder so unter Windows programmiert daher kann ich nicht sagen wie sich das OS verhält.
 
Pointer gehen hier nicht. Speicher (also auch die Adressen in Pointer) sind virtualisiert und werden durch die Memory Management Unit der CPU in physische Adressen übersetzt. Ergo hat die im Pointer gespeicherte Adresse nichts mit einer tatsächlichen Adresse zu tun. Die Adresse im Pointer ist auch nur im Kontext der jeweiligen Anwendung gültig. Eine andere Anwendung kann theoretisch auch einen Pointer haben, der die identische Speicheradresse enthält. Trotzdem wird diese Adresse durch die MMU auf eine andere physische Adresse übersetzt. Nur das Betriebssystem kann im Kernel Mode direkt physische Speicheradressen ansprechen, was auch für viele Hardwareinteraktionen (Stichwort Memory Mapped I/O, AcPI) erforderlich ist.
 
  • Gefällt mir
Reaktionen: LukS
Hmm, wäre interessant wenn wir einen Takt 4000+ hätten. Das bischen kann man doch bei jedem billig RAM übertakten.
 
  • Gefällt mir
Reaktionen: ITX17x17
Optisch sehen die Top aus, mal was anderes als immer nur "G'SKILL Trident Z" die Timings die Gigabyte angegeben haben sagt nicht viel über das was mit OC machbar ist, Samsung B-Die's ist das beste für OC mit schönen Timings und niedrigen Latenzen, aber wenn der Preis stimmt wird der auch mit Hynix oder Micron gekauft, CJR & E-Die sind die guten günstige OC-Die

Den RAM würde ich gerne testen, ein Test Sample bitte an mich schicken 😃
 
Zuletzt bearbeitet:
Zurück
Oben