DDR oder RIMM für Audioanwendungen

[Unregistered]

Hi!
Ist letzendlich DDR oder RIMM schneller? Ich brauche einfach einen schnellen Arbeitsspeicher für meine Audioworkstation. Ich bin bereit mehr zu zahlen und mir eine RIMM anzuschaffen, wenn sich das auch wirklich von der Leistung her lohnt. also bitte gebt mir rat
danke und ´n gruß

[davidzo]

gerade bei Audioanwendungen ist die Latenzzeit von hoher Priorität, so können minimale verzögerungen bei mehrspuraufnahmetechnik auf die dauer eine hörbare hässliche verschiebung verursachen.
Deswegen würde ich eher zu DDR RAM greifen, dann aber mindestens PC3000 oder PC3200 Modelle von Corsoir o.ä. die3se Module kommen mittlerweile annähernd an die Bandbreite von Rambus heran... es kommt natürlich auch auf den Prozzi an, wenn er mit 100mhz FSB (FSB400) läuft reicht ein sehr guter DDR Riegel schon ausum Rambus zu deklassieren, doch bei FSB133 (FSB533) ist rambus immer noch kanpp die schnellere Lösung. Bei Audiobearbeitung allerdings würde ich zu DDR RAM Greifen!
(Überhaupt würde ich von nem P4 abraten, allein weil Der Athlon auch gerade bei Audiobearbeitung dank sehr guter Rohleistung einen guten Vorsprung bei gleicher Preisklasse hat) Ich würde nen Athlon 2200+ bis 2700+ und PC3000 oder PC3200 Speciher empfehlen, dazu ein Shuttle AK37GT, denn bei diesem kann man cl1.5 anwählen, was natürlich zu einem plus in der vermeidung hoher Latenzzeiten führt! (allein weil ich kein p4 board kenne das cl1.5 kann würde ich nen Athlon nehmen)

[zeckensack]

Rimms. Aber der Mini-Vorteil wäre mir keinen Cent wert ...

@davidzo,
Spaßvogel :|
Worst case-Latenzen bei RAMs liegen in der Größenordnung 50~100ns (Nanosekunden). In der Audiobearbeitung braucht's Latenzen irgendwo unter 10ms, also so Pi*Daumen um Faktor hunderttausend daneben geschossen.
*kopfschüttel*

[Endorphine]

Originally posted by davidzo
gerade bei Audioanwendungen ist die Latenzzeit von hoher Priorität, so können minimale verzögerungen bei mehrspuraufnahmetechnik auf die dauer eine hörbare hässliche verschiebung verursachen.
Deswegen würde ich eher zu DDR RAM greifen, dann aber mindestens PC3000 oder PC3200 Modelle von Corsoir o.ä. die3se Module kommen mittlerweile annähernd an die Bandbreite von Rambus heran... es kommt natürlich auch auf den Prozzi an, wenn er mit 100mhz FSB (FSB400) läuft reicht ein sehr guter DDR Riegel schon ausum Rambus zu deklassieren, doch bei FSB133 (FSB533) ist rambus immer noch kanpp die schnellere Lösung. Bei Audiobearbeitung allerdings würde ich zu DDR RAM Greifen!
(Überhaupt würde ich von nem P4 abraten, allein weil Der Athlon auch gerade bei Audiobearbeitung dank sehr guter Rohleistung einen guten Vorsprung bei gleicher Preisklasse hat) Ich würde nen Athlon 2200+ bis 2700+ und PC3000 oder PC3200 Speciher empfehlen, dazu ein Shuttle AK37GT, denn bei diesem kann man cl1.5 anwählen, was natürlich zu einem plus in der vermeidung hoher Latenzzeiten führt! (allein weil ich kein p4 board kenne das cl1.5 kann würde ich nen Athlon nehmen)

Wer setzt nur immer wieder diesen Quatsch mit "RDRAM hat eine hohe Latenz" in die Welt? RDRAM wird vollkommen anders angesprochen als unoptimiertes normales DRAM wie DDR-SDRAM.

Ich komme mit DDR-SDRAM nicht mal in die Nähe der Gesamtlatenz von PC1066. Mit PC1066 kommt man runter bis auf 207 Zyklen: http://www.aceshardware.com/Spades/read.php?article_id=45000219

Mit DDR-SDRAM komme ich selbst bei synchroner Anbindung und 1,5-2-2-5 Timing nicht unter 248 Zyklen.

Die core access time bei RDRAM hat überhaupt nichts mit der Periodendauer eines Taktzyklus' von SDRAM zu tun. Wenn man so wöllte, könnte man ja bei PC1066 dann 1,9 ns draufschreiben...

Edit:
Wer allen Ernstes den Begriff "DDR RAM" verwendet, sollte nicht mal daran denken, auch nur ein Wort über Hauptspeichertechniken zu verschwenden.

Edit #2:
Jetzt hab ich ganz vergessen, dem Unreg ein wenig bei der Entscheidungsfindung zu helfen ;) Also...

Originally posted by Unregistered
Hi!
Ist letzendlich DDR oder RIMM schneller? Ich brauche einfach einen schnellen Arbeitsspeicher für meine Audioworkstation. Ich bin bereit mehr zu zahlen und mir eine RIMM anzuschaffen, wenn sich das auch wirklich von der Leistung her lohnt. also bitte gebt mir rat
danke und ´n gruß

RDRAM ist beim P4 eindeutig die leistungsfähigste Speicherarchitektur. PC1066 RDRAM ist sogar noch schneller als dual channel PC2100 im E7505 oder E7205. In der Praxis macht der Unterschied in der Anwendungsleistung zwischen RDRAM und einkanaligem DDR-SDRAM ungefähr eine Taktstufe aus (100 bis 200 MHz). Du kannst nun selbst ausrechnen, ob sich für dich eher RDRAM oder DDR-SDRAM lohnt.

Von E7205 Boards rate ich derzeit noch ab, die haben noch einige Kinderkrankheiten. Es sei denn, du willst wirklich sehr viel RAM einsetzen (um die 2GB). Dann lohnt sich ein E7205 Board, weil der Speicher sehr billig ist.

Wenn du auf die Leistung schaust lohnt sich RDRAM auf jeden Fall. Hoffe, das hilft dir... :)

[GloomY]

Originally posted by Endorphine
Wer setzt nur immer wieder diesen Quatsch mit "RDRAM hat eine hohe Latenz" in die Welt? RDRAM wird vollkommen anders angesprochen als unoptimiertes normales DRAM wie DDR-SDRAM.

Ich komme mit DDR-SDRAM nicht mal in die Nähe der Gesamtlatenz von PC1066. Mit PC1066 kommt man runter bis auf 207 Zyklen: http://www.aceshardware.com/Spades/read.php?article_id=45000219
Mit DDR-SDRAM komme ich selbst bei synchroner Anbindung und 1,5-2-2-5 Timing nicht unter 248 Zyklen.Ich weiss nicht, wo du die ominöse Zahl von 248 Takten hernimmst (Bei deinem Link auf Ace's hab' ich's nicht gefunden).
Außerdem ist schon die Latenz von PC133 RAM besser als die von PC800 RAM (229 zu 248 Takten), bei SDRAM mit 166 oder 200 MHz (egal ob SDR oder DDR) sieht selbst PC1066 alt dagegen aus.

Der Grund für die (relativ) schlechte Latenz von RDRAM ist nunmal der serielle Bus, der dort zum Einsatz kommt. Auf der einen Seite bringt das Vorteile (deutlich höhere Frequenzen), aber was die Latenz betrifft, hat es einen entscheidenden Nachteil: Damit die 8 Speicherchips, die üblicherweise auf einem RDRAM Modul drauf sind, nicht gleichzeitig Daten über den Bus senden (merke: sie benutzen ja die gleichen Leitungen, da seriell), müssen diese zeitlich verzögert werden, damit sie sich nicht in die Quere kommen.
Das erhöht natürlich deutlich die Latenz gegenüber einer parallelen Speichertechnologie (SDRAM), wo die Chips alle gleichzeitig angesprochen werden und auch gleichzeitig Daten senden können.
Originally posted by Endorphine
Edit:
Wer allen Ernstes den Begriff "DDR RAM" verwendet, sollte nicht mal daran denken, auch nur ein Wort über Hauptspeichertechniken zu verschwenden.An sich ein richtiger Aspekt, aber es hat sich halt so eingebürgert, dass man von "DDR RAM" spricht, wenn man DDR SDRAM meint. Wenn es um Rambus geht, dann schreibt man halt RDRAM.

Aber im eigentlichen Sinne ist RDRAM auch ein "DDR RAM"...

[Endorphine]

Originally posted by GloomY
Ich weiss nicht, wo du die ominöse Zahl von 248 Takten hernimmst (Bei deinem Link auf Ace's hab' ich's nicht gefunden).


Wenn du mein Posting richtig gelesen hättest, wäre dir folgendes aufgefallen:
Mit DDR-SDRAM komme ich selbst bei synchroner Anbindung und 1,5-2-2-5 Timing nicht unter 248 Zyklen.

Originally posted by GloomY
bei SDRAM mit 166 oder 200 MHz (egal ob SDR oder DDR) sieht selbst PC1066 alt dagegen aus.


Eine Behauptung, die du nicht beweisen kannst. Und die meiner Meinung nach falsch ist. Du kannst mich gern vom Gegenteil überzeugen und beides benchen.

Originally posted by GloomY
Der Grund für die (relativ) schlechte Latenz von RDRAM ist nunmal der serielle Bus, der dort zum Einsatz kommt. Auf der einen Seite bringt das Vorteile (deutlich höhere Frequenzen), aber was die Latenz betrifft, hat es einen entscheidenden Nachteil: Damit die 8 Speicherchips, die üblicherweise auf einem RDRAM Modul drauf sind, nicht gleichzeitig Daten über den Bus senden (merke: sie benutzen ja die gleichen Leitungen, da seriell), müssen diese zeitlich verzögert werden, damit sie sich nicht in die Quere kommen.
Das erhöht natürlich deutlich die Latenz gegenüber einer parallelen Speichertechnologie (SDRAM), wo die Chips alle gleichzeitig angesprochen werden und auch gleichzeitig Daten senden können.


Unsinn. Die recht hohe core access time kommt durch die Verwaltungsarbeit zustande. Jedes 16d RDRAM-device besteht ja aus 2x 8 Bänken, die mit 100 MHz laufen und über einen Device-internen 128-Bit Bus verbunden sind. Die Latenz entsteht nun durch den Verwaltungsaufwand, die externen 16-Bit Häppchen zu verarbeiten und dann das Kommando auf die entprechende Bank anzuwenden, dann das selbe nochmal rückwärts und der Transfer ist abgeschlossen.

Zu "DDR RAM": Wer über eine Speichertechnik urteilt, sollte IMO wenigstens so viel Wissen haben, dass er nicht Begriffe wie "DDR RAM" verwendet. Du bringst es auf den Punkt, auch RDRAM würde in die Menge der "DDR RAM" fallen.

[zeckensack]

... was alles nichts an der Tatsache ändert daß die Speicherlatenz für den gewünschten Anwendungsfall unkritisch ist. Quasi Null Relevanz und so.

Gell???

[GloomY]

Originally posted by Endorphine
Wenn du mein Posting richtig gelesen hättest, wäre dir folgendes aufgefallen:

Mit DDR-SDRAM komme ich selbst bei synchroner Anbindung und 1,5-2-2-5 Timing nicht unter 248 ZyklenNa wunderbar, darf ich vielleicht auch das System erfahren, mit dem du diese Messung gemacht hast?
Das Programm, und die sonstige Softwareumgebung wäre auch nicht schlecht, bevor man irgendwelche selbsterzeugten Zahlen veröffentlicht...
Originally posted by Endorphine
Eine Behauptung, die du nicht beweisen kannst. Und die meiner Meinung nach falsch ist. Du kannst mich gern vom Gegenteil überzeugen und beides benchen.Mal schauen...
Originally posted by Endorphine
Die Latenz entsteht nun durch den Verwaltungsaufwand, die externen 16-Bit Häppchen zu verarbeiten und dann das Kommando auf die entprechende Bank anzuwenden, dann das selbe nochmal rückwärts und der Transfer ist abgeschlossen.Das Multiplexing bei RDRAM ist nicht das Problem. Das könnte man schon einfach durch eine schnellere Logikschaltung verbessern. Da liegt sicher nicht das Problem.

Wie oben schon geschrieben, ist für die relativ schlechte Latenz hauptsächlich der serielle Bus und damit die Verzögerungen der einzelnen Speicherchips auf dem Bus verantwortlich. Ars (http://arstechnica.com/paedia/r/ram_guide/ram_guide.part3-6.html) schreibt z.B.:

"Because of the need to be able to delay the output of read requests so that reads from different RDRAM chips can arrive at the chipset together and in the right order, a RAMBUS system has to go through an elaborate initialization ritual on boot-up in order to determine the amount of delay that needs to be inserted into each RDRAM. The read delay value for each individual RDRAM chip is programmed via the control pins into one of those control registers that we met in the previous section. These read delays effectively slow down the entire system so that each device has the same latency as the outermost RDRAM."


Was die Latenz angeht, so gibt es noch ein paar Gründe, die für oder gegen RDRAM sprechen.
Da wäre z.B. die Sache mit dem Power Management der Speicherchips. Jeder Chip kann sich in 6 verschiedenen Zuständen befinden, in denen er je nach Stufe entweder voll bereit ist und damit aber auch ziemlich viel Strom verbrät (Alles an: Takt- und Refresh-Logik, Lese- und Schreib-(De)multiplexer, Sense Amps, Row/Column Decoder und Multiplexer). Oder er befindet sich in einen der "Schlafzustände", die weniger oder extremsten Fall praktisch kaum Strom verbrauchen (nur Refresh- und Taktlogik an). Allerdings brauchen die Chips aber auch eine gewisse Zeit (eine "Ewigkeit" beim stärksten Modus), um aus diesen Zuständen dann wieder zu "erwachen".

So, was hat das ganze jetzt mit der Latenz zu tun? Folgendes:
Da die einzelnen Speicherchips sich auf einem Bus befinden, DARF nämlich nur maximal ein Chip gleichzeitig aktiv sein und sich im "höchsten" Modus (d.h. voll aktiv) befinden. Die anderen sind in einem der weniger aktiven Modi und müssen erst aktivert werden (was Zeit braucht!!!), wenn ein Command für sie auf dem Bus ankommt. Besonders bei random Zugriffen macht sich so eine höhere Latenz bemerkbar.

Und diese Tatsache ist auf die Natur des seriellen Busses bei RDRAM zurückzuführen (und auf nix anderes!). Für ein paralleles Speicherinterface braucht man diese "Schlafzustände" nämlich nicht, da dort die Daten über die gesamten Chips verteilt sind und bei einem Zugriff aus jedem Speicherchip gelesen/geschrieben wird und nicht nur aus einem einzelnen (so wie bei RDRAM).

Originally posted by zeckensack
... was alles nichts an der Tatsache ändert daß die Speicherlatenz für den gewünschten Anwendungsfall unkritisch ist. Quasi Null Relevanz und so.

Gell??? Öhm, kannst du mir bitte erklären (oder in andern Worten ausdrücken), was du damit meinst?
Willst du damit sagen, dass die Latenz keine Rolle spielt? Das würde ich aber nicht so sehen...

edit: @ Endorphine:
Ich hab' grad' noch was bei Ace's (http://www.aceshardware.com/read.jsp?id=50000279) gefunden:

"These enormous differences in "reaction" time must be compensated. To do this, the memory controller assigns each memory chip a different extra delay (latency) called TPARM. The closer the chip to the memory controller, the higher the extra latency. The result is that all DRDRAM chips appear to be as slow or as fast as the farthest chip. This also explains why the typical latency of RDRAM is (a bit) higher than DDR SDRAM."

[Endorphine]

Originally posted by GloomY
Na wunderbar, darf ich vielleicht auch das System erfahren, mit dem du diese Messung gemacht hast?
Das Programm, und die sonstige Softwareumgebung wäre auch nicht schlecht, bevor man irgendwelche selbsterzeugten Zahlen veröffentlicht...
Mal schauen...


Das Programm findest du bei aufmerksamem Lesen des Artikels von Ace. Google ist dann dein Freund.

Testsystem: i845E bei FSB533

Ergebnisse für CM mit Speicherblock von 32MB, 4kB Schritte:
FSB533, 133 MHz synchron angebunden, Timing 1,5-2-2-5: 248 cycles Latenz, Main memory speed (MB/s): Read=1910.6, Write=607.7
FSB533, 179 MHz via 4:3 Multiplikator, Timing 2,5-3-3-7: 271 cycles Latenz, Main memory speed (MB/s): Read=2282.0, Write=712.7

Originally posted by GloomY
Das Multiplexing bei RDRAM ist nicht das Problem. Das könnte man schon einfach durch eine schnellere Logikschaltung verbessern. Da liegt sicher nicht das Problem.

[...] bla [...]


Du hast mich komplett missverstanden (oder weisst du nicht, wie RDRAM tickt?). Ich habe das Multiplexing im Chipsatz nicht mit einem Wort erwähnt. Meine Ausführungen bezogen sich allein auf die interne Struktur eines RDRAM-Devices. Vielleicht solltest du da noch einmal in die Datenblätter und Design Guidelines sehen, um etwas mehr Verständnis für die Sache aufzubringen? Vorgekaute Meinungen von anderen Seiten sind keineswegs das optimale Mittel, wenn man sich deren Quellen auch selbst bedienen kann (z.B. http://www.rdram.com)

Wenn du aber noch weiterhin nur das wiederholen willst, was du jetzt 2x gesagt hast, dann können wir die Diskussion hier beenden. Die Teilaktivierung wurde übrigens nur als Workaround für die Hitzeprobleme der ersten PC800-RIMMs im i820 eingeführt und hat nichts mit dem seriellen Bus zu tun. Auch hier wieder -> lies dich mehr in die Sache ein.

Edit:
Und wieder habe ich jemanden vergessen ;)

Originally posted by zeckensack
... was alles nichts an der Tatsache ändert daß die Speicherlatenz für den gewünschten Anwendungsfall unkritisch ist. Quasi Null Relevanz und so.

Gell???

Yup, 100 % ACK :)

Ist schon ein wenig OT, die Diskussion. Die ursprüngliche Frage wurde ja längst geklärt...

[zeckensack]

Originally posted by GloomY
Öhm, kannst du mir bitte erklären (oder in andern Worten ausdrücken), was du damit meinst?
Willst du damit sagen, dass die Latenz keine Rolle spielt? Das würde ich aber nicht so sehen...Das bedrohliche Knacksen/Aussetzen/allgemeine Verzögern bei Audioaufnahmen wird sicher nicht durch die Speicherlatenz beeinflußt.

Man spricht hier zwar auch in Audiosystemen von Latenz, allerdings darf alles unterhalb von 10 Millisekunden bereits als sehr gut, und alles unter 5 ms als nicht mehr verbesserungswürdig gelten.

Die Speicherlatenz hat darauf praktisch keinen Einfluß, dafür ist sie viel zu gering. Rambus hin oder her.

Da sollte man doch besser auf die erreichbare Bandbreite schielen, damit man in der Bearbeitungsphase möglichst wenig warten muß.

[Tiamat]

Die Latenzzeiten des Arbeitsspeichers beeinflusst deine Audiobearbeitung überhaupt nicht.Du kannst hier ganz nach deinem Geschmack zugreifen.Eine ASIO-fähige Audiokarte ist von viel größerer Wichtigkeit als der Speicher nebenbei bemerkt ...
Gruß
Tiamat

[GloomY]

@ Zeckensack: Volle Zustimmung, da befinden wir uns in einer ganz anderen Größenordnung.
Originally posted by Endorphine
Das Programm findest du bei aufmerksamem Lesen des Artikels von Ace. Google ist dann dein Freund.

Testsystem: i845E bei FSB533

Ergebnisse für CM mit Speicherblock von 32MB, 4kB Schritte:
FSB533, 133 MHz synchron angebunden, Timing 1,5-2-2-5: 248 cycles Latenz, Main memory speed (MB/s): Read=1910.6, Write=607.7
FSB533, 179 MHz via 4:3 Multiplikator, Timing 2,5-3-3-7: 271 cycles Latenz, Main memory speed (MB/s): Read=2282.0, Write=712.7Na super, 2,5-3-3-7 ist ein ziemlich mieses Timing. Langsamer geht's echt nicht...

Mal schauen, was ich aus meinem DDR SDRAM @ 203 MHz und 2,0-2-2-5-1T Timing rausquetschen kann...
Originally posted by Endorphine
Du hast mich komplett missverstanden (oder weisst du nicht, wie RDRAM tickt?).Ticken? Nein, ticken ist mir nicht bekannt. Takten schon eher...
Originally posted by Endorphine
Ich habe das Multiplexing im Chipsatz nicht mit einem Wort erwähnt.
Meine Ausführungen bezogen sich allein auf die interne Struktur eines RDRAM-Devices.Ja, und da hast du die "16-Bit Häppchen" erwähnt, die durch die Multiplexer generiert werden. Denn intern sind es im Speicher zwei 64 Bit breite Busse und der FSB ist auch 64 Bit breit. Ohne Multiplexer bekommst du deine 16 Bit breiten Häppchen auf dem RDRAM Channel nicht hin.
Originally posted by Endorphine
Vielleicht solltest du da noch einmal in die Datenblätter und Design Guidelines sehen, um etwas mehr Verständnis für die Sache aufzubringen?Du meinst, ich hätte nicht genügend Verständnis von der Sache? Soso...

Mal davon abgesehen, dass dich hier niemand um deine Meinung bezüglich meiner Kompetenz gefragt hat, ist es absolut unangebracht, mir in diesem Zusammenhang ungefragt Vorschläge zu bereiten, was ich machen sollte oder nicht. :jedifire:
Originally posted by Endorphine
Vorgekaute Meinungen von anderen Seiten sind keineswegs das optimale Mittel, wenn man sich deren Quellen auch selbst bedienen kann (z.B. http://www.rdram.com)Meinungen? Mit Meinungen gebe ich mich nicht ab. Und wenn du die von mir aufgezeigten Fakten als Meinungen abqualifizieren willst, dann hat die Diskussion wirklich keinen Sinn mehr (siehe auch unten).

Ach ja, was Neutralität angeht: Meinst du etwa RAMBUS erzählt dir auf ihrer Webseite, welche Schwächen ihre Architektur hat? Da bevorzuge ich lieber die "anderen Seiten" (wie du es nennst).
Originally posted by Endorphine
Wenn du aber noch weiterhin nur das wiederholen willst, was du jetzt 2x gesagt hast, dann können wir die Diskussion hier beenden.Im Gegensatz zu dir bringe ich neue Argumente in die Diskussion ein (z.B. die Sache mit dem Power Management wirst du nicht in meinem ersten Posting finden).

Ach ja, wenn du dich weiterhin so im Tonfall vergreifst, dann sollten wir die Dsikussion wirklich beenden.
Originally posted by Endorphine
Die Teilaktivierung wurde übrigens nur als Workaround für die Hitzeprobleme der ersten PC800-RIMMs im i820 eingeführt und hat nichts mit dem seriellen Bus zu tun.
Lies mein Posting von oben. Ich hab' mir nicht umsonst die Mühe für's Tippen gemacht. Da steht klipp und klar drin, warum es eine Folge der Eigenschaft des seriellen Busses ist.
Originally posted by Endorphine
Auch hier wieder -> lies dich mehr in die Sache einno comment...

[BlackBirdSR]

Originally posted by Endorphine


Das Programm findest du bei aufmerksamem Lesen des Artikels von Ace. Google ist dann dein Freund.

Testsystem: i845E bei FSB533

Ergebnisse für CM mit Speicherblock von 32MB, 4kB Schritte:
FSB533, 133 MHz synchron angebunden, Timing 1,5-2-2-5: 248 cycles Latenz, Main memory speed (MB/s): Read=1910.6, Write=607.7
FSB533, 179 MHz via 4:3 Multiplikator, Timing 2,5-3-3-7: 271 cycles Latenz, Main memory speed (MB/s): Read=2282.0, Write=712.7


Wie man es nimmt: http://www.aceshardware.com/read.jsp?id=50000304
du solltest nicht vergessen welchen Einfluss Prefetching hier hat.


Originally posted by Endorphine
Du hast mich komplett missverstanden (oder weisst du nicht, wie RDRAM tickt?). Ich habe das Multiplexing im Chipsatz nicht mit einem Wort erwähnt. Meine Ausführungen bezogen sich allein auf die interne Struktur eines RDRAM-Devices. Vielleicht solltest du da noch einmal in die Datenblätter und Design Guidelines sehen, um etwas mehr Verständnis für die Sache aufzubringen? Vorgekaute Meinungen von anderen Seiten sind keineswegs das optimale Mittel, wenn man sich deren Quellen auch selbst bedienen kann (z.B. http://www.rdram.com)



du solltest vielleicht etwas benehmen lernen, die Audrucksart ist ein wenig unangebracht fürchte ich.
Was Gloomy hier übrigens einbringt, ist das was im generellen von RDRAM angenommen wird.
Also kann keiner im Netz RDRAM richtig verstehen ausser dir, oder..

RDR nutzt einen Seriellen Bus, im Gegensatz zu SDRAM sitzen die Chips also hintereinander im logischen Aufbau.
Das Signal erreicht den Chip 1 nun nach x sekunden, den Chip 2 nach x+y sekunden und den Chip 8 nach x+n sekunden.
Das ist unakzeptabel für eine Datenübertragung.

Deswegen erhält der Chip 1 ebenfalls eine Latenz von x+n die der zeit enspricht die der letzte Chip auf dem Bus hat.
Bei mehr Chips im Bus wird die allg. Latenz für das ganze System größer.

Das ist sicher nur einer von vielen Gründen für unterschiedliche Latenz.. aber keineswegs der von dir bezeichnete Unsinn.
So, und nun will ich wissen was daran falsch ist, bzw warum wir es verdient haben so angemacht zu werden?

[GloomY]

btw: Falls es irgend jemanden interessiert:

Ich komme bei Cachemem mit meinem System (7,5*203 MHz) auf 179 Clockcycles bei 4kB Schritten und 32 MB Blockgröße (also weit entfernt von den 248 bzw. 271 Clockcyclen).

Latency - Memory walk tests... ("pointer chasing")
Null size: 4 cycles 1 cycles (overhead 66 cycles)
steps: 4 8 16 32 64 128 256 512 1k 2k 4k (bytes)
Block of 1KB: 4 4 4 4 4 4 4 4 - - - cycles
Block of 2KB: 4 4 4 4 4 4 4 4 4 - - cycles
Block of 4KB: 4 4 4 4 4 4 4 4 4 4 - cycles
Block of 8KB: 4 4 4 4 4 4 4 4 4 4 4 cycles
Block of 16KB: 4 4 4 4 4 4 4 4 4 4 4 cycles
Block of 32KB: 4 4 4 4 4 4 4 4 4 4 4 cycles
Block of 64KB: 4 4 4 4 4 4 4 4 4 4 4 cycles
Block of 128KB: 4 5 9 10 20 20 20 20 20 20 20 cycles
Block of 256KB: 4 5 9 10 20 20 20 20 20 20 20 cycles
Block of 512KB: 11 19 41 68 121 122 122 124 128 136 150 cycles
Block of 1024KB: 11 19 41 68 121 122 122 124 128 136 150 cycles
Block of 2048KB: 12 19 41 68 122 122 123 127 134 146 172 cycles
Block of 4096KB: 12 19 42 68 122 122 124 127 135 147 176 cycles
Block of 8192KB: 11 19 42 68 122 123 124 128 135 149 178 cycles
Block of 16384KB: 11 19 42 68 122 122 124 128 135 149 179 cycles
Block of 32768KB: 11 19 41 68 122 122 124 128 136 150 179 cyclesAnzumerken wäre noch, dass der Wert für 128 kb Schritte bei mir (122 Clocks) deutlich geringer als der von PC1066 ist (Ace's schreibt dort 207 Clocks). Das ist eine 69% höhere Latenz...