Ram Takt höher als FSB sinnvoll ?

[grueni]

Lt. Commander
Registriert
Okt. 2008
Beiträge
1.293
Ich bin leicht verwirrt ^^
Beim durchstöbern mancher Sysprofile habe ich doch den einen und anderen getroffen der meinte seinen Ram bis ans Limit zu übertakten zu müssen zB OCZ 800er auf 910 Mhz. Allerdings lag der FSB bei knapp 410. Worin besteht da der Sinn ? Oder habe ich etwas verpasst ^^ ? Ich bin der Ansicht besser als 1:1 geht doch nicht oder :freak:
 
Ram-Takt 1:1 ist der Beste, asynchrone Taktung führt sogar zu Leistungseinbußen.
 
asynchroner ram is völlig banane und brignt circa so viel wie multi color led lüfter :)
 
in der theorie erweitert es halt die bandbreite des speichers,....was aber ausser für den virtuellen schwanzvergleich nix bringt
 
Diese Frage entfacht manchmal einen Glaubenskrieg.
Die Antwort ist, es kommt drauf an. WinRAR profitiert gut von einem OC-RAM. Die Datendurchsätze von Everest lesen sich auch dergestalt, dass vor allem beim "read" mehr durchkommt.
Ansonsten bringt das OC des RAM ca. 3% bis 10% mehr fps, je nach Game.
Bezogen auf 30 fps sind das gerade mal 3 mehr; wenn Du 90 fps hast, kriegst Du noch 9 dazu. Nur: Die 9 fps zusätzlich wirst Du nicht merken und die 3 fsp machen den Kohl auch nicht fett.
Wenn ich aber von meinem persönlichen "Glauben" reden darf; mir macht es Spaß aus den teueren PC-Komponenten die letzten Promille Leistung rauszuholen.
 
Zuletzt bearbeitet von einem Moderator:
haste benchs die deine 3-10% belegen? würde mich mal interessieren, aber bin zu faul es selber zu testen ^^
 
Was ich nicht so ganz verstehe wie zB Winrar von Ram OC profiitert ?
Ich sehe das so: FSB Sys is der Motor und der RamTakt die Reifen:
Die Reifen machen 200km/h mit der Motor schafft aber nur 150km/h max.
Wie kann ein Prog von etwas profitieren,welches das System gar nicht ausnutzen kann^^

Bissl umständlich aber vllt versteht wer was ich meine ;):)
 

Die Latenzen des Ram steigen wenn dieser schneller getaktet ist. Auch wenn der FSB darunter liegt. Viel bringts nicht. Höherer FSB hat mehr Vorteile...
 
Zuletzt bearbeitet von einem Moderator:
[QUOTE='[grueni]Zitat entfernt.[/QUOTE]




ja das frag ich mich auch. bei läuft läuft far cry 2 mit standarttakt und 1000 mhz ram ganze 5 fps schneller wie auf 3000 mhz übertaktet und 800 mhz ram (FSB:Ram = 1 :1). schon komisch der mist!

o5i schrieb:

dann sollten alle die nen fsb1333 haben einen 667 mhz speicher nehmen? alleine mit dem 800er ist es nicht mehr 1:1.
 
Zuletzt bearbeitet von einem Moderator: (Beiträge zusammengeführt.)
stas_mueller schrieb:
ja das frag ich mich auch. bei läuft läuft far cry 2 mit standarttakt und 1000 mhz ram ganze 5 fps schneller wie auf 3000 mhz übertaktet und 800 mhz ram (FSB:Ram = 1 :1). schon komisch der mist!

Tja da sieht man echt warauf einzelene Spiele/Progs etc. Wert legen....
Und 5fps sind schon erschreckend finde ich^^
 
@Grueni
Kommt auf die Referenz an.
5 FPS bei 500 oder 5 FPS bei 20 :-)
Bei CPU-Limit in 800x600 oder bei GPU-Limit in 2560x1600?
 
Zuletzt bearbeitet:
Die Auffassungen, asynchroner RAM sei "völlig Banane" oder führe sogar zu Leistungseinbußen, halte ich für nicht richtig. Mir ist jedenfalls kein einziges Testverfahren bekannt, das eine solche Behauptung stützen könnte.
Ich selber habe mit zahlreichen Testverfahren zeigen können, dass ein übertakteter RAM einen -marginalen- Leistungszuwachs bringt. Sodann habe ich versucht, auch den physikalischen Hintergrund beim Zusammenspiel der PC-Komponenten zu verstehen. Dieses Zusammenspiel der Komponenten funktioniert nach dem folgenden Ablauf:

