Gå til innhold

DDR4 2133MHz CL13 vs CL15


C64C

Anbefalte innlegg

Ytelsestest av RAM med AIDA64 ved ulike timings, lik RAM-hastighet og CPU-hastighet.

 

i7-5820K @ 3,3 GHz.

 

16GB DDR4 2133MHZ CL 13: (13-13-13-32)

 

Lese: 49023 MB/S

Skrive: 51092 MB/S

Kopiering: 51316 MB/S

Latens: 66,3 ns

 

16GB DDR4 2133MHz CL 15: (15-15-15-35)

 

Lese: 46670 MB/S.

Skrive: 51071 MB/S.

Kopiering: 49111 MB/S.

Latens: 71,1 ns.

Endret av C64C
Lenke til kommentar
Videoannonse
Annonse
  • 1 måned senere...
  • 3 uker senere...

Ja, det er nok raskt en 8 år siden elns siden slike tall var vanlig. Joda, cl13 osv.. er høyt i forhold, med tar det igjen og vell så det med flere titals høyere båndbredde og flere kanaler. :) FOr ikke å snakke om at CPUer i dag også gjene har over 10 ganger så mye hurtigminne integrert i CPUen (over 20 MB på forbrukermodeller), som også er ganske så mye raskere attpåtil, og langt bedre instruksjoner for å hente inn slikt, slik at man har det klart når det trengs. ^^

 

Dette vil da gjøre at CPUen på de mest kritiske oppgavene for svært lav responstid slipper å aksessere RAM i langt mindre grad. Og da vil båndbredden kunne være av økende viktighet.

Endret av Andrull
Lenke til kommentar
  • 2 uker senere...

Ytelsestest av RAM med AIDA64 ved ulike timings, lik RAM-hastighet og CPU-hastighet.

 

i7-5820K @ 3,3 GHz.

 

16GB DDR4 2133MHZ CL 13: (13-13-13-32)

 

Lese: 49023 MB/S

Skrive: 51092 MB/S

Kopiering: 51316 MB/S

Latens: 66,3 ns

 

16GB DDR4 2133MHz CL 15: (15-15-15-35)

 

Lese: 46670 MB/S.

Skrive: 51071 MB/S.

Kopiering: 49111 MB/S.

Latens: 71,1 ns.

 

Hva skal det bety? At lavere latency gir høyere lesehastighet men tregere skrivehastighet?

 

Med de klokkefrekvensene og buffermengdene vi har nå, er det lite vits i å bry seg om cas-latency på minne.

Det var noe annet før med 200mhz ddr-ram hvor det kunne ha litt å si.

Endret av Pycnopodia
Lenke til kommentar

Ja, det er nok raskt en 8 år siden elns siden slike tall var vanlig. Joda, cl13 osv.. er høyt i forhold, med tar det igjen og vell så det med flere titals høyere båndbredde og flere kanaler. :) FOr ikke å snakke om at CPUer i dag også gjene har over 10 ganger så mye hurtigminne integrert i CPUen (over 20 MB på forbrukermodeller), som også er ganske så mye raskere attpåtil, og langt bedre instruksjoner for å hente inn slikt, slik at man har det klart når det trengs. ^^

 

Dette vil da gjøre at CPUen på de mest kritiske oppgavene for svært lav responstid slipper å aksessere RAM i langt mindre grad. Og da vil båndbredden kunne være av økende viktighet.

 

Ja, dobler du latency og båndbredden vil forsinkelsen være den samme.

 

200Mhz med cas latency 2

x 4

800Mhz med cas latency 8

 

Forsinkelsen blir akkurat like lang om du måler i tid (nanosekund f.eks.)

Cas Latencyen kunne ikke bli så mye lavere enn 2, så de økte ytelsen med å øke båndbredde.

 

Før var det stor forskjell på CL 2 og CL 3. Nå kan du ha CL 8 eller CL 10 og det gir omtrent samme ytelse.

