Ram Takt höher als FSB sinnvoll ?

wow super beschreibung, hab zwar noch nich alles verstanden aber das mag an der zeit und meinem zustand liegen ;) ... werde das morgen nochmal genauer studieren.

Aber mal nebenbei ^^
Woher weis man sowas alles Oo :D

da gibs mehrere möglichkeiten ... z.b. e-technik studiert oder einfach nur interesse und es sich angelesen :)
 
Aber klar doch, schau in den Anhang!
Sie sind gegenüber den OC-Settings geradezu erbärmlich, oder?
 

Anhänge

  • cachememDefaultBIOS-Settings.png
    cachememDefaultBIOS-Settings.png
    205 KB · Aufrufe: 554
danke,mh das ja nich die Welt da haben meine 7090mb lesen

wie isn bei dir @fsb 333 dann die trd Phase?

mein ds3 setzt die im turbomodus auf 1 dann hab ich 7090mb lesen wenn ich die perfomance enhance option auf standart stell hab ich ne trd phase von 29 und dann auch "nur" 6500mb lesen.
 
Erstmal zur reinen Begrifflichkeit synchron/asynchron: FSB und Speicherbus - und das ist das Thema des Threads - laufen _immer_ synchron zueinander. Auch bei 5:4 oder einem anderen "schiefen" Taktverhältntis laufen beide stets synchron zueinander. Es gibt eine gemeinsame Taktbasis, aus der beide Seiten ihren (Sub-)Takt erzeugen. Die beiden Seiten laufen nie auseinander und müssen daher nie durch irgendwelche zusätzlichen Mechanismen in "Einklang" gebracht werden. Die Transfers sind einzig und allein durch in starren Taktzahlen beschriebene Timings spezifiziert. Es gibt keinerlei Feedback der Art: "Ich bin nun fertig, kannst die den bestellten Kram jetz abholen". Stellt man die Timings zu eng ein, stürzt die Kiste eben ab. Ganz einfach.

Vielleicht hilft das: Die 3 nicht tickenden sondern mit konstanter Winkelgeschwindigkeit drehenden Zeiger einer idealen Uhr laufen auch synchron, nur eben mit unterschiedlicher Drehzahl.

Der Großteil von HeinzNeus Erläuterungen zu tatsächlich asynchronen Verbindungen, insbesondere sein kompletter 2. langer Beitrag, geht hier völlig am Thema vorbei, da solche asynchronen Transfers beim hier diskutierten Speicherzugriff gar nicht vorkommen - weder beim Zugriff auf den Speicher selbst noch beim Übergang Speicherbus<-->FSB. Was er da von Handshakes und Bestätigungssignalen erzählt, hat nichts mit der Realität des Speicherzugriffs auf Intels Systemen mit FSB zu tun. Intels Hardware arbeitet nicht so, wie er im 2. Beitrag hier erzählt. Dummerweise ist dieser Teil nicht nur off topic sondern auch noch inhaltlich weitgehend falsch - kein Wunder wenn man Vorzüge asynchroner Transfers an einem nichtexistenten Beispiel zu erläutern versucht.

Auch sein Fazit ist Humbug:
HeinzNeu schrieb:
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.
Daß diese asynchrone Methode mit Handshake gar nicht stattfindet, hatten wir geklärt. Weiterer Unsinn ist "keine wartezeiten außer bei Handshake". Auch bei asynchronen Transfers zwischen zwei (unsynchronisiert) getakteten Systemen treten selbstverständlich Wartezeiten auf, da immer nur zu den Zeitpunkten der Taktflanken aktiv was passiert und darauf gewartet werden muß. Weiterhin ist es grober Unfug, einen asynchronen Bus einem synchronen Bus als grundsätzlich überlegen hinzustellen, insbesondere wenn man mit dem Argument "schneller" kommt. Es ist kein Zufall, daß es eine Menge synchroner Techniken in allen möglichen Bereichen gibt, in denen sehr schnelle Transfers stattfinden. Im kleinen (z.B. Speicherzugriff), wo die Synchronisation sehr einfach ist, ist das leicht nachvollziehbar. Doch selbst in riesigen, schnellen Systemen (z.B. SDH/Sonet) nutzt man gern synchrone Transfers, obwohl dort die Synchronisation alles andere als einfach ist.

Zurück zum Thema:
Die Frage "Ram Takt höher als FSB sinnvoll" läßt sich jedenfalls nicht mit "Klar doch, weil höherer Ramtakt = schneller" beantworten. Es muß insgesamt passen. Die Kombination RAM-Takt, RAM-timing, MCH-Konfiguration und FSB-Takt muß zueinander passen:
FSB-Takt und tatsächliche Fähigkeiten des Speichers oder der Restlichen Hardware stehen meistens fest. Unter diesen gegebenen Bedingen kann man für jeden Rechner einen idealen Punkt für FSB:RAM-Verhältnis (und damit RAM-Takt), RAM-Timing und MCH-Timing ermitteln. Dabei ist keineswegs immer der höhere RAM-Takt besser.

Rein praktisch reicht es aus, sich nur um die 3 Parameter FSB:RAM-Verhältnis, CL des RAMs und Trd der Northbridge (aka Performance Level) zu kümmern. Alle anderen Stellschrauben (weitere Timings, Spannungen, ...) sind für sich allein betrachtet unwichtig, dienen aber dazu, ggf. bei einem der 3 genannten wichtigen Parameter noch was rauszuholen. Die anderen Stellschrauben sind also nur über diesen Umweg interessant. Man bekommt mit nur wenigen Versuchen ein passables Ergebnis nah am Optimum hin.
 
Zuletzt bearbeitet:
Mensch183,
Dass sich mein zweiter Beitrag mit dem synchronen bzw. asynchronen Bus befasst und somit das Thema verlässt, ist richtig. Es mag dadurch auch der Eindruck entstanden sein, jeder RAM/FSB-Takt, der nicht 1:1 läuft, sei asynchron. Es ist daher auch wichtig, die Begrifflichkeiten zu klären.
Tatsächlich habe ich in meinem Post#16 am Beispiel des 4:3 RAM/FSB-Takt eindeutig die in starren Taktzyklen stattfindenden Transfers am Beispiel eines Intel PC-Systems beschrieben ( FSB-Zyklen 0, 1, 2 und RAM-Zyklen 0, 1, 2, 3). Daraus kann man erkennen, dass die "Transfers einzig und allein durch in starren Taktzahlen beschriebene Timings spezifiziert sind". Insoweit sind wir uns völlig einig. Sehr plastisch finde ich in diesem Zusammenhang die Erläuterung mit den Zeigern einer Uhr, die sich zwar in konstanter Winkelgeschwingigkeit drehen, aber mit unterschiedlicher Drehzahl.
Und nun zurück zu synchronen/asynchronen Bus. Ich bleibe bei meinem Vortrag, dass der asynchrone Bus auf das Taktsignal verzichtet und bei allen Busvorgängen mit Synchronisations- und Bestätigungsmerkmalen (Handshakes) arbeitet. Deshalb laufen auch schnellere Speicherchips sofort schneller. Das ist wissenschaftlich geklärt. Deshalb weiß ich nicht, wie Du mit der schlichten Negation, "daß diese asynchrone Methode mit Handshake gar nicht stattfindet", noch sagen kannst, das "hatten wir geklärt".
 
Zuletzt bearbeitet von einem Moderator:
Interessante Diskussion - unterm Strich kann ich allerdings auch nur bestätigen: meine Kiste läuft mit einem Speichermultiplikator von 2,5 auch (messbar) schneller als mit 2,0. Das "messbar" bezieht sich auf synthetische Benchmarks als auch auf Spielebenchmarks. Daher würde ich jedem raten statt 800er 1066er Speicher zu kaufen und diesen auch möglichst auszulasten.
An euch beide - HeinzNeu und mensch183 - meinen Respekt: solch technische Abläufe für uns normale Menschen verständlich darzustellen ist wirklich schwierig. Da mag die Übersetzung in normale Umgangssprache hier und da missverständlich rüberkommen (asynchron = unterschiedliche Winkelgeschwindigkeit der Zeiger?) - ich finde es trotzdem gelungen!
 
@Chrispe13,
ich danke Dir für Deinen Beitrag. Es ist sicher schwierig, sich durch das Gewirr der unterschiedlichen Begriffe zu hangeln und dann noch den Überblick zu bewahren.
Mir ist aber gestern noch eins zum Vorbringen von mensch183 eingefallen.
Soweit behauptet wird: "Es ist kein Zufall, daß es eine Menge synchroner Techniken in allen möglichen Bereichen gibt, in denen sehr schnelle Transfers stattfinden", verlässt dieses Vorbringen freilich die inhaltliche Ebene. Denn damit soll doch nicht ernsthaft dargetan werden, man hätte die einzlenen Bereiche geprüft, inwieweit synchrone oder asynchrone Techniken verwendet werden und sodann festgestellt, 70 von 100 verwenden synchrone Systeme. Doch selbst wenn das so wäre, was wäre damit inhaltlich zur Frage der grundsätzlichen Überlegenheit von asynchronen Systemen gesagt?
Doch gar nichts, außer man wollte mit Hegel argumentieren, aus Quantität wird irgendwann Qualität.
Im Übrigen finde ich die aggressive Art der Argumentation sehr befremdlich. Um auch mal ein quantitatives Argument zu nutzen: Agressive Argumenationen werden oft benutzt, wenn es an Inhalten mangelt. Diese Attributierungen "grober Unfug, Humbug" haben mit einer sachlichen Diskussion nichts mehr gemein. Ich verstehe nicht, wie man sich eine solche Blöße geben kann.
Zu Recht wurde jedoch zum Schluss auf die 3 wichtigsten Parameter (FSB/RAM Verhältnis, CL des RAM und Trd der North-Bridge) hingewiesen.
Allerdings habe ich auch hierzu einen Thread verfasst, der sich sehr intensiv mit dem physikalisch/mathematischen Verhältnis des Performance-Level auseinandersetzt. Um die Kurve zum FSB/RAM- Takt und dem Trd zu bekommmen, habe ich diesen Thread verlinkt. Hierzu hat mensch183 nichts gesagt. Das ist aber auch nicht nötig.
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben