DDR3: Latency vs bandwidth

[Jaapoes]

Ik vroeg mij vanwege een eventuele mem upgrade het volgende af;
Is bij DDR3 een hogere kloksnelheid beter dan een set met lagere snelheid maar met strakkere timings? Nou kan ik me voorstellen dat 1600mhz met bijvoorbeeld 10-10-10-20 beter zou kunnen zijn dan 2000mhz met 15-15-15-30.. hoewel.. wie weet het? Google heeft me niet verder kunnen helpen..

[Ventieldopje]

Beide zijn niet verkeerd om te hebben, nou verschillen de latency's niet zo heel veel meer tegenwoordig volgensmij. Een hogere kloksnelheid is alleen leuk als je gaat overclocken want standaard zal hij wat voor module dan ook niet sneller draaien dan 1333- of 1600MHz.

Wat voor modules heb je op het oog?

[jbkappirossi]

Dan is 10 10 10 20 beter, omdat je pas met meer dan 16gb een bottleneck crieert op 1600mhz.

[Jaapoes]

Waarom zou je pas vanaf 16gb een bottleneck creeren op 1600mhz?

En ik heb een 6gb triple channel set van OCZ op het oog die op 2000mhz lopen met timings van 10-10-10-30

[Admiral Freebee]

Onthoud in elk geval dat die timings uitgedrukt worden in aantal kloktikken, en niet in (nano)seconden. Een kloktik aan 1600MHz duurt korter dan één aan 2000MHz bijvoorbeeld. Vandaar dat oudere geheugentypes zoals DDR schijnbaar lagere latencies hebben, terwijl ze in tijd uitgedrukt nauwelijks veranderd zijn.

Denk verder ook eens na of je wil overklokken, en hoever je wil overklokken. Modules die snel kunnen draaien, kan je overigens ook op een lager snelheid in combinatie met strakkere timings instellen. Maar ja, je hebt ook nog de prijs natuurlijk

Een bottleneck ga je overigens niet snel creëren hoor. Het s1366 platform heeft triple channel ondersteuning, en dat geeft zo'n grote sloot geheugenbandbreedte, dat dat zeker niet de bottleneck vormt. Zelfs bij langzamer DDR3 geheugen.

[ Voor 17% gewijzigd door Admiral Freebee op 27-01-2011 09:47 ]

[Jaapoes]

Dus als ik het goed begrijp zal het verschil tussen mijn set en die OCZ niet enorm groot zijn?

[Admiral Freebee]

Tenzij je met het overklokken merkt dat je geheugen het niet meer kan bijhouden (je kan het geheugen niet ver genoeg overklokken bijvoorbeeld), niet nee. Die extra bandbreedte ga je helemaal niet merken, tenzij in een aantal synthetische benchmarks. En dan nog maar minimaal. Bovendien ga je dan extra belasting teweegbrengen op je geheugencontroller die in de CPU zit.

[R.E.]

Daarnaast geeft DDR3 op 2000MHz met 15-15-15 op 1600MHz waarschijnlijk precies dezelfde latencies als dat originele 1600MHz reepje.

Zolang je niet gaat overklokken is in principe 1333MHz DDR3 over het algemeen al bijna overkill op bandbreedte gebied (in verband met dual channel). Alles daarboven komt pas in beeld als je echt wilt overklokken.

[Ventieldopje]

Onthoud in elk geval dat die timings uitgedrukt worden in aantal kloktikken, en niet in (nano)seconden. Een kloktik aan 1600MHz duurt korter dan één aan 2000MHz bijvoorbeeld.

Because modern DRAM modules' CAS latencies are specified in clock ticks instead of time, when comparing latencies at different clock speeds, latencies must be translated into actual times to make a fair comparison; a higher numerical CAS latency may still be a shorter real-time latency if the clock is faster. However, it is important to note that the manufacturer-specified CAS latency typically assumes the specified clock rate, so underclocking a memory module may also allow for a lower CAS latency to be set.

Timings in winkels en op verpakkingen worden altijd uitgedrukt in nano seconden en niet in clock ticks

[Jaapoes]

Phas0r schreef op donderdag 27 januari 2011 @ 10:59:
Timings in winkels en op verpakkingen worden altijd uitgedrukt in nano seconden en niet in clock ticks

Dat is ook eigenlijk wel logischer Anders zouden een hele boel consumenten misleid worden denk ik.. maar goed, als ik het goed begrijp zijn 2000mhz leuk voor benchmarks e.d. maar voor gaming e.d. zal je er weinig van merken?

[Admiral Freebee]

Phas0r schreef op donderdag 27 januari 2011 @ 10:59:
Timings in winkels en op verpakkingen worden altijd uitgedrukt in nano seconden en niet in clock ticks

Net andersom.

[jbkappirossi]

Jaapoes schreef op donderdag 27 januari 2011 @ 09:45:
Waarom zou je pas vanaf 16gb een bottleneck creeren op 1600mhz?

En ik heb een 6gb triple channel set van OCZ op het oog die op 2000mhz lopen met timings van 10-10-10-30

sorry, ik zat even met dual channel in de knoop.

stel je clockt je i7 over 200x20=4000mhz.

Als je dan geheugen van 1600Mhz gebruikt maal de BCLK van 200mhz = 320000MB/s bandbreedte.
Als je dan geheugen van 2000Mhz gebruikt maal de BCLK van 200mhz = 400000MB/s bandbreedte.
Dus theoreties moet je met 1600mhz geheugen en een BCLK van 200mhz pas een bottlenack vormen met meer dan 32GB op die snelheid. Daarom heb je meer aan snellere timings, omdat je de maximale bandbreedte toch nooit benut van tripple channel.

MHZ = bandbreedte
Timings = de snelheid waarmee het geheugen kan comuniceren en met de cpu.
GB = de capaciteit van het geheugen ofwel de hoeveelheid data wat weggeschreven kan worden.

[ Voor 16% gewijzigd door jbkappirossi op 28-01-2011 04:40 ]

[Admiral Freebee]

Dan nog is de geheugenbandbreedte geen bottleneck. Jij gaat er vanuit dat je je hele RAM geheugen in één seconde zou moeten kunnen lezen, maar dat is toch een arbitraire grens? Er is geen reden waarom je je RAM geheugen in één seconde zou moeten kunnen lezen.

[jbkappirossi]

Je hebt bijv. ddr3 1600mhz en dat doet 1600.000.000 cycles per clock tik. met latensie/delays CAS RAS tRP tRAS van bijv. 999-27 is totaal 54 clocktiks delay. 1600.000.000 clocktiks gedeelt door het aantal clock delays 54 = 29626929 cycles per clock tik. We weten dat 1 nanoseconde gelijk is aan 1/1000000 seconde. Dus dat is 29 nanoseconden per clocktik.

Als je dus 16gb geheugen hebt en een programma gebruikt al dat geheugen. Dan krijg je 16GB/s x 29ns = 464000ns is gelijk aan 0,464 seconde.


Als ik dan de vergelijking maak met 2000mhz = 2000.000.000 cycles per clock tik. met latensie/delays CAS RAS tRP tRAS van bijv. 11-10-11-27 is totaal 59 clocktiks delay. 2000.000.000 clocktiks gedeelt door het aantal clock delays 59 = 33898305 cycles per clocktik. We weten dat 1 nanoseconde gelijk is aan 1/1000000 seconde. Dus dat is 33 nanoseconden per clocktik totaal delay.

Als je dus 16gb geheugen hebt en een programma gebruikt al dat geheugen. Dan krijg je 20GB/s x 33ns = 660000ns is gelijk aan 0,66 seconde.


Dan kun jij wel nagaan hoeveel dat gaat schelen in bijvoorbeeld 1uur. Verschil tussen 0,464 en 0,66 = 0,196 maal 60 is een minuut maal 60 is een uur. 0.196 x 60 = 11.75secondes x 60 = 705,6secondes per uur.
Wat dus betekent dat 1600 9-9-9 27 in 1 uur kan verwerken 2000 11-10-11 27 daar 1:11 uur over doet.

[Admiral Freebee]

Dat is een mooie berekening, maar je kan je wel voorstellen dat dit voor real-world prestaties nauwelijks iets uitmaakt?

Een programma kan nooit al het geheugen in beslag nemen, aangezien andere processen ook hun stukje willen. Bovendien heb je vrijwel geen software die al dat geheugen dan nog eens in één keer gaat uitlezen.