Hvad betyder "CL"

http://letmegooglethat.com/?q=...

#1 +1

Hej Søren,

Jeg har tidligere skrevet om dette i en tråd, og jeg forklarer det således:

Timings er tiden, målt i clock cyclus, hvor RAM skal vente for at kunne tilgå data. Derfor skal CL19 vente 19 svinginger på dine RAM for at kunne tilgå data. Hvis du køber 3200MHz RAM kører disse RAM med 3.200.000 svinginger i sekundet, her vil 19 af disse gå på blot at vente, altså de vil intet lave.

Dette kan også måles som forsinkelse, hvor vi ofte snakker nanosekunder, og vi kan sige at RAM enten er hurtige eller langsomme til at reagerer.

Naturligvis vil RAM med lavere ventetid også være hurtigere, dette kan også måles på den rå båndbredde som dine RAM kan spytte ud, men dette har ikke kun noget med CL at gøre. RAM har 4 primære timings, disse ser du ofte skrevet som 19-19-19-32 f.eks., dette er alle vente tider i forskellige dele af dine RAM, men RAM har ikke kun disse 4, der er over 30 forskellige timings, og RAM skal HELE tiden vente på et eller andet, det er derfor at man gerne vil have lave timings, og hvorfor lave timings også giver dig en højere båndbredde.

De første 4 timings og hastighed (sammen med command rate, ofte 1T eller 2T) er beskrevet i en lille chip på 99% af alle RAM (hvis ikke alle). Denne chip hedder en SPD chip. Det er dog begrænset hvad data der kan være i disse.

De sidste 30 (eller hvor mange det nu er) skal herefter sættes af bundkortet selv, det er her hvor forskellige producenter kan være gode eller dårlige. Algoritmerne for det der kaldes for "RAM træning" er nemlig forskellig, og man kan på samme 3200MHz CL19 kit ende op med MEGET forskellige "sub timings", og disse kan nemt diktere den rå båndbredde dine RAM kan spytte ud, det er derfor at forskellige bundkort yder forskelligt med samme hardware, det har intet med CPU'en at gøre, da den altid yder som den skal yde ved en given hastighed.

Man ser ofte at bundkort lige skal genstarte et par ekstra gange efter XMP er slået til, det er netop fordi bundkortet forsøger at træne RAM til at få de mest optimale sub timings, dette er dog langt fra perfekt og kan oftes sættes noget lavere manuelt, men det kræver mange timer at sætte sig ind i, og der er kun en vej, prøv et tal og se hvor godt det er, prøv et ny og se hvor godt det er, og med 30+ timings kan det nemt tage en dags tid.

Min observation med RAM er at hvis du måler rå båndbredde, så kan timings hjælpe sindsygt meget, men hvis det eneste du skal er at spille, og du ikke selv vil justere noget som helst, så er forskellen på et CL19 kit og et CL16 kit så lidt at du nok ikke mærker det, eller måler det.

CL16 kits er dog ofte B-die, hvor det CL19 kit du har fundet sikkert er Micron's revision E. Hvis man overclocker er B-die det man gerne vil have fat i, men micron er nu heller ikke dårlige. Det kan også være SK Hynix chips på det CL19 kit, dem holder jeg mig generelt fra, men igen, skal de bare køre XMP profil uden andre justeringer så vil du ingen forskel mærke alligevel, da RAM yder det samme ved de samme timings/hastighed producenterne imellem.

Benchmarks som Time Spy, Fire Strike, SuperPI og til dels wprime kan RIGTIG godt lide RAM, og det er ofte RAM der kan gøre forskellen mellem en første og en anden plads når vi overclocker.

Hvis du har brug for mere uddybning eller forklaring skriver du bare 😎

http://letmegooglethat.com/?q=...

Skrev zylichh d. 11-12-2019 18:29:23

Med den attitude, kan vi blot google alting. Men vi finder kun svaret på Google, hvis nogen rent faktisk har beskrevet det. Det kunne f.eks. være her på HWT. Med mindre man kun kan svare med "Google er din ven (hår håååår)".

Aaarh men var det her en tråd værdig kontra at google det; skal man også spørge sig selv om.

Aaarh men var det her en tråd værdig kontra at google det; skal man også spørge sig selv om.

Skrev Anomynous d. 12-12-2019 08:25:50

Det hurtige svar er Ja. Men tak fordi du er her.

Ja velbekomme. 

#4 Når du ikke engang gider selv forsøge at finde svaret, så får du kastet LMGTFY i hovedet.

Det er noget helt andet hvis du rent faktisk har forsøgt, men ikke kunne finde noget eller ikke forstod det.

Dit eget engagement afspejles direkte i de svar du får (bortset fra #3 som forbarmer sig over dig).

Jeg forbarmer mig ikke over ham.

Der er ingen der ved om han har forsøgt før, og hvis man ikke kan stille disse spørgsmål i forum, hvor skal de så stilles? Vi har vel et forum for at det skal bruges 🙂

#9 præcis

Hvis forummet her ikke  er til den slags spørgsmål, hvor skal de så stilles. Der er ingen der kender baggrunden for hvad han har prøvet eller ikke har prøvet. Måske han ikke forstår engelsk, der er mange variabler her, og da slet ikke noget man bør blive pigesur over.

#4 Når du ikke engang gider selv forsøge at finde svaret, så får du kastet LMGTFY i hovedet.

Det er noget helt andet hvis du rent faktisk har forsøgt, men ikke kunne finde noget eller ikke forstod det.

 

Dit eget engagement afspejles direkte i de svar du får (bortset fra #3 som forbarmer sig over dig).

Skrev Die_Happy d. 12-12-2019 09:51:24

Det vil sige at du har en antagelse, at disse to scenarier ikke reelt er udtømt. Denne antagelse, hvad bygger du den på?

Dette forum er NETOP til spørgsmål angående hardware blandt andet.....

Som man siger, der er ingen dumme spørgsmål, kun dumme svar  

Hej Søren,

Jeg har tidligere skrevet om dette i en tråd, og jeg forklarer det således:

Timings er tiden, målt i clock cyclus, hvor RAM skal vente for at kunne tilgå data. Derfor skal CL19 vente 19 svinginger på dine RAM for at kunne tilgå data. Hvis du køber 3200MHz RAM kører disse RAM med 3.200.000 svinginger i sekundet, her vil 19 af disse gå på blot at vente, altså de vil intet lave.

Dette kan også måles som forsinkelse, hvor vi ofte snakker nanosekunder, og vi kan sige at RAM enten er hurtige eller langsomme til at reagerer.

Naturligvis vil RAM med lavere ventetid også være hurtigere, dette kan også måles på den rå båndbredde som dine RAM kan spytte ud, men dette har ikke kun noget med CL at gøre. RAM har 4 primære timings, disse ser du ofte skrevet som 19-19-19-32 f.eks., dette er alle vente tider i forskellige dele af dine RAM, men RAM har ikke kun disse 4, der er over 30 forskellige timings, og RAM skal HELE tiden vente på et eller andet, det er derfor at man gerne vil have lave timings, og hvorfor lave timings også giver dig en højere båndbredde.

De første 4 timings og hastighed (sammen med command rate, ofte 1T eller 2T) er beskrevet i en lille chip på 99% af alle RAM (hvis ikke alle). Denne chip hedder en SPD chip. Det er dog begrænset hvad data der kan være i disse.

De sidste 30 (eller hvor mange det nu er) skal herefter sættes af bundkortet selv, det er her hvor forskellige producenter kan være gode eller dårlige. Algoritmerne for det der kaldes for "RAM træning" er nemlig forskellig, og man kan på samme 3200MHz CL19 kit ende op med MEGET forskellige "sub timings", og disse kan nemt diktere den rå båndbredde dine RAM kan spytte ud, det er derfor at forskellige bundkort yder forskelligt med samme hardware, det har intet med CPU'en at gøre, da den altid yder som den skal yde ved en given hastighed.

Man ser ofte at bundkort lige skal genstarte et par ekstra gange efter XMP er slået til, det er netop fordi bundkortet forsøger at træne RAM til at få de mest optimale sub timings, dette er dog langt fra perfekt og kan oftes sættes noget lavere manuelt, men det kræver mange timer at sætte sig ind i, og der er kun en vej, prøv et tal og se hvor godt det er, prøv et ny og se hvor godt det er, og med 30+ timings kan det nemt tage en dags tid.

Min observation med RAM er at hvis du måler rå båndbredde, så kan timings hjælpe sindsygt meget, men hvis det eneste du skal er at spille, og du ikke selv vil justere noget som helst, så er forskellen på et CL19 kit og et CL16 kit så lidt at du nok ikke mærker det, eller måler det.

CL16 kits er dog ofte B-die, hvor det CL19 kit du har fundet sikkert er Micron's revision E. Hvis man overclocker er B-die det man gerne vil have fat i, men micron er nu heller ikke dårlige. Det kan også være SK Hynix chips på det CL19 kit, dem holder jeg mig generelt fra, men igen, skal de bare køre XMP profil uden andre justeringer så vil du ingen forskel mærke alligevel, da RAM yder det samme ved de samme timings/hastighed producenterne imellem.

Benchmarks som Time Spy, Fire Strike, SuperPI og til dels wprime kan RIGTIG godt lide RAM, og det er ofte RAM der kan gøre forskellen mellem en første og en anden plads når vi overclocker.

 

Hvis du har brug for mere uddybning eller forklaring skriver du bare 😎

Skrev freak_master d. 11-12-2019 20:13:30

Hvis at han køber "3200MHz RAM", er de nok 1600MHz, men double data rate... Derved 2*1600, og så igen om hvor mange kanaler de bruger. 

Men vigtigst af alt, du rammer 1000x vedsiden af Jesper. 

Mega 1.000.000, 3200MHz 3.200.000.000 xD

Fin forklaring. 

Latencies kan ses som forsinkelse. Data behandles i cpu (eller gpu*) alt som er udregnes ender i cpu cache; L1, L2, L3 - fra skal det til RAM, og latencies er forsinkelsen på denne proces. 

Det er straks værre hvis at du spørger til command rate; 1T, 2T for så bliver forklaringen af processen kompleks og kræver en "øls tid" at forklare

Angående de mange timings deles det op i 3 kategorier; primære, sekundære, tertiære... Derudover for at gøre det endnu mere kompleks er der interval indstillinger. 

Denne inddeling er baseret på hvor at delay er I hardwaren... Er det på selve ram? På controller(cpu, tidligere Northbridge), på bundkortet... Det bliver dog hurtigt noget rod at kaste sig ud af, da det er platform specifikt. 

Er man nysgerrig har en haj beskrevet det godt i en artikel : Rajinder Gill

https://www.anandtech.com/show...

... Én af de dygtigere på RD hos Asus ROG. 

#13

Lol ja Marc det er jo korrekt, jeg rammer vidst lidt ved siden af, jeg var lidt træt da jeg skrev det tror jeg 😀

"3200MHz" RAM er selvfølgelig 1600MHz, så det er derfor 19 svingninger ud af 1.600.000 og ikke 3.200.000 svingninger, så bliver det også pludselig lidt en smule. 6400 RAM CL19 🤣🤣🤣🤣

Jeg er dog for doven og træt (lige sat mig i stolen) til at redigere det, hvis det irriterer dine øjne kan du bare redigerer det Marc 😎

PS: mangler et dansk udtryk... 

Begrav stridsøksen, det må være nærmeste... 

Vi er alle forskelligt stadie ang. HW, og tråden er yderst passende på forum. 

Hold en god tone hele vejen rundt folkens. 
 

Jeg kunne ikke lige se det beskrevet, men selve forkortelsen CL står for Cache Latency 😉

Jeg kunne ikke lige se det beskrevet, men selve forkortelsen CL står for Cache Latency 😉

Skrev Gripen90 d. 13-12-2019 00:03:38

CAS Latency 🙂

Jeg kunne ikke lige se det beskrevet, men selve forkortelsen CL står for Cache Latency 😉

Skrev Gripen90 d. 13-12-2019 00:03:38

CAS Latency 🙂

Skrev freak_master d. 13-12-2019 01:08:52

Doh ja selvfølgelig...hjernetræt her 😀 Column Access Strobe.

#3 Bliver altsaa noed til at rette/tilfoje dit fine indlaeg

CAS Latancy er altsaa ikke det samme som tiden til at tilgaa data i ram. Det er EN af de mange operationer der skal til

CAS er tiden der tager at faa stroem paa den rigtige kollone i et row

saa ja hvis den rigtie Row allerede er aktiveret Saa er CA tiden til at starte med at kunne laese fra cellen

men er den korrekt ROW ikke aktivere saa skal vi altsaa igennem en del operation foerst og saa er tilgangstide vaesenlige laenger end blot CAS

Trc Er tiden imellem vi har aabnet en row og vi kan aabne en kollone

saa tilgangstiden til en celle er ikke allerde ligger i en aabne ow er altsaa TRCD+CS

Dertil har vi allerede en row aabent og skal aaabne en ny row skal vi lige have den op og koer

Der har vi saa Row Peechargee tiden dvs Trp   . vi er nu oppe paa TRP+TRCD+CS.

Dertil skal der saa ligges evt Refresh Charge tider osv osv. me nder er ikke decidre tilgangstider da de opperate i Realtime og ikke per Data hetning

Det er derfor lidt sjov  at folk sider og regner deres NS ud udelukkende aa CL tide naar det trods alt kun er for adgang til Celler i samme row og man saa helt ignorere tilgangs tiden til celler i andre rows

#13

Bliver ogsaa noed til at rette lidt til her

"alt som er udregnes ender i cpu cache; L1, L2, L3 - fra skal det til RAM, og laten"

Alt er et uultimativt ord or nemt at lave fejl med.

Alt er ukorrekt a tbruge her da der er masser af tilfaelde med CPU som har WT cache istedet for WB cache.

I dette tilfaelde vil resultat fra en cpu udregnings ikke ligge I CPU'ens cache ( foer der bliver spurgt om at hente det ind igen)

MHT til cache kan vi ogsaa kigge paa at forskellige Cache hiraki structuer kan give forskellige forhold til hvor cache data ligger  hvilket ogsaa forklare om hvorfor vi har l3 cache idag

Intels bruger typisk in inklusiv cache. dvsa alt der ligger i et hoejt lag cache (taet pa udreningense delen) er der altid en kopi af i de nedre Cache lag

dvs  L1's data ligger ogsaa i L2. og L2 ( og derved L1) ligger ogsaa i L3

L1 cache formaal er at vare hurtigt. den er lille men hurtige

L2's cache er at vaere stor. og der spare derfor paa hastigheden

L3 cache er der for at holder L1/L2  fra at gaa i tomgang naar de skal hentes data paa krydes af cores

L1 og L2 ligger begge i core.  dvs alle cores har sing egen L1 og L2 cache

Hvis core 2 skal udregner paa data some enande core  maaske har . saa skal core2 over og laese frade andre cores cache hvilket goer at L1/L2 cache ikke kan services derens tilknytte core. Dette kan ske rigtige tit og derved risikier vi at  miste en hel del hastighed

L3 loeser dette smukt fordi L3 er ude fra Cores. det er en faellse pulje alle kan tilgaa.

siden vi er opbygget med inklusive hiraki saa ved vi at vi blot skal kigge i L3 og hvis data IKKE er i L3 sa ved i at det ikke er i nogel andre cores L1/L2 cache og vi behover derfor ikek forstyre alle andre cores

AMD gamle athlon/Duron CPU koert med Exclusive cache. Dvs alt data der var i L1 var ikke i L2

det gjorde naturlgivis at med samem cache stoerelse kunne cpu indeholder mere data i cache da der ikke blev spildt plads med kopiere

det gjorde desvare ogsaa at der tit og ofte skulle roters data imellme cache.

skulle der tommes u i L! for at faa nyt data ud. saa skulel det forste kopiere ud til L2.

paa intel kunne vi frit slette det da L2 have en kopi

fordele og ulemper. altid en balance gang

side bemarkning

CMD rate er ikke en ram timmings men en controller timmings

#19

Forsimplet er 'alt' på sin plads

Derudover snakker vi CPU, ikke blot processor - hvorfor at WB / WT ikke rigtig er af relevans i 2019.

• Du har dog helt ret i det med command rate

"Det er derfor lidt sjov  at folk sider og regner deres NS ud udelukkende aa CL tide naar det trods alt kun er for adgang til Celler i samme row og man saa helt ignorere tilgangs tiden til celler i andre rows"

Fordi at du kan have nok så hurtige subtimings, men de hjælper ikke hvis CAS er høj. Det er set på Vram af flere omgange også (f.eks GTX 660Ti subtimings).

#19

Forsimplet er 'alt' på sin plads

/content/gfx/smilies/wink.gif

Derudover snakker vi CPU, ikke blot processor - hvorfor at WB / WT ikke rigtig er af relevans i 2019.

• Du har dog helt ret i det med command rate

Skrev M.Beier d. 13-12-2019 14:14:01

jeg maa indromme jeg ikke fanger dit argument

Pointen var at du skeev "alt som er udregnes ender i cpu cache"

Hvilket er teknisk forkert. Det er ikke ALT en CPU udregner der komme ud i cache

1: der kan lave WT direkte til ram  dvs de udrenger rammer aldrig i cache

2: Hvis det er til intern brug for naeste udregning er det heller ikke sikkert det kommer ud I cache systemmet

Relevans for 2019 er ligegyldigt. Orde ALT er ultimativt og du havde ingen afgraendning i dit udsagn i dit originale indlaeg. At du har behov for at aendre det nu viser blot at det var korrekt at dit orginale udsagn ikke var korrekt i sig selv.

"Det er derfor lidt sjov  at folk sider og regner deres NS ud udelukkende aa CL tide naar det trods alt kun er for adgang til Celler i samme row og man saa helt ignorere tilgangs tiden til celler i andre rows"

Fordi at du kan have nok så hurtige subtimings, men de hjælper ikke hvis CAS er høj. Det er set på Vram af flere omgange også (f.eks GTX 660Ti subtimings).

Skrev Gripen90 d. 13-12-2019 14:14:51

og omvendt hjalper det heller ikke at have an lav CAS hvis alle andre timings er hoeje

Det er som at fokusere paa Track2Track seek time paa en hd men ignore full stroke seek time

Begge ting har en effekt og den ene boer ikke ignoreres fremfor den anden

Rettelse til mig selv

WT vil ogsaa ramme cache systemmet

WT/WB er blot om der skriver til  RAM lige nu eller senere.

Saa argument 1 er invalidt

"og omvendt hjalper det heller ikke at have an lav CAS hvis alle andre timings er hoeje".

Nej, men det er stadig bedre, da det er den primære latens tid.