Analyse van prestatieverschillen tussen geheugentimings

Bij Techware Labs is een uitgebreide analyse verschenen van de invloed die de verschillende geheugentimings hebben op de prestaties van het geheugen. Naast zaken als kloksnelheid, CAS Latency (CL) en Bank Interleave, wordt er ook gekeken naar de effecten van Trp, Tras, Trcd, DRAM Command Rate, DRAM Burst Length, Write Recovery Time en DRAM Access Time. Voor een uitleg van al deze termen verwijst de auteur ons naar deze site, alwaar ook de werking van geheugen in zijn algemeenheid wordt toegelicht. De analyse heeft plaats gevonden op een Soyo SY-P4X400 moederbord, omdat dit plankje veel mogelijkheden biedt wat betreft het handmatig instellen van geheugentimings. Crucial stelde twee 128MB PC2700 DDR RAM-reepjes ter beschikking, en als benchmark werd de geheugentest van SiSoft's Sandra Professional 2003 gebruikt.

Van de 4608 combinaties die mogelijk zijn met de gekozen timings, zijn er maar liefst 289 getest. Dit zijn combinaties die de verschillen tussen de timings zo duidelijk mogelijk maken, waardoor een gedetailleerde analyse mogelijk is. Het verschil tussen de traagste en de snelste combinatie van timings is de moeite waard. De geheugenbandbreedte nam met 95 procent toe, van 1333 naar 2603MB/sec. De grootste verschillen worden logischerwijs veroorzaakt door de kloksnelheid, waarbij een verhoging van 100MHz naar 166MHz zo'n 55 tot 60 procent prestatiewinst veroorzaakte. Na de kloksnelheid zullen tweakers hun aandacht richten op de CAS Latency, welke het aantal klokcycli (of 'ticks') meet tussen de ontvangst van een leesopdracht en het moment waarop de chip de leesopdracht echt uitvoert.

De CAS Latency lijkt verbazingwekkend genoeg weinig invloed te hebben op de geheugenbandbreedte. Wanneer de CL werd aangepast van 3T tot 2T, of zelfs tot 1,5T, steeg de bandbreedte met niet meer dan 4MB/sec, een stijging van 0,002 procent. Bank Interleaving bleek meer effect te hebben. Een aanpassing van 'Disabled' tot 4-way nam een prestatiewinst van 80 tot 100MB/sec voor zijn rekening, wat neer komt op een stijging van twee tot acht procent. (Let op: 4-way Bank Interleaving is doorgaans alleen mogelijk op reepjes van tenminste 64MB!) Van alle andere timings is er geen één die meer dan een of twee procent invloed heeft op de totale prestaties. Er wordt dan ook geconcludeerd dat de hoogste bandbreedte gehaald kan worden door de timings iets minder agressief in te stellen en de kloksnelheid zo hoog mogelijk te kiezen:

From our results, the most important factor in memory bandwidth is the speed of the memory clock. This would suggest a certain desirability to sacrifice the other memory timings in hopes of pushing the memory speed higher. However, as our results revealed, the speed of the memory combined with CAS latency has the most affect on the overclockability of a memory stick (our test memory would not run at the more aggressive speeds and CAS latencies). The memory timings on our particular setup that had the most impact on performance involved setting the Bank Interleave to 4 Way, decreasing the DRAM command rate to 1T, and decreasing tRCD to 1T.

Reacties (26)

[KaMiKaZe]

Ik kreeg anders wel een performance boost van 10% (300mbps op 3000) door mijn 512MB Samsung PC3200 CL3 op PC2700 CL2 te draaien. Overigens ook gemeten met sandra 2003. Ik gebruik een Gigabyte Sin1394 met sis 655 chipset (dual channel ddr). ik weet zeker dat cas latency WEL een hoop verschil maakt.

Ook is het behoorlijk kortzichtige test, omdat er maar met 1 type ram en 1 type moederbord is getest.ding kan zo de prullenbak in imho.

[Anoniem: 59419]

Ik wet niet precies waarom, maar dat heet te maken met het dual-channel-verhaal. de nForce2 heeft ook Dual Channel DDR, en tests gaven aan dat dat dual channel alleen merbare winst opleverde mits op CAS2 gewerkt werd, zie:
http://www6.tomshardware.com/motherboard/20021111/nforce2-16.html

[dion_b]

Ik denk dat die performance verschil door andere zaken komt, sterker nog, dat 166MHz (PC2700) CL 2.5 of 3 zelfs nog sneller is dan 200MHz (PC3200) CAS 3.

SiS chipsets zijn notoir slecht in asynchrone modi, en juist erg efficient in synchroon met de FSB. Je heft zeker een 166MHz FSB Athlon, gok ik zo

[KaMiKaZe]

Sis 655 is een Pentium 4 chipset en een die officieel DDR400 ondersteunt. Synchrone FSB=133 (4x133=533). Volgens jou zou mijn machine dan op PC2100 het snelste moeten zijn omdat hij dan het meest synchroon loopt. PC2700 CL 3 is helemaal baggertraag.

[dion_b]

De SiS 655 ken ik zeker - maar dat een chipset een bepaalde modus ondersteunt betekent niet dat het ook daarmee het best presteert. Mijn K7S5A (met SiS735 chipset) draait ook op 100/100 beduidend sneller dan op 100/133 met exact dezelfde timings. Zeker als je je FSB op 133MHz hebt, is een 200MHz geheugenbus krankzinnig- de asynch latency vernietigt iedere performance gain die je door de extra clock krijgt. Waarom dat hier wel opgaat en minder voor de gereviewde systeem zet ik in m'n algemene reactie hieronder..

[dion_b]

Deze benchmark is een staaltje heroisch onderzoekwerk met data waar je 'U' tegen kunt zeggen. Helaas is Techware volstrekt tekortgeschoten in zowel de inleiding van het artikel als in de conclusies die ze trekken.

Wat betreft de inleiding had erbij vermeld moeten worden dat het gebruikte systeem, een single-channel DDR P4, een bandbreedte beperkte systeem is bij mem clocks onder de 200MHz. Dat betekent dat alles wat de bandbreedte ten goede komt sterk de test zal beinvloeden, terwijl het effect van latencies minimaal naar voren zal komen. Daarbij komt dat Sandra een goed algemeen testtooltje is, maar veel te grof als het op memory scores aankomt. Het is ook allerminst gevoelig voor latency effecten.

De combinatie van deze twee factoren maakt het bijna vanzelfsprekend dat het effect van de CAS timings zo verwaarloosbaar uit de data komen. De conclusies die met deze opstelling gemaakt zijn, zijn alleen toepasbaar bij bandbreedte-gelimiteerde systemen (dus P4 single channel (DDR-)SDRAM en Athlon met SDR-SDRAM, en P3 systemen met integrated VGA (i810 anyone? )) met applicaties die flink streamen (geluids- en videobewerking bijv.)

Daar staat tegenover dat het effect van de memory clock allicht ook onderschat is. De FSB van het testsysteem is een (quad-pumped) 100MHz. Vermits die gelijk gehouden is, heb je bij 133MHz en nog veel meer bij 166MHz een knoert van een asynchronicity latency. Als ze deze test met een 133MHz FSB P4 gedaan hadden, waardoor er nooit meer dan 25% asynch gedraaid zou worden, zou de relatieve winst van mem clock veel hoger geweest zijn.

IMHO was deze test dan ook veel beter met een Athlon CPU gegaan- omdat het systeem doorgaans niet bandbreedte-beperkt is, zie je de effecten van bijvoobeeld latencies veel sterker. Ten tweede is het mogelijk om door de CPU te unlocken de clock speed gelijk te houden, maar de FSB gelijk met de mem clock in te stellen. Zo worden de snelheidsbenchmarks niet vertekend door asynch latencies.
Tenslotte had de reviewer een betere mem bench programma moeten gebruiken. PCmark 2002 geeft een veel gebalanceerdere en toch 'makkelijk uitvoerbare' bench (ik ben zelf momenteel een flinke benchmark project aan het voorbereiden, en kan erg goed voorstellen waarom iemand die 293 dingen moet benchen gebruiksgemak van de bench belangrijk vindt ), maar ik zou zelf eerder naar Expendable neigen, getuige bijvoorbeeld deze in-depth stuk van Lostcircuits:

One benchmark famous for its sensitivity regarding latencies and bandwidth is Expendable "go.exe". In addition to being very sensitive to memory issues, Expendable also poses substantial demands on the CPU, whereas the graphics adapter is relatively unchallenged.

http://www.lostcircuits.com/memory/latency/3.shtml

Kort samengevat: erg jammer dat zoveel werk zo beperkt toepasbaar is, maar wel leuk om te weten als je een P4 hebt en veel streaming spul doet (DiVX encoden bijvoorbeeld)

Edit: die link hierboven gaat sowieso naar een veel grondigere artikel die weliswaar gedateerd is (anno 2000), maar zeker voor Athlon of dual-channel P4 eigenaars veel relevantere conclusies heeft mbt timings

[Tachyon]

De CAS Latency lijkt verbazingwekkend genoeg weinig invloed te hebben op de geheugenbandbreedte.

Dit geldt natuurlijk alleen voor SiSoft Sandra!

De geheugentest van SiSoft meet eigenlijk alleen de ruwe doorvoersnelheid van het geheugen. In een real-life applicatie waar het geheugen veel wordt aangesproken en waar toegangstijd belangrijker is dan doorvoer (databases?) kan de CL-waarde wel degelijk uitmaken.

De conclusie van het artikel vind ik dan ook onvolledig en misschien zelfs onjuist...

[John_Glenn]

Van http://www.lostcircuits.com/memory/ddr400/2.shtml gehaald:

...in SDRAM, the controller can be set to give the next read command one cycle before the end of the ongoing data burst, however, this implies that with increasing CAS latencies, the gap between successive data transfers would increase. DDR specs are written to do the early read command at exactly one CAS latency before the expiration of the ongoing data burst. The consequence is that if CAS latency is increased, the command will be issued earlier and, therefore, the net difference is zero. Bottom line is that CAS latency hardly matters anymore, only in random accesses is there still a benefit, which, however, is at the border of what is, in fact, measurable.

In het SDR SDRAM tijdperk was CAS latency dus inderdaad heel belangrijk, maar helaas is deze vuistregel blijven hangen, terwijl ze niet van toepassing is op DDR SDRAM. Zoals uit het gelinkte artikel blijkt, is RAS-to-CAS delay veel belangrijker geworden.

[_Thanatos_]

95% toename in bandbreedte is op zich leuk, maar ik vraag me dan wel af hoe dat zich vertaalt naar real-world *overall* performance...

[johnny.xxx]

hier is het geen toename van 95%, maar een verschil tussen de meest snelle optie en de langzaamste.

als je PC1600 cls3 met een stripje PC2700 cls1.5 vergelijkt,
mag je er vanuit gaan dat de 2de een heel stuk sneller is

[Anoniem: 72316]

Hieruit blijkt maar weer eens dat de echte tweakers het bij het rechte eind hadden: de 4-way bank interleave tweak, mits toepasbaar, zal toch wel op elk tweakerssysteem aanwezig zijn, niet? Is het niet via de BIOS, dan is het wel via de VIA chipset tweak of Intel patch.

Die telde jaren geleden al mee, terwijl de RAS/CAS discussie pas veel later op gang is gekomen..

[theXE]

(Let op: 4-way Bank Interleaving is doorgaans alleen mogelijk op reepjes van tenminste 64MB!)

Wie gebruikt er tegenwoordig nog reepjes van 64MB of lager? Ik denk dat tweakers sowieso al beginnen bij 256MB...

Trouwens vind ik het wel opvallend dat de CL dus helemaal niet veel snelheidswinst opleverde in deze test, terwijl het toch iets is waar qua geheugen vaak over gesproken wordt.

[Aetje]

CAS latency betekent kwa bandbreedte niet zoveel, dat is waar. Kwa snelheid van wanneer de data beschikbaar is voor de CPU is het echter een GROTE winst (33%) van CAS3 -> CAS2. Dat wordt hier blijkbaar niet meegenomen, snelheid is pure bandbreedte in deze test.

[Olaf van der Spek]

Het probleem is dat ze helemaal geen snelheid hebben gemeten in de test. Ze hebben bandbreedte gemeten.

Als jij de hele dag SiSoft benchmarks draait heb je inderdaad weinig aan een lagere CL. Maar niet veel mensen draaien de hele dag benchmarks.

Ik snap niet waarom ze geen games hebben gebruikt als benchmarks.

[ANdrode]

omdat dat nog meer werk zou zijn

280+ testen is al veel. als je binnen 2 minuten die reboot kan doen + instellen + sandra (en dan ben je héél snel), dan ben je dus al meer dan 560 minuten bezig

[snooze]

niet alleen de tweakers maar ok de winkels beginnen over het algemeen pas bij 256 MB
(128 MB voor SDR geheugen)

[Anoniem: 2976]

De CAS Latency lijkt verbazingwekkend genoeg weinig invloed te hebben op de geheugenbandbreedte

Wauw! Jij komt tot dezelfde conclusie als de mensen die het artikel hebben geschreven.

[theXE]

Maar die lagere CAS Latency is wel iets waar mensen voor warmlopen als ze nieuw geheugen gaan kopen. Terwijl er dus haast geen snelheidswinst te bekennen valt.

Is natuurlijk wel één test op één moederbord, ik vraag me af of het op meer borden, en met ander geheugen meer zou schelen...

[nhimf]

Die latency zal ook weinig op de bandbreedte uitmaken.
Zodra je veelvuldig het geheugen gaan aanspreken voor verschillende dingen, dan denk ik dat je het wel degelijk zal merken.
Het lijkt erop dat ze dat dus niet getest hebben.
Maar er zijn denk ik ook redelijk weinig dingen die echt heel veel kleine stukjes geheugen benaderen.
En natuurlijk ook: Hoe hoger de frequentie des de minder tijd de latency is. (absolute tijd, niet het aantal ticks.

[eamelink]

Ik heb net vrijdag 2x 512 MB dane-elec pc3200 gekocht, CAS 3

Vond die 2 wat te duur, en had al eerder gelezen dat het hooguit 3% scheelt. Volgens dit dus nog minder

Overigens :
een stijging van 0,002 procent <- Het moet wel ietsje meer zijn, als je het in procenten uitdrukt moet je nog vermenigvuldigen met 100%

[Ruuddie]

Er wordt dan ook geconcludeerd dat de hoogste bandbreedte gehaald kan worden door de timings iets minder agressief in te stellen en de kloksnelheid zo hoog mogelijk te kiezen

Maar dan heb je toch het probleem dat het geheugen niet synchroon met de CPU snelheid loopt, terwijl je die gaat overklokken. En dat maakt ook weer trager.
Ik heb iig altijd gehoord dat je beter je geheugen wat langzamer kan laten lopen, en dan gelijk met de CPU FSB...

En, hoe kan je dat 4-way geheugengebruik eigenlijk aanzetten op een nForce2?

[Sokratesz]

het verhogen van de geheugenbandbreedte heeft een yield van 15%, het zou dus ook ongeveer 15% schelen in realtime

(ter vergelijking: het verhogen van de cpu snelheid heeft een yield van 60%)

[Anoniem: 2141]

ik vind die CAS conclusie erg kort door de bocht, ze kijken ook alleen naar bandbreedte, terwijl er ook nog zoiets is als "hoe snel krijgt de cpu de data waar ie om vraagt ?"..

[Anoniem: 1999]

Inderdaad. Helaas snappen ze blijkbaar niet helemaal dat er verschillende manieren zijn waarop applicaties geheugen-access doen (random access, linear access, repeated access, cache-line fill etc etc), waardoor een miniem verschil met een bepaalde benchmark met een andere benchmark of applicatie wel een flink verschil geeft.
Dus niet verstandig om je tot 1 bepaalde benchmark te beperken, en persoonlijk zou ik al helemaal geen Sandra gebruiken maar liever een aantal real-world apps die geheugen op een verschillende manier gebruiken (denk bv aan een 3D-game als UT2003, data-verwerking met veel processing zoals divx- of mpeg2-encoding, en integer-processing zoals bv winzip).

Zonde van de vele moeite dus.

[Anoniem: 2141]

absoluut.. nix aan toe te voegen guys

[KaMiKaZe]

Juistem, en ik vind het hele verhaal kort. ze testen maar met 1 bepaalde module van 1 bepaald merk op 1 bepaald board. Dat kan gewoon geen representatieve test zijn voor alle geheugens. Je moet gewoon lekker zelf testen wat voor jou de beste settings zijn en nietafgaan op zo'n eenzijdig artikel