C64C Skrevet 9. september 2014 Del Skrevet 9. september 2014 (endret) 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 10. september 2014 av C64C Lenke til kommentar
Andrull Skrevet 9. september 2014 Del Skrevet 9. september 2014 (endret) Good, good. Kom gjerne med mer. ^^ Er det KUN CAS Latency som er forandret, eller er flere av de andre tilganstidene også endret? Endret 9. september 2014 av Andrull Lenke til kommentar
C64C Skrevet 10. september 2014 Forfatter Del Skrevet 10. september 2014 (endret) Good, good. Kom gjerne med mer. ^^ Er det KUN CAS Latency som er forandret, eller er flere av de andre tilganstidene også endret? Endret hele veien. Altså 13-13-13-32 vs. 15-15-15-35. Endret 10. september 2014 av C64C Lenke til kommentar
LOBOS Skrevet 29. oktober 2014 Del Skrevet 29. oktober 2014 (endret) Samme mhz så er lavere CL bedre for spill ol, men betydningen er umerkelig i praksis. Her er det hip som hap. Om pris forskjellen ikke er stor, gå for lavere CL (dvs CL13). Endret 29. oktober 2014 av LOBOS Lenke til kommentar
k-orm Skrevet 18. november 2014 Del Skrevet 18. november 2014 Hva er CL? Se pungt 17. i RAM-FAQ. Ofte stilte spørsmål og svar-tråden Lenke til kommentar
Helm Skrevet 19. november 2014 Del Skrevet 19. november 2014 (endret) Se pungt 17. i RAM-FAQ. Ofte stilte spørsmål og svar-trådenTakk. Der er det eksempler på CL 2-3-2-8, så da høres 13-13-13-32 ut som veldig høy latency. Men siden sistnevnte er DDR4 så kan kanskje ikke tallene sammenlignes? Endret 19. november 2014 av Helm Hammerhand Lenke til kommentar
Andrull Skrevet 19. november 2014 Del Skrevet 19. november 2014 (endret) 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 19. november 2014 av Andrull Lenke til kommentar
IntelAmdAti Skrevet 28. november 2014 Del Skrevet 28. november 2014 (endret) 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 28. november 2014 av Pycnopodia Lenke til kommentar
IntelAmdAti Skrevet 28. november 2014 Del Skrevet 28. november 2014 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
Andrull Skrevet 29. november 2014 Del Skrevet 29. november 2014 (endret) 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 29. november 2014 av Andrull Lenke til kommentar
IntelAmdAti Skrevet 29. november 2014 Del Skrevet 29. november 2014 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. Lenke til kommentar
Andrull Skrevet 29. november 2014 Del Skrevet 29. november 2014 (endret) 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. 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 29. november 2014 av Andrull 1 Lenke til kommentar
sedsberg Skrevet 29. november 2014 Del Skrevet 29. november 2014 Men når forsinkelsene er oppgitt i klokkepulser så vil forsinkelsen bli mindre (i tid) når frekvensen økes. CL10 vil være mye kortere tid ved 800MHz enn det ville vært ved 100MHz. 1 Lenke til kommentar
Andrull Skrevet 29. november 2014 Del Skrevet 29. november 2014 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
IntelAmdAti Skrevet 29. november 2014 Del Skrevet 29. november 2014 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. 1 Lenke til kommentar
Andrull Skrevet 29. november 2014 Del Skrevet 29. november 2014 (endret) 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 30. november 2014 av Andrull Lenke til kommentar
Anbefalte innlegg
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 kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå