Terminologi - CAS osv

[flopflop]

Hei,

 

Skal kjøpe en ny PC som skal klokkes litt om en liten stund, og forsøker å gjøre litt research, og nå har jeg kommet til minne-siden:

Jeg lurer særlig på om noen her på forumet vet om hva det forskjellige tilgangstidene på RAM er, (CAS-tRCD-tRP-tRAS-CMD) og hva de "gjør"? (beklager dårlig formulering). Evt om noen har en link til et sted det blir forklart. Har ikke funnet noen tilfredsstillende steder så langt..

 

I tillegg lurer jeg på dette med høyere mhz og høyere latency-settings vs. lavere mhz og lavere latency-settings, hvordan dette spiller inn mhp ytelse ved overklokking? Ser noen overklokkere forsøker å komme seg opp på så mange mhz som mulig, mens andre har relativt lave mhz-verdier men igjen har svært lave timings på minnet.

 

Takk for all hjelp!

 

 

 

Oppdatert: Fant noen fine artikler om emnet på I_N_T_E_R_N_E_T_T_E_T (det strekker seg over hele verden, vet du!):

 

Memory timings explained

http://www.techpowerup.com/articles/overcl.../AMD/memory/131

 

Enda en guide, litt mer utfyllende

http://www.cooltechzone.com/index.php?opti...id=377&Itemid=0

 

Memory Bandwidth vs. Latency Timings

http://www.pcstats.com/articleview.cfm?articleID=873

 

Wikipedia:

http://en.wikipedia.org/wiki/CAS_Latency

Endret 19. august 2007 av demeyfint

[El Fantasma]

Tror du finner en del info på Wikipedia.

Lykke til!

[Quintero]

La meg først få takke trådstarter for noen meget underholdende linker

 

Forsøksvis avanserte, ultra-BS-perforerte minneguider er noe av det morsomste jeg vet, selv om den til ColdTechZone nesten ble i meste laget. Når tragikomikken fører til pustebesvær er det nemlig ikke så veldig morsomt lenger...

 

Det kan kanskje virke banalt at en vanlig forumbruker foretar seg et slikt angrep på "fagfolk" som det jeg skal gjøre her, men jeg kan ikke hjelpe for det. Som noen av medlemmene sikkert har oppdaget, er jeg ikke særlig redd for å utfordre alskens "sannheter" man finner rundt omkring på websites. Når man er minnespesialist finner man raskt ut at praktisk talt ingenting av det som skrives på nettet er i nærheten av å kunne tas seriøst. Nivået er simpelthen hasardiøst lavt.

 

Mitt første slaktoffer er "guiden" til techPowerUp!

 

CAS (tCL) Timing: CAS stands for Column Address Strobe or Column Address Select. It controls the amount of time in cycles between sending a reading command and the time to act on it. From the beginning of the CAS to the end of the CAS is the latency. The lower the time of these in cycles, the higher the memory performance.

Dette er vel mest et definisjons-spørsmål, men ordene "to act on it" tolker jeg som å påbegynne prosessen. CAS Read er enkelt forklart avstanden fra minnet begynner å respondere på kommandoen til de første 64 bitene er tilgjengelige på den eksterne bussen.

 

tRCD Timing: RAS to CAS Delay (Row Address Strobe/Select to Column Address Strobe/Select). Is the amount of time in cycles for issuing an active command and the read/write commands..

Merkelig språk. Jeg tolker dem slik at tRCD bestemmer lengden på både aktiveringer og lesing/skriving. tRCD er avstanden fra minnet begynner å respondere på en aktiverings-kommando, til en lese/skrive-prosess kan påbegynnes. Med andre ord vil tRCD 3 "reservere" tre sykluser til aktiveringen, og dermed blokkere den kommende kommandoen for å sikre at aktiveringen fullføres før signalene involveres i neste prosess.

 

tRP Timing: Row Precharge Time. This is the minimum time between active commands and the read/writes of the next bank on the memory module.

Det er helt feil. tRP angir hvor mange sykluser minnet disponerer til å lukke en rad, punktum. Hvis en annen rad i samme interne bank skal aktiveres etterpå, vil lengden på tRP bestemme hvor lenge den neste aktiveringen må utsettes. Men når de skriver at dette er den kortest mulige tiden mellom aktiveringer og lesing/skriving av neste bank, kan det ikke tolkes som noe annet enn at tRP også er selve aktiveringen (som jo egentlig er tRCD). Lesing/skriving kan heller ikke inntreffe før raden er aktivert. tRP har heller ikke noen som helst påvirkning på kommandoer rettet mot en annen bank, så dette her blir "full pott" - med feil fortegn.

 

tRAS Timing: Min RAS Active Time. The amount of time between a row being activated by precharge and deactivated. A row cannot be deactivated until tRAS has completed.

tRAS påvirker riktignok avstanden mellom en rads aktivering og lukking (precharge), men "activated by precharge" er mildt sagt på jordet. En rad blir naturligvis ikke aktivert av en lukking, det er jo det stikk motsatte :!:

 

Command Rate: Also called CPC (Command Per Clock). The amount of time in cycles when the chip select is executed and the commands can be issued. The lower (1T) the faster the performance, but 2T is used to maintain system stability. On Intel based machines, 1T is always used where the number of banks per channel are limited to 4.

Grensesprengende! For det første er det chip select-signalet som kvalifiserer en kommando, og dette signalet utsettes med en syklus ved bruk av 2T. På den måten får kontrolleren en ekstra klokke på seg til å generere et korrekt adressesignal, som tar lengre tid jo flere moduler den må drive.

 

Påstanden om Intel-systemer er et av de mest latterlige hardware-eventyrene jeg noengang har blitt utsatt for For å ta en ting, er de fleste Intel-systemer låste på 2T CMD. Det stemmer forøvrig at de har holdt seg til en begrensning på fire ranks pr kanal - uten at det på noen som helst måte er unikt. Det er heller ikke i nærheten av å fungere som noen "1T-garanti". Fire dualrank-moduler er faktisk en ganske tung belastning for kontrolleren, og det er altfor mange faktorer med i bildet til at det ville vært fornuftig å implementere en "1T-lås" i et brikkesett. Alt fra kvaliteten på hovedkortets strømkretser, brikkesettet, slotenes avstand fra kontrolleren, drive strength, og kvaliteten på minnet spiller inn.

 

tRC Timing: Row Cycle Time. The minimum time in cycles it takes a row to complete a full cycle. This can be determined by; tRC = tRAS + tRP. If this is set too short it can cause corruption of data and if it is to high, it will cause a loss in performance, but increase stability.

Denne er faktisk helt feilfri

 

tRRD Timing: Row to Row Delay or RAS to RAS Delay. The amount of cycles that it takes to activate the next bank of memory. It is the opposite of tRAS. The lower the timing, the better the performance, but it can cause instability.

Nei, tRRD er overhodet ikke tiden det tar å aktivere neste rad - da ville jo denne parameteren ha vært selve aktiverings-prosessen. Og dette er heller ikke "det motsatte av tRAS", en forklaring som bare kan kalles for oppdiktet tøv. tRRD er en intervall mellom to rad-aktiveringer i forskjellige interne banker, men har ingenting med lengden på de involverte operasjonene å gjøre.

 

tRFC Timing: Row Refresh Cycle Timing. This determines the amount of cycles to refresh a row on a memory bank. If this is set too short it can cause corruption of data and if it is too high, it will cause a loss in performance, but increased stability.

Den er go

 

# tRW Timing: Write Recovery Time. The amount of cycles that are required after a valid write operation and precharge. This is to insure that data is written properly.

Det stemmer at tWR inntreffer etter skrive-prosessen, men precharge kommer etter den igjen.

 

tRTW/tRWT Timing: Read to Write Delay. When a write command is received, this is the amount of cycles for the command to be executed.

Denne forklaringen skjønner jeg for lite av til å kunne filleriste, men jeg tror de mener at dette enten er forsinkelsen før en Read-to-Write Bus Turnaround utløses, eller lengden på skrive-prosessen. Begge deler er i alle fall feil. Hvor lenge kontrolleren utsetter en turnaround avhenger av organiseringen til lese/skrive-køene og bufrings-kapasiteten. Lengden på Write CAS er alltid 1 tCK på DDR1, og alltid CAS Read - 1 på DDR2.

 

tRTW er databussens "hvileperiode" når trafikken skifter retning, og denne er nødvendig for å sikre at all reststrøm som kan farge signalene er forduftet først.

 

tWTR Timing: Write to Read Delay. The amount of cycles required between a valid write command and the next read command. Lower is better performance, but can cause instability.

Nok en gang helt på jordet. Denne parameteren er ikke tiden mellom mottakelsen av en skrive-kommando til neste lese-kommando. Derimot er den avstanden fra den siste kolonnen skrives til minnet, og til en ny lese-kommando kan mottas av samme rad (eller andre aktive rader i samme rank). Men det er i denne sammenhengen stor avstand mellom sykluser hvor skrivekommandoen mottas, og den siste tilhørende kolonnen skrives internt. Her bommer de i beste fall med flere sykluser.

 

tREF Timing: The amount of time it takes before a charge is refreshed so it does not lose its charge and corrupt. Measured in micro-seconds (µsec).

Denne høres helt grei ut, men jeg har aldri helt fått taket på denne innstillingen.

 

tWCL Timing: Write CAS number. Write to whatever bank is open to be written too. Operates at a rate of 1T, but can be set to others. It does not seem to work with other settings than 1T on DDR. DDR2 is different though.

Denne forklaringen var bemerkelsesverdig bra, etter artikkelens øvrige målestokk.

 

 

 

Så over til den mest horrible artikkelen jeg noensinne har sett. Dette makkverket har tydeligvis utgjort grunnlaget for forumets overklokkingsguide, som jeg gikk nådeløst igjennom i dette innlegget. Jeg ser at un0kai ikke kan klandres for å ha postet feilinformasjon når det står så dårlig til med kildene...

 

The last two specifications in 2/2/2/6-11/1T, tRAS and CMD (short for Command) rate, are somewhat complicated and more difficult to understand than simple access and precharge latencies (the first three specifications). The level of misinformation on tRAS and CMD rate are rampant because some memory manufacturers use it for a concept of performance.

Jeg er utrolig nok enig i at tRAS og Command Rate er to særdeles misforståtte timings - de to troner definitivt øverst på min liste. Men disse karene gir uvitende et aldeles fantastisk bidrag til nettopp det...

 

CMD rate is generally used to describe the time from a chip select until a Row Activate Command can be given. The chip select defines the physical bank in which the row is located. In a system running a single, single-sided memory module, there is never a question which bank will be selected since there is only one.

 

More generally, the CMD Rate is a chipset latency that is not determined by the memory but by the time it takes the chipset to translate the virtual address space into physical memory addresses. Needless to say that higher density system memory with its more addresses will take longer to decode than a single low density module, even if it is double-sided.

Det stemmer at chip select forteller en bestemt rank at den skal respondere på en kommando, men det er også det eneste de har rett i.

 

CMD har ingenting med oversettelse av adresser å gjøre. Store moduler belaster kontrolleren mer, men det handler om kapasitiv last, som gjør at spenningen bruker lengre tid på å bygge seg opp til de riktige verdiene.

 

Intel has taken care of this problem by simply limiting the number of banks supported per memory channel to four. This, in turn allows them to run all their chipsets on a fixed CMD rate of 1T, regardless of how much memory is installed.

Dette punktet var jeg inne på da jeg kommenterte forrige artikkel, og her tar de uansett 100 % feil.

 

Rating a module as 1T is actually somewhat misleading advertising because all unbuffered modules are capable of a 1T CMD rate up to four banks per channel, beyond which chipset limitations become a factor.

Javel ja. Så det er minnet som sender kommandoer til seg selv nå da? Det er ufattelig bak mål å påstå at "modulene kan kjøre på 1T med inntil fire ranks pr kanal" - det er jo brikkesettet som påvirkes av det, ikke brikkene i seg selv (i kommando-sammenheng). Og som sagt, det er milevis ifra at man kan garantere 1T operasjon med fire dobbeltsidige brikker - i praksis er man faktisk ganske nær å kunne garantere at man må bruke 2T (innenfor rimelighetens grenser mtp frekvens). De påstår jo også at først når man går utover fire ranks pr kanal kommer brikkesettets begrensninger med i bildet

 

tRAS and its Importance:

 

Also known as Active to Precharge Delay, this is the time between receiving a request for data electronically on the pins of a memory module and then initiating RAS to start the actual retrieval of data. This command seems important, but really it isn't. Memory access is a very dynamic thing. Sometimes memory is being hit hard, and other times very sporadically. Though at all times, memory access is at constant, therefore, it is rare that the tRAS command is received to access nw data (such as a substantial change, like opening a new program).

Det der håper jeg inderlig er verdensrekord

 

tRAS er et telleverk som blokkerer lukkingen av en rad, for å unngå at transaksjonene avbrytes før tiden. Tellingen starter på samme syklus som minnet begynner å respondere på en aktiverings-kommando, inkluderer CAS med tilhørende overføring av x antall kolonner (varierer), og når tRAS nås er minnet igjen mottakelig for precharge-kommandoer (som lukker raden). Nok en gang ser vi at operasjoner blandes sammen - her gis det tydelig inntrykk av at tRAS er selve aktiveringen...

 

Hvis tRAS var det de prøver å innbille oss, har de hypotetisk sett helt feil i at den er uviktig. Lengden på rad-aktiveringen er unektelig blant de klart viktigste parametrene. Og dynamisk minne-aksess ville i så fall ha gjort parameteren mer viktig, ikke motsatt. Men tRAS i sin egentlige forstand er som regel av svært liten betydning. Det er blant annet fordi rader kan leses i lange sekvenser, ergo "overskrides" verdien med glans. Et annet viktig poeng er at det finnes mange interne banker i de fleste av dagens minnekonfigurasjoner, slik at flere aktive rader kan håndteres uavhengige av hverandre.

 

CAS is Column Address Strobe or Column Address Select. CAS controls the amount of time (in cycles (2, 2.5,& 3) between receiving a command and acting on that command.

"...respondere på "en kommando" - helt uten å presisere hva slags prosess det handler om. Det minner skremmende mye om en bak mål-tolkning av Command Rate.

 

When the request is first electronically set on the memory pins, the first triggered response is tRAS (Active to Precharge Delay). Data requested electronically is precharge, and the memory actually going to initiate RAS is activation.

Nok et eventyr. De sier det egentlig selv - om man har litt basiskunnskap og tar seg tid til å gruble litt over begrepet "Active-to-Precharge" så skjønner man hva tRAS er.

 

Once tRAS is active, RAS, or Row Address Strobe begins to find one half of the address for the required data. Once the row is located, tRCD is initiated, cycles out, and then the exact HEX location of the data required is accessed via CAS.

Kommentar overflødig.

 

The time between CAS start and CAS end is the CAS latency.

En altfor enkel og opplagt forklaring - men utrolig nok riktig!

 

Since CAS is the last stage in actually finding the proper data, it's the most important step of memory timing.

CAS er ofte den viktigste settingen, men begrunnelsen er håpløs. CAS er viktig fordi den har innflytelse på hver eneste lese-sekvens, og leseforsinkelsen har direkte betydning for prosessoren og enkelte øvrige komponenter.

 

tRCD

 

There is an interval between RAS (activated when data is first requested) and CAS (activated when RAS is complete), as memory can't locate a block precisely in a single stage. tRCD is the cycle time between the first stage in memory access, the row strobe, and the second stage.

Utifra selve begrepet - RAS-to-CAS - høres dette ganske sannsynlig ut. Men noen som påtar seg oppgaven å skrive en offentlig guide bør utvilsomt vite bedre. Forklaring har jeg gitt tidligere i tråden.

 

However, the performance impact of this setting is often neglible, as memory tries to store data from programs in sequential order. It tries to keep the same row for a single program, and ordered columns to reduce the time for tRCD.

Det stemmer at tRCD bare må inntreffe en gang pr rad, innenfor visse grenser. I så fall blir også CAS-forsinkelsen bare gjeldende for den aller første transaksjonen i en lengre sekvens. Men et viktigere poeng er muligheten for å kamuflere forsinkelser, som oppnås ved å spre data over flere banker. Da kan aktiveringer foretas mens databussen er reservert av andre adresseområder, slik at forsinkelsen ikke behøver å ha noen som helst betydning.

 

tRP:

 

Also known as RAS Precharge, this is the amount of time it takes for memory to terminate the access in one row and begin another.

Ja, tRP er tiden det tar å lukke en rad. Men det som sies om aktiveringen av neste rad apellerer kun til rader i samme bank - et viktig poeng.

 

This is only an important setting when you're doing massive shifting in data, for example - working with large virtual buffers or video rendering. At that point, several rows are being consumed by a single program, and its advantageous for the program to be able to switch quickly between these rows.

Dette sitatet beviser ettertrykkelig at de ikke aner hva interleaving er for noe. Altså å kunne foreta aktiveringer og lukkinger i bakgrunnen av pågående overføringer.

 

Edit: Redigerte et par punkter.

Endret 13. mars 2007 av Quintero