1. Die CPU verlangt nach Daten und sucht zunächst im Cache Level 1 und 2.
2. Da der Cache bei den heutigen CPUs sehr groß ist, werden die gesuchten Daten dort oft gefunden. Eine Verarbeitung kann in weiteren Schritten erfolgen.
3. Falls die benötigten Daten aber nicht im Cache gefunden werden (Cache-Miss-Hits), geht die Datenabfrage weiter an den Memory-Control-Hub (MCH) der North-Bridge. Dort wird die CPU-Datenabfrage in geeignete Befehlssequenzen mit benötigten RAM-Lese-Adressen übersetzt.
4. Die Befehlssequenzen werden sodann von der North-Bridge zu den RAM-Bänken gesandt.
5. Wenn der Zugriff auf die RAM-Bänke komplett erfolgt ist, und die Daten für die Übermittlung zum MCH gepuffert sind, werden sie zur North-Bridge zurück gesandt.
6. Die MCH führt jetzt das "Clock-Crossing-Procedure" durch, d.h. die Daten, die vom Memory-Bus kommen, werden in den System-Bus (FSB) überführt. Damit wäre die Datenabfrage der CPU beantwortet und erledigt.

Dieser Ablauf dürfte als physikalische Tatsache unstreitig sein. Dabei spielt es noch keine Rolle, in welchem Verhältnis der FSB zum RAM getaktet ist. Da gleichwohl ein geringer Leistungszuwachs beim RAM-OC messbar ist, eröffnet sich die Frage nach der Ursache.
Hierzu muss der Memory-Bus und der FSB näher in Bezug auf das oben beschriebene "Clock Crossing Procedure" untersucht werden. Zur Veranschaulichung möchte ich den von mir bevorzugten DRAM:FSB-Teiler von 4 zu 3 darstellen:

1. Der FSB (Datenbus) läuft mit drei Zyklen, also 0, 1 und 2.
2. Der Memory-Bus läuft mit vier Zyklen, also 0, 1, 2 und 3. (Die Null bitte jeweils mitzählen, dann sind es beim FSB drei und beim RAM vier Zyklen).

Ich beginne mit dem Memory Bus im Zyklus 0.

3. Der MCH überführt die vom Memory-Bus im Zyklus 0 erhaltenen Daten in den FSB-Zyklus 1, danach werden im Memory-Zyklus 1 vom RAM erhaltene Daten in den FSB-Zyklus 2 überführt und schließlich vom Memory-Zyklus 3 in den FSB-Zyklus 0 überführt. Damit wäre der 3er Rhythmus des FSB beendet und beginnt von vorne. Doch was ist mit dem 4er Zyklus des RAM, es fehlt doch noch der vierte Zyklus?
4. Da der FSB-Zyklus wieder bei 0 beginnt, aber der Memory-Zyklus noch nicht beendet ist (er läuft ja asynchron zum FSB) und noch ein Datenpaket des Memory Zyklus 3 (das wäre dann das Vierte, denn 0, 1, 2, 3 sind insgesamt 4 Zyklen) bereit steht, wird es zusammen mit dem Datenpaket vom Memory-Zyklus 2 in den FSB-Zyklus 0 überführt.

Dadurch ist der MCH ist Lage, in einem schnelleren Zyklus Daten für die CPU bereit zu stellen. Denn der oben beschriebene Weg von der CPU zum MCH zum RAM und wieder zurück dauert "eine gewisse Zeit". In dieser Zeit wäre die CPU aber ist der Lage, weitere Daten zu verarbeiten. Die "Wartezeiten" der CPU werden besser ausgenutzt, wodurch sich der Datendurchsatz beim "read" erhöht.
Ein kleiner Screenshot für die Ungläubigen ganz unten; einmal FSB von 450 MHz, Teiler 4:3 sowie FSB 500 MHz Teiler 1:1.
Außerden eine grafische Darstellung der 4:3 FSB/RAM-Takte.
Ich hoffe, ich habe mich verständlich ausgedrückt. Für Anregungen und Kritik bin ich dankbar.
 

Anhänge

  • cachememRAmpage0308strongerFSB450.png
    cachememRAmpage0308strongerFSB450.png
    206,6 KB · Aufrufe: 656
  • cachememFSB500.png
    cachememFSB500.png
    206,4 KB · Aufrufe: 646
Zuletzt bearbeitet von einem Moderator:
Moin

Super Erläuterung!!
Besser kann man es glaube ich nicht mehr erklären.
 
Wow cool ;) Sowas hatte ich mir auch schon gedacht das halt die Daten geouffert bereit gehalten werden für den n. Takt, aber das bedeutet ja das der letzte Takt der CPU (FSB) keine Daten bekommt, weil 1 Takt weniger vorhanden ist als beim Ram.


Aber super Erklärung :)
ThX a lot:)
 
Es freut mich, wenn ich Euch etwas rüber bringen kann. Zwar ist das Thema zu komplex, um es mit ein paar Zeilen füllen zu wollen, aber am zweiten Weihnachtstag bin ich für eine Zugabe über den synchronen bzw. asynchronen Bus gerne bereit:
Der synchrone Bus hat auf einer separaten Taktleitung ein Taktsignal. Es wird von einem Schwingquarz stabilisiert und formt den Zeitrhythmus für alle Vorgänge auf dem Bus. Dieses Taktsignal ist ein symmetrisches Rechtsecksignal mit einer Taktfrequenz f.
Jenes sich wiederholende Signalstück des Taktsignals (LOW-Phase zuzüglich HIGH-Phase) bildet einen Taktzyklus oder einfach Takt. Ein solcher Takt dauert eine Taktzykluszeit T=1/f. Bei einem angenommenen FSB von 400 MHz dauert also ein Taktzyklus T= 1/40 hoch 8 = 2,5 Nanosekunden (1 Nanosekunde ist eine milliardstel Sekunde). Dass nicht alle Komponenten dieses Tempo mithalten können, liegt auf der Hand. Allerdings orientieren sich die angeschlossenen Komponenten am Taktsignal und alle Zeitbedingungen sind relativ zu diesem Taktsignal beschrieben. Die "Zeitbedingungen", also das Timing, sind sehr kompliziert. Soweit z.B. festgelegt ist, dass ein Speicherbaustein in der ersten Hälfte des Folgetaktes nach der Datenanforderung durch ein Read-Signal die Daten bereitzuhalten hat, der Speicherbaustein jedoch zu langsam ist, muss die Speichersteuerung einen Wartetakt (Waitstate) einlegen. Dieser Waitstate ist entweder durch ein Signal des Bausteins ausgelöst oder er ist in der Speichersteuerung bereits einprogrammiert.
Da sich die Hersteller von Komponenten an diese Buseigenheiten halten, gibt es von da her keine Probleme, außer die Speichermodule haben ein nicht exaktes Timing (bzw. der User verursacht ein solches durch eine nicht stimmige BIOS-Einstellung).
Aus diesem Grund ist der synchrone Bus auch verbreitet und grundsätzlich stabil.
Doch wozu dann einen asynchronen Bus-Takt?
Ist ein Speichermodul in der Lage, angeforderte Daten nach 4,1 Taktzyklen auszugeben, sind aber 5 Taktzyklen erforderlich, weil jeder Vorgang immer eine ganze Anzahl von Taktzyklen braucht (wenn z.B. durch eine Busspezifikation ein Bus immer drei Zyklen zu je 10ns beim Auslesen eines RAM-Moduls benötigt), würde ein schnelleres RAM-Modul keine Verbesserung bringen, weil das feststehende Busprotokoll dieses RAM-Modul genauso schnell ansteuert, wie das langsamere RAM-Modul.
Durch die Verwendung des asynchronen Busses werden diese Nachteile ausgeglichen, denn der asynchrone Bus verzichtet auf das Taktsignal und arbeitet bei allen Busvorgängen mit Synchronisations und Bestätigungssignalen, den sogenannten Handshakes.
Bei einem Lesezugriff auf einen Busbaustein legt der Busmaster, das ist die CPU, die Adresse und die Anforderungsignale auf den Bus. Der angesprochene Baustein, der Slavebaustein, erkennt diese Signale und beginnt damit, die abgefragten Daten bereitzustellen. Falls die angefragten Daten vorhanden sind, wird dies vom Baustein durch ein Bestätigungsignal angezeigt. Die CPU liest die Daten und nimmt das Anforderungsignal zurück. Im Gegenzug nimmt der Slavebaustein sein Bestätigungsignal zurück und ist für den nächsten Transfer bereit. Im Gegensatz zum synchronen Bus können alle Bustransfers eine beliebige Zeit in Anspruch nehmen, denn der asynchrone Bus ist ereignisgesteuert (und eben nicht zeitgesteuert wie der synchrone Bus).
Deshalb gibt es beim asynchronen Bus (abgesehen von den Handshake-Signalen) keine Wartezeiten. Daraus folgt, dass ein schnellerer Speicherchip den Bus sofort schneller zum Laufen bringt- und daraus folgt wiederum (mögen es manche auch nicht hören wollen), dass der asynchrone BUS dem synchronen BUS überlegen ist. Daran ändert auch der zusätzliche Aufwand durch die Handshakes nichts.
Wer noch etwas über das Verhältnis des RAM/FSB zum Performance-Level lesen möchte, der kuckt hier: https://www.computerbase.de/forum/t...eme-intel-x38-x48.380113/page-64#post-4620553
 
Zuletzt bearbeitet von einem Moderator:
Cool das nenn ich mal ne ausführliche Antwort :D
Schön und auch gut verständlich =)

Aber mal nebenbei ^^
Woher weis man sowas alles Oo:D
 
Zurück
Oben