Lenke til kommentar

 

Ja, det er nok raskt en 8 år siden elns siden slike tall var vanlig. Joda, cl13 osv.. er høyt i forhold, med tar det igjen og vell så det med flere titals høyere båndbredde og flere kanaler. :) FOr ikke å snakke om at CPUer i dag også gjene har over 10 ganger så mye hurtigminne integrert i CPUen (over 20 MB på forbrukermodeller), som også er ganske så mye raskere attpåtil, og langt bedre instruksjoner for å hente inn slikt, slik at man har det klart når det trengs. ^^

 

Dette vil da gjøre at CPUen på de mest kritiske oppgavene for svært lav responstid slipper å aksessere RAM i langt mindre grad. Og da vil båndbredden kunne være av økende viktighet.

 

Ja, dobler du latency og båndbredden vil forsinkelsen være den samme.

 

200Mhz med cas latency 2

x 4

800Mhz med cas latency 8

 

Forsinkelsen blir akkurat like lang om du måler i tid (nanosekund f.eks.)

Cas Latencyen kunne ikke bli så mye lavere enn 2, så de økte ytelsen med å øke båndbredde.

Nei, det kan ikke stemme.

 

Forsinkelse er et norsk ord for latency, og dobler du latency'en, ja så dobler du også forsinkelsen.

 

Hvis du derimot tenker på ytelsen i helhet, så er det heller ingen sammenheng med at en dobling av båndbredde kan hente inn tiden tapt på en dobling av forsinkelse. Det eneste du kan si er at ytelsen ligger mellom en dobling av ytelse, til en halvering. Joda, ingen endring ligger midt mellom, uten at det betyr alt for mye.

 

Det som bestemmer hva som er viktig er oppgaven, og hva slags data den skal ha tak på. Hvis CPUen etterspør datastrenger som er svært små, så vil latency (forsinkelse) ha nesten alt å si. Når det er store filer/datastrøm, så vil båndbredden ha det meste å si.

 

Ta et praktisk og litt forenklet eksempel da:

Hvis CPUen skal f.eks hente 1 byte med data, og minnet har en båndbredde på f.eks 5 GB/s (la oss si dette er statisk og gjelder alle størrelser) og en total forsinkelse på 50 nanosekunder. Da vil CPUen vente 50,2 nanosekunder totalt.50 nanosekunder før den får svar og overføringen starter, og 0,2 nanosekund på selve overføringen (som da er bidraget fra båndbredden).

 

Hadde du doblet forsinkelsen og doblet båndbredden så får du tilnærmet halvert ytelse, med totalt 100,1 ns. I et slikt ekstremt tilfelle har ikke båndbredden noe å si overhode.

 

Det motsatte er selvsagt sant, og om du skulle ha overført 10 KB med data i en og samme pakke, så blir det samme eksempelet: 50 nanosekunder for forsinkelsen, og 2000 ns for selve overføringen. Totalt 2050 ns. Om du dobler båndbredden og forsinkelsen så blir det da: 1100 ns. Ergo nesten en dobling av ytelse.

 

Kort oppsummert:

Du har kanskje rett i at det kan være en tendes som tisier at dobling av forsinkelsen kan hentes inn med en dobling av båndbredden. (ps: husk at CasL bare er en liten del av den totale forsinkelsen)

Men at de er omvendt-proposjonale stemmer altså ikke. For det er i så fall tilfeldig. :)

Ergo er

Endret av Andrull
Lenke til kommentar

 

 

Ja, det er nok raskt en 8 år siden elns siden slike tall var vanlig. Joda, cl13 osv.. er høyt i forhold, med tar det igjen og vell så det med flere titals høyere båndbredde og flere kanaler. :) FOr ikke å snakke om at CPUer i dag også gjene har over 10 ganger så mye hurtigminne integrert i CPUen (over 20 MB på forbrukermodeller), som også er ganske så mye raskere attpåtil, og langt bedre instruksjoner for å hente inn slikt, slik at man har det klart når det trengs. ^^

 

Dette vil da gjøre at CPUen på de mest kritiske oppgavene for svært lav responstid slipper å aksessere RAM i langt mindre grad. Og da vil båndbredden kunne være av økende viktighet.

 

Ja, dobler du latency og båndbredden vil forsinkelsen være den samme.

 

200Mhz med cas latency 2

x 4

800Mhz med cas latency 8

 

Forsinkelsen blir akkurat like lang om du måler i tid (nanosekund f.eks.)

Cas Latencyen kunne ikke bli så mye lavere enn 2, så de økte ytelsen med å øke båndbredde.

Nei, det kan ikke stemme.

 

Forsinkelse er et norsk ord for latency, og dobler du latency'en, ja så dobler du også forsinkelsen.

 

Hvis du derimot tenker på ytelsen i helhet, så er det heller ingen sammenheng med at en dobling av båndbredde kan hente inn tiden tapt på en dobling av forsinkelse. Det eneste du kan si er at ytelsen ligger mellom en dobling av ytelse, til en halvering. Joda, ingen endring ligger midt mellom, uten at det betyr alt for mye.

 

Det som bestemmer hva som er viktig er oppgaven, og hva slags data den skal ha tak på. Hvis CPUen etterspør datastrenger som er svært små, så vil latency (forsinkelse) ha nesten alt å si. Når det er store filer/datastrøm, så vil båndbredden ha det meste å si.

 

Ta et praktisk og litt forenklet eksempel da:

Hvis CPUen skal f.eks hente 1 byte med data, og minnet har en båndbredde på f.eks 5 GB/s (la oss si dette er statisk og gjelder alle størrelser) og en total forsinkelse på 50 nanosekunder. Da vil CPUen vente 50,2 nanosekunder totalt.50 nanosekunder før den får svar og overføringen starter, og 0,2 nanosekund på selve overføringen (som da er bidraget fra båndbredden).

 

Hadde du doblet forsinkelsen og doblet båndbredden så får du tilnærmet halvert ytelse, med totalt 100,1 ns. I et slikt ekstremt tilfelle har ikke båndbredden noe å si overhode.

 

Det motsatte er selvsagt sant, og om du skulle ha overført 10 KB med data i en og samme pakke, så blir det samme eksempelet: 50 nanosekunder for forsinkelsen, og 2000 ns for selve overføringen. Totalt 2050 ns. Om du dobler båndbredden og forsinkelsen så blir det da: 1100 ns. Ergo nesten en dobling av ytelse.

 

Kort oppsummert:

Du har kanskje rett i at det kan være en tendes som tisier at dobling av forsinkelsen kan hentes inn med en dobling av båndbredden. (ps: husk at CasL bare er en liten del av den totale forsinkelsen)

Men at de er omvendt-proposjonale stemmer altså ikke. For det er i så fall tilfeldig. :)

Ergo er

 

 

Hva måles frekvensen i? MegaHertz.

Hva er hertz? Svingning per sekund.

 

Hvis det skal dobbelt så mange svingninger til, men bølgelengden mellom svingningene er halvert, da snakker vi om nøyaktig like lang tid.

 

 

Tenk at den øverste linjen er cl 3 200mhz og den nederste linjen er cl 6 400mhz.

Dette er en forenkling, men i prinsippet så skal cas-latency målt i sekunder være identisk i begge tilfeller.

post-16776-0-35065700-1417250002_thumb.png

Lenke til kommentar

 

Hva måles frekvensen i? MegaHertz.

Hva er hertz? Svingning per sekund.

 

Hvis det skal dobbelt så mange svingninger til, men bølgelengden mellom svingningene er halvert, da snakker vi om nøyaktig like lang tid.

Tror du muligens har missforstått hva latency er for noe i denne sammenhengen. Det du snakker om er sammenhengen mellom frekvens og båndbredde men hadde ikke med latency å gjøre. I eksempelet ditt så har du i begge tilfeller en latency på 0.

 

Forsinkelsen (latency) er ventetiden, altså, tiden hvor CPUen står å venter på at det skal komme et svar. Ergo ingen bølger eller noe som helst. Båndbredden er hvor mye informasjon det kan overføre per tidsenhet.

post-79251-0-15818900-1417268797_thumb.jpg

 

Ytelsen er representert av den totale tiden brukt, her oppgitt i millisekunder. Øverst er et referansen. I den under så har båndbredden (frekvensen) blitt doblet, og er representert av sinusbølgen. Forsinkelsen er også doblet, og representeres av den rette streken hvor CPUen venter på svar. I følge deg ville ytelsen blitt den samme, men den er i dette tilfellet blitt 25 % dårligere.

 

Det er kun i et tilfelle hvor forsinkelsen og den faktiske båndbredden er nøyaktig like lange at de er omventproposjonale. :)

 

La, meg gjerne komme med et eksempel til, som er lettere å se det på.

F.eks ved en eldre SSD VS HDD. Ta en SSD med båndbredde på ca. 200 MB/s med sekvensiell data, og sammenlign det med en harddisk med f.eks 200 MB/s. Hvem bruker kortest tid på å overføre en enkelt stor fil på f.eks 10 GB? I følge din teori så ville SSDen gjort det ca. 100 ganger raskere, fordi den har en reponstid som er ca. 100 ganger lavere. (8 ms VS 0,08ms)

 

Men som sikkert de fleste har fått med seg så ville de brukt omtrent like lang tid. Rett og slett fordi responstiden vil gi SSDen et forsprang på 7,92 ms, men hatt lik ytelse de resterende 50 000 millisekundene. Den ville da bare vært ca. 0,014 % raskere i dette forenklede tilfellet.

Endret av Andrull
  • Liker 1
Lenke til kommentar

Helt korrekt. Et godt poeng sedsberg.

 

Pleier sjeldent å oppgi forsinkelse i frekvensdomenet, og har i disse eksempelene brukt den totale forsinkelsen. (CasL er ikke dette, og bare en liten del av den totale latencyen/forsinkelsen)

 

Så tenkte ikke over det i det hele tatt. :)

Lenke til kommentar

Andrull, Du blander med asynkron ddr minne. Da er cas-latency en fast tid i nanosekunder.

Men med DDR-SDRAM som vi bruker i datamaskiner og laptoper så er cas latency antall klokkepulser, ikke et fast definert tidsrom.

Dess høyere Mhz, dess kortere tid mellom klokkepulser:

 

DDR-400Mhz Cas latency 3 = 15 ns

DDR2-800Mhz Cas latency 6 = 15 ns

 

Samme latency, men brikken med høyere båndbredde er raskere pga andre forhold. Men selv om cas-latency er høyere så kan faktisk forsinkelse være identisk, det er fordi cas latency må sees i forhold til klokkefrekvens for å finne tiden.

  • Liker 1
Lenke til kommentar

Som sagt så snakker jeg ikke om CAS-L, rett og slett fordi det bare er en liten brøkdel av den totale forsinkelsen som CPUen ser, og i det hele og store av liten betydning om resten ikke følger med (noe de som oftest gjør sånn høvelig vel og merke, men ikke nødvendigvis) .

 

Om du egentlig mener det samme som sedsberg, så har jeg bare ikke forstått forklaringen din, og i utgangspunktet enig. :)

 

Jeg bruker alltid forsinkelse i tidsdomeet, rett og slett for å slippe slik forvirring, men også fordi du da får ut total forsinkelse, ikke bare den mindre betydelige, CASL. ;) Da er 15 ns, 15 ns. ^^ Og er jo også det du får ut når du bencher brikkene. Og dermed sammenlignbart mot alle andre komponenter i maskinen.

Endret av Andrull
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...