</div><div class=b4>Vraag aan dezelfde fabrikanten hoe moeilijk het is om Rambus stabiel te krijgen. Ze hebben er allemaal problemen mee, terwijl SDRAM gewoon rock solid is</div><div class=b1>
Natuurlijk. Ze hebben kunnen oefenen met FPM DRAM, EDO DRAM, en nu SDRAM. Zoveel verschillen deze technologieen niet in de implementatie op PCB nivo. Als de ervaring met RDRAM toeneemt, zal dat ook rock-solid zijn.
</div><div class=b4>Da's mooi, want de DDR-2 staat op de planning voor 2002. Een open standaard die door de hele industrie wordt ondersteund (op dit moment hebben de meeste geheugenfabrikanten schijt aan Rambus Inc.). </div><div class=b1>
Daar heb je helemaal gelijk in. Ik prefereer ook open standaarden. Over DDR-2 weet ik niets, dus ik geef er geen commentaar op of het beter of slechter is. De SDRAM architectuur kan ik dromen, RDRAM heb ik me in verdiept uit interesse. Maar ik ga ervan uit dat er wel weke punten opgelost worden.
Over QDR DRAM: Kentron geeft geen informatie over hun technologie op de webpagina, behalve een persbericht. Een antwoord op m'n mail heb ik nog niet gehad.
QDR SRAM is inderdaad mogelijk zoals het beschreven wordt, maar dit is niet mogelijk bij DRAM. In DRAM kun je niet tegelijk lezen/schrijven, wat in SRAM geen probleem is (zolang je niet tegelijk hetzelfde adres wilt lezen en schrijven)
</div><div class=b4>Hiermee rekening houdend is PC2100 DDR SDRAM nog steeds sneller dan PC800 Rambus. SDRAM heeft dan wel het voordeel van de lagere latency en de veel lagere kosten</div><div class=b1>
Ik ben niet bekend met deze getallen, en ik kan ze ook niet afleiden. Maar dan nog: als het je om het verschil tussen die getalletjes 2100 en 800 gaat, dan ben je ook vast van mening dat een P2-450 net zo snel is als een P3-450 omdat ze allebei 450MHz zijn. Het verschil is 500Mb/sec. (2.1Gb/sec - 1.6Gb/sec) in *burst* rate. Wat alleen maar iets zegt als je veel bytes achter elkaar uitleest van opeenvolgende adressen. De grote caches maken overigens de burst transacties redelijk efficient.
</div><div class=b4>Dat probleem is inherent aan het Rambus design (de smalle bus en het seriële ontwerp).</div><div class=b1>
Veel van de RDRAM latency komt nog steeds van de precharge en bank changes. Het Rambus design heeft inderdaad inherent een vrij grote latency, maar bied tegelijkertijd de mogelijkheid om dat grotendeels te verbergen in een optimale implementatie. Als je trouwens de latencies in nanoseconden tegen elkaar gaat zetten, komt rambus nog maar een beetje slechter uit de bus. Alleen schijnt het leuk te zijn om het in clocks tegen elkaar af te zetten, want dan lijkt RDRAM veel beroerder.
</div><div class=b4>Nou, verklaar eens. Is 'bus skew' (whatever dat mag zijn) de reden dat Rambus beter is dan SDRAM, ondanks het feit dat het trager en duurder is?</div><div class=b1>
Ja, in de toekomst wel. Nu is het nog belachelijk duur en de voordelen wegen niet op tegen de nadelen. Btw, RDRAM is (ietsje, 15% ofzo) sneller dan SDR SDRAM, en ik heb nog nooit real-life benchmarks van DDR SDRAM vs. RDRAM gezien op een x86 moederbord.
Er zijn twee effecten.
Ten eerste: vervorming van de signalen op hoge snelheid en het niet op tijd arriveren dan data tov klok. Dit is de skew. Dit is een reden waarom hoge frequenties zo lastig zijn op een PCB, en ook de reden van alle kronkels in de sporen.
Ten tweede: SDRAM moet je commando's geven, waarop de chip begint data uit te spugen. Dit vereist tweeweg verkeer over (meestal, niet altijd) dezelfde sporen, die helaas niet oneindig snel zijn. RDRAM lost dit met hun seriele benadering erg mooi op. Er kunnen nieuwe commando's verstuurd worden voordat de oude uitgevoerd zijn en terug bij de northbridge. Hoe het precies werkt weet ik niet meer, dat zou ik weer even na moeten zoeken.
Hehe, let's continue the war