Gå til innhold

Mer entusiastsminne fra Corsair


Anbefalte innlegg

Videoannonse
Annonse

Artikkelforfatteren trøtt eller? Dette er vel 2x1GB par og ikke 2x2GB par?

 

Begge produktene består av to moduler som hver har en kapasitet på 2048 MB, slik at den totale kapasiteten er på 4 GB. I følge Corsair har de samarbeidet tett med Nvidia for å optimalisere modulene for bruk på hovedkort med brikkesettet nForce 590.
Lenke til kommentar
Artikkelforfatteren trøtt eller? Dette er vel 2x1GB par og ikke 2x2GB par?

6159799[/snapback]

Korrekt, både til første og andre spørsmål. Takk, nå skal det være rettet opp.

6159802[/snapback]

 

Har det kommet noe utvalg av 2 x 2GB minne enda? Jeg ønsker meg det neste gang da jeg kunne tenke meg mer enn 4GB totalt over tid og kjøre 64-bit på AM2.

Lenke til kommentar
Har det kommet noe utvalg av 2 x 2GB minne enda? Jeg ønsker meg det neste gang da jeg kunne tenke meg mer enn 4GB totalt over tid og kjøre 64-bit på AM2.

6159817[/snapback]

Du kan jo kjøre 4x1GiB for å få totalt 4GiB minne. ;) (Det er jo ikke 4 minneplasser bare for pynt)

 

Men hvis du absolutt vil ha 2x2GiB så er dette det eneste vanlige ubufrede settet i prisguiden.

Lenke til kommentar
Over 4000 kr for 2 GB minne? Er de gale?
Regner nesten med at det finnes et marked for det, så hvorfor ikke melke de "gale" entusiastene? At toppmodellene gir lite per krone er jo ikke noe nytt. For eksempel koster Crucial DDR2 BallistiX PC6400 2048MB kr 3095 på komplett, mens PC8000 utgaven koster 4595. Men for knappe to måneder siden kostet faktisk PC8000 over 6000... Endret av Quintero
Lenke til kommentar
Over 4000 kr for 2 GB minne? Er de gale?
Regner nesten med at det finnes et marked for det, så hvorfor ikke melke de "gale" entusiastene? At toppmodellene gir lite per krone er jo ikke noe nytt. For eksempel koster Crucial DDR2 BallistiX PC6400 2048MB kr 3095 på komplett, mens PC8000 utgaven koster 4595. Men for knappe to måneder siden kostet faktisk PC8000 over 6000...

6160394[/snapback]

Løp og kjøp!

 

Enkelte har rett og slett bare for mye penger... Skulle ønske jeg var en av dem. :cool:

Lenke til kommentar
Har det kommet noe utvalg av 2 x 2GB minne enda? Jeg ønsker meg det neste gang da jeg kunne tenke meg mer enn 4GB totalt over tid og kjøre 64-bit på AM2.

6159817[/snapback]

Du kan jo kjøre 4x1GiB for å få totalt 4GiB minne. ;) (Det er jo ikke 4 minneplasser bare for pynt)

 

Men hvis du absolutt vil ha 2x2GiB så er dette det eneste vanlige ubufrede settet i prisguiden.

6160191[/snapback]

 

vel med amd og ddr1 så ble man da tvunget til å kjøre 2t og det vil man jo unngå!(aner ikke åssen det er på am2

Lenke til kommentar
Har det kommet noe utvalg av 2 x 2GB minne enda? Jeg ønsker meg det neste gang da jeg kunne tenke meg mer enn 4GB totalt over tid og kjøre 64-bit på AM2.

6159817[/snapback]

Du kan jo kjøre 4x1GiB for å få totalt 4GiB minne. ;) (Det er jo ikke 4 minneplasser bare for pynt)

 

Men hvis du absolutt vil ha 2x2GiB så er dette det eneste vanlige ubufrede settet i prisguiden.

6160191[/snapback]

vel med amd og ddr1 så ble man da tvunget til å kjøre 2t og det vil man jo unngå!(aner ikke åssen det er på am2

6162013[/snapback]

Joda, jeg er klar over det. (I hvertfall på eldre revisjoner av prosessorene) Men selv om man må sette 2t command rate så betyr ikke det liv og død for ytelsen. Det betyr faktisk under 1%.

Lenke til kommentar
Joda, jeg er klar over det. (I hvertfall på eldre revisjoner av prosessorene) Men selv om man må sette 2t command rate så betyr ikke det liv og død for ytelsen. Det betyr faktisk under 1%.

6164841[/snapback]

Jeg er enig i at mange er i overkant hysteriske over å måtte bruke 2T, men forskjellen er definitivt mer enn 1%, og det gjelder spesielt når man kjører i dualchannel. Hvis det finnes en betydningsfull minnerelatert timing så er det command rate. Forskjellen mellom 1T og 2T vil øke forsinkelsen til alle kommandoer, i tillegg til å blokkere to sykluser på kommandobussen. Særlig i interleaved mode, som jo er det mest aktuelle, kan det fort bli få ubrukte timeslots. Da er det ganske vesentlig at de bare opptar ett slag istedenfor to. I dualchannel vil også en gitt mengde kolonner (vanligvis 8) leses/skrives i parallell som 2x4 I/O-"sykluser" istedenfor 1x8 (singlechannel), noe som gjør at det blir kortere avstand mellom initsieringen av nye kommandoer, og dermed større risk for kollisjoner. Dette kombinert med stramme minnetimings og en strammere refresh-intervall (som ofte kreves ved bruk av høykapasitets-RAM pga økt antall rader) vil ytterligere øke ytelsespåvirkningen av command rate.

 

Forøvrig finnes det en håndfull eksempler på socket 939 systemer som kjører med fire dualrank brikker på litt over DDR400 med 1T.

Lenke til kommentar
Ok, da lærte jeg noe nytt i dag også. ;) Takk

 

Hvor mye ytelseforskjell mener du det er på 1t og 2t da? (Gjerne i et utvalg reelle programtester)

6167139[/snapback]

Jeg har lenge forsøkt å finne en skikkelig grundig test av reelle applikasjoner, men materialet er ikke akkurat overveldende. Det går jo for det meste på lite interessante båndbreddetester og toy-benches...

 

La meg først få gå litt rundt grøten... Jeg vil hevde at CAS er den viktigste minnetimingen både i teori og praksis, fordi den er involvert i hver eneste output-sekvens. Men jeg er temmelig sikker på at command rate er viktigere enn den igjen. En økning av sistenevnte vil både forskyve fremtidige prosesser, påvirke initsieringen av aktiveringer og lesing/skriving, mens CAS read bare påvirker selve lesingen. Her har jeg sakset ut de mest "virkelighetsnære" testresultater jeg kunne finne om CAS latency. Forskjellen mellom CAS 2 og 3 ser altså ut til å utgjøre nesten 4 % på det meste, noe som må kunne kalles mye til å være en justering av en enkelt minnetiming.

200x12 / 2-2-2-10 :

3DMark 2001 : 351.3 / 156.2

Aquamark 3 : 77661

200x12 / 3-2-2-10 :

3DMark 2001 : 338.2 / 150.9

Aquamark 3 : 75755

200x12 / 2-2-2-10 :

VST Low : 198 FPS

Doom 3 Low : 144.2 FPS

200x12 / 3-2-2-10 :

VST Low : 193 FPS

Doom 3 Low : 142.2 FPS

I minneintensive applikasjoner, som for eksempel spill, kan jeg strekke meg til å si at command rate vil bety opptil 5-6 %. Men som jeg har antydet er det mye som kan få dette forholdet til å variere: Burst length, single/dual channel, refresh timing, burst type (sequential/interleaved) og øvrige latencies. Siden jeg hverken har noe socket 939-system, eller klarer å finne noen skikkelig gode tester, må jeg vel bare forklare med egne ord hvorfor jeg mener at command rate praktisk talt er dømt til å ha større innflytelse enn CAS og en hvilken som helst annen innstilling.

 

 

Først prøver jeg å sette opp et scenario som maksimerer forskjellen mellom 1T og 2T, innenfor rimelighetens grenser. Dvs uten å gå meg helt vill i ekstreme OC-resultater, og uten å tvinge igjennom innstillinger som normalt vil gi dårligere ytelse (f.eks. å benytte unødig lav burst length eller unødig stram refresh timer for å "jukse" frem større forskjeller). Da ser jeg for meg følgende settings for et socket 939-system:

 

"Vanlige" timings: 2-2-2-5 / tRRD-2 / Burst mode: 4-way Interleave / Burst Length: 8 / Dualchannel /

 

Her vil altså de interne operasjonene bare ta 2 kjernesykluser, det samme gjelder for hver I/O sekvens pga dualchannel og 8 burst mode (fordelt mellom kanalene). Under Interleaved mode vil også kommandoene komme mye tettere fordi det hoppes fra bank til bank, istedenfor å lese sekvensielt fra samme rad. I sistenevnte tilfelle vil raden holdes åpen, uten så mange tRCD-initsieringer. Interleaving er fundamentalt for kamuflering av interne minneforsinkelser fordi en bank kan leses fra/skrives til mens de andre enten forbereder seg til overføringer, eller avslutter dem (precharge). Alle DDR1-chiper består av fire interne banker, mens høykapasitets DDR2-chiper har åtte. Begrepet "bank" virker å være veldig misforstått, så jeg skiller bevisst mellom (intern) bank og Rank.

 

Den viktigste forskjellen mellom command rate og interne RAM-operasjoner, er som nevnt at command rate okkuperer to sykluser på kommandobussen, slik at det forsinker timingen til alle operasjoner og samtidig skaper flere kollisjoner. Å slakke opp de interne timingene vil ikke ha fullt så store "ringvirkninger".

 

(Det å øke f.eks. tRCD vil faktisk kunne ha motsatt effekt, som jeg skal kommer tilbake til).

 

 

Så en liten begrepsforklaring:

 

tRRD: Bank-to-Bank eller RAS-to-RAS er den kortest mulige forsinkelsen mellom aktiveringen av forskjellige interne banker på samme Rank. Vanligvis 2 sykluser.

 

Bank (eller Intern Bank): Hver interne bank deler samme kommando -og databuss, men har hver sin Row decoder, Column decoder og Sense Amplifier. Hver kommando appelerer til en bestemt bank, og bare en av dem kan lese/skrive fra databussen på samme syklus. Fordelen med flere banker er først og fremst at de kan påbegynne operasjoner i påvente av at databussen skal bli ledig.

 

Rank: "Elektrisk side". Chipene i en rank vil til sammen ha en bredde på 64 bits på non-Parity/non-ECC moduler, og antallet ranks behøver ikke samsvare med hvor mange fysiske sider av modulen de er montert på.

 

Burst length: Antallet kolonner som "hentes" til I/O bufrene for hver READ kommando (altså for hver CAS forsinkelse). Appellerer også til WRITE.

 

Refresh: En intervall på 64 millisekunder er det vanlige, og dette er altså hvor ofte hver eneste rad må oppfriskes. Jo flere rader, jo flere kommandoer kreves altså for å ivareta dataintegriteten til hele minnesystemet. Dermed øker betydningen av command rate i takt med antallet rader/brikker. Disse "aksessene" hjelper ikke på overføringen av data, men er rett og slett er et nødvendig onde for at minnet i det hele tatt skal fungere. Refresh gjøres ved at minnekontrolleren sender mange ACTIVATE-kommandoer (tRCD) til forskjellige rader, på samme måte som før minnet skal leses fra/skrives til. Ladningene forsterkes av Sense Amplifiers i løpet av tRCD, før de leses, men ved refresh vil raden lukkes igjen med det samme. Om tRCD-forsinkelsen økes fra f.eks. 3 til 4 har det ikke særlig betydning i denne sammenhengen, fordi denne prosessen vil foregå internt, og bare kortvarig blokkere tilgangen til de andre radene i sin interne bank. 2T Command rate vil derimot blokkere en ekstra syklus for hver rad, og både 32 -og 64MB DDR1-chiper (som vanligvis benyttes i hhv 512 og 1024 moduler) kan bestå av 8192 rader for hver interne bank...

I en parantes bør det riktignok nevnes at høyere chip-kapasitet ikke nødvendigvis betyr flere rader, fordi en annen mulighet er å øke radlengden. Refresh-timingen trenger heller ikke endres om man skifter fra single til dualchannel (øker fra en til to brikker) fordi refresh-syklusene i likhet med alt annet vil foregå i paralell (les: respondere på samme kommandoer).

 

 

Diagrammet viser en serie 4-way interleaved lese-sekvenser med timings 2-3-3-x-1T, tRRD 2 og burst length 8 (jeg har manipulert bildet en smule ved å legge til en ekstra DQ-linje for å simulere dualchannel, slik at 8 bursts deles opp i 2x4). En kuriositet ved dette eksempelet er forøvrig at I/O-sekvensen nede til høyre er helt uavbrutt (ingen bobler) - det ville faktisk ikke ha vært mulig hvis tRCD hadde vært strammet fra 3 til 2. Selv om tRCD 2 fortsatt ville gitt lavere Critical Word latency, vil 2-2-2 faktisk gi dårligere båndbredde enn 2-3-2 så lenge de andre timingene er like. READ vil sendes så snart ACTIVATE A er fullført, uansett om en annen ACTIVATE ideelt sett også skulle ha inntruffet da. Nøkkelen til det er at tRCD er høyere enn tRRD, ellers ville ACTIVATE B (altså fra og med andre aktivering) ha kollidert med READ A, og følgelig skapt en boble på databussen (READ A ville fått førsteprioritet fordi den hører til en allerede påbegynt sekvens).

 

Dette diagrammet synes jeg er en bra demonstrasjon på hvor viktig command rate kan være. Grunnet rimelig stramme timings, dualchannel og 4-way interleave er det "trangt om plassen" på kommandobussen (CMD-linjen), så denne sekvensen ville sett svært annerledes ut hvis alle kommandoene måtte ha blitt strukket over to sykluser...post-100025-1148470591_thumb.jpg

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...