Overklokkingsguide for a64 -ferdig

[[email protected]]

jeg har følgende system:

Amd 3500+ 2,2ghz AM2 BOXED Gigabyte GA-M55S-S3, nForce 550, ATX, Socket-AM2, GbLAN, DDR2, Firew, PCI-Ex16, Corsair 1gb ddr2 pc5300, samsung 250gb harddisk, XFX 7600gt XXX

 

ehm tenkte jeg skulle begynne forsiktig med prossesoreren min, hva skal jeg sette den til?

7334621[/snapback]

 

 

Kan du gi litt mer info om kor mange multipler, volt, osv.?

[hølands_gutt]

cpu frequency: 202

cpu clockratio x11

pci clock 100

ddr2 voltage:normal

chipset voltage:normal

HT-link voltage: normal

CPU voltage control:normal

Normal cpu vcore: 1,4000v

[Quintero]

Dette er absolutt en fin guide om generell OC-teknikk. Dessverre er minne-delen direkte dårlig, og jeg velger å kommentere den selv om den ikke er noen sentral del av guiden.

 

Command rate: er tiden det tar å oversette en virtuell minne adresse til en fysisk adresse/hvilken "bank" som skal initsialiseres.

Nei, i denne sammenhengen angir command rate hvor mange sykluser kontrolleren har til disposisjon for å generere et adressesignal, og på 2T vil hver kommando okkupere to sykluser. Alle brikkene deler den samme kommandobussen, og når man installerer flere brikker så øker kapasitansen. Selv om en kommando bare rettes mot en rank (eller to i dualchannel) vil hver ekstra brikke øke belastningen, for på en måte vil hver eneste kommando "nå frem" til alle brikkene. Det brukes bare styresignaler (chip select) til å fortelle de forskjellige brikkene hvorvidt de skal respondere på eller ignorere en bestemt kommando. Så flere brikker gjør at kontrollerens elektriske respons blir tregere, dvs at det tar lengre tid å svitsje mellom spenningsverdiene som representerer 0 og 1 i adressesignalene. Det er grunnen til at 2T er nødvendig for å kompensere for høyere last - dette påvirkes altså av rent elektriske faktorer.

 

Command rate har ingen sammenheng med oversettelse av adresser - det foregår i prosessoren vha en referansetabell (TLB), så den reelle minneadressen er allerede kjent når kontrolleren mottar en forespørsel. Med en porsjon godvilje kan man dog si at command rate har en viss sammenheng med valg av riktig rank (side), fordi det er chip select som til slutt "åpner" riktig del av minnet og får det til å respondere på kommandoen. På 2T utsettes timingen av chip select med ett slag, slik at kontrolleren får ekstra tid til å skape de riktige spenningsverdiene før signalet "slippes" til minnet, men parameteren er alikevel ikke relatert til noen oversettelse av adressene.

 

tRAS (active to precharge delay): Dette er tiden det tar fra minnet mottar en anmodning om data til RAS (Row Adress Strobe) blir initsiert til å hente data. Er egenlig en mindre viktig timig, siden minne aksess er relativt konstant. Dette betyr at tRAS er viktigst når man har store forandringer i data; som å starte et nytt program.

Hvis jeg tolker deg riktig mener du at tRAS er selve aktiveringen, som åpner raden i starten av sekvensen. Men slik er det ikke.

 

Tygg litt på ordene Active-to-Precharge - de gir nemlig en overraskende fullstendig beskrivelse av hva denne parameteren regulerer.

 

Det er tRCD som er selve aktiveringen, og den etterfølges av tCAS (lesing eller skriving), og til slutt tRP (som lukker raden). tRAS skiller seg ut blant annet i det at den ikke er en operasjon - den er bare en counter/trigger som bestemmer det tidligste tidspunktet hvor en lukking kan påbegynnes (telt i antall sykluser fra aktiveringen initsieres). Dette betyr også at tRAS påvirkes av flere andre timings, men det er et komplisert tema som vi ikke trenger gå inn på her. Det er forresten særdeles vanlig at overklokkere bruker veldig lav tRAS, tydeligvis i den tro at verdiene er reelle, og attpåtil gir bedre ytelse. Sannheten er at verdier lavere enn 4-5 ikke engang eksisterer, og om de hypotetisk sett gjorde det ville det vært helt meningsløst å bruke dem. Det ville naturligvis være bak mål å lukke en rad før aktiveringen fullføres, men det bør merkes at BIOS eller kontrolleren ser ut til å ordne dette automatisk (selv om det ikke kommer frem av programmer som CPU-Z).

 

Jeg vet ikke hva du mener med at "minne aksess er relativt konstant", men tipper det er at minnet i liten grad svitsjer mellom forskjellige rader og banker. I realiteten er det stikk motsatt. Det å spre data over flere banker, for å okkupere færrest mulig rader pr bank, er utvilsomt den beste måten å organisere data på (som jeg forklarte deg her). Det finnes forøvrig faktorer som reduserer betydningen av tRCD, men ikke de som du beskriver. Siden interleaving og jevn fordeling kamuflerer forsinkelser, bidrar det til at tRCD blir en mindre kritisk timing enn den kunne ha vært under andre organiserings-metoder.

 

Når en rad først er aktivert kreves det ikke flere operasjoner enn tCAS for å få tilgang til hvilke som helst av dens kolonner, men bare én rad pr bank kan være aktiv samtidig. (Merk at banker er individuelle "kamre" internt i chipene, ikke antallet sider på modulene). Alt DDR1-minne har fire banker, og hver bank har uavhengige enheter for aktivering, lesing og skriving, men de deler samme kommandobuss og databuss. Bank interleaving gir gode muligheter for å kamuflere forsinkelser, fordi de kan forberede seg til/avslutte operasjoner i bakgrunnen av transaksjoner, og fordi data kan fordeles mellom dem.

 

Å drøfte timingenes betydning når det startes et nytt program er selvfølgelig meningsløst fordi harddiskens forsinkelser fullstendig utjevner de marginene.

 

tRCD (RAS to CAS delay): For å lokalise riktig blokk i minne matrisen må man først utføre RAS, som finner korrekt "rad". Deretter må CAS utføres for å finne riktig "kolonne". Som navnet tilsier er tRCD forsinkelsen mellom RAS og CAS.

Jeg ser at det er rom for misforståelser her. Man skulle kanskje tro at tRAS og tCAS var to nært beslektede operasjoner, hvor førstenevnte åpnet radene og sistenevnte åpnet/leste kolonnene. Det virker også som om du tolker tRCD som et "pusterom" mellom dem, noe som utifra begrepet RAS-to-CAS heller ikke høres usannsynlig ut. Men dette er også en misoppfatning.

 

tRCD er som nevnt selve rad-aktiveringen, og den må inntreffe i forkant av enhver lese -og skrive-operasjon (men ikke nødvendigvis umiddelbart før). Hvor ofte aktiveringer må gjentas når det svitsjes mellom rader/banker, kommer an på flere faktorer, som jeg var litt inne på i forrige punkt.

 

CAS (Column Address Strobe): Er den desidert viktigste av tilgangstidene, da den kontrollerer tiden (i klokkesykluser) det tar fra anmodning til minnet blir "lest"

Ja, CAS Read er selve lese-operasjonen, men for at kolonner skal kunne leses må altså raden være aktivert på forhånd. En viktig forskjell mellom tRCD og tCAS er at sistenevnte må inntreffe i enhver lese-operasjon, og er derfor den viktigste interne timingen for AMD-systemer. Command rate har enda større innflytelse for socket 754 og 939, men det er en kontroller-parameter.

 

tRP (RAS precharge): Kontrollerer tiden det tar for minnet å terminere adgang til en "rad" og initsiere adgang til en annen "rad". Denne innstillingen er viktigst når en har store omskifninger av data i minnet. eks: video redigering.

tRP er ganske riktig antallet sykluser som minnet har til disposisjon for å lukke en rad, og i bunn og grunn er den bare det. Operasjonen vil bare forsinke en ny rad-aktivering hvis den forespurte raden befinner seg i samme bank, og det er et viktig poeng som de fleste ser ut til å gå glipp av. Ergo er det ingen automatikk i at lengre tRP utsetter nye aktiveringer, men denne kan ha ganske stor betydning i situasjoner hvor det er mange konflikter. Jo bedre data-organiseringen er, jo mindre innflytelse får tRP.

 

Enkelt beskrevet opererer minnet slik: Prosessoren vil ha data fra en minne adresse --> "Command rate" sender denne anmodningen til riktig minne "bank" --> tRAS bestemmer hvor lang tid til RAS begynner å finne riktig minne rad --> tRCD: forsinking fra RAS til CAS blir initsiert --> CAS bestemmer hvor lang tid til riktig minne kolonne er funnet og kan leses --> tRP bestemmer hvor lang tid det tar å "stenge" en minne rad og aktivere en annen ved å begynne på tRAS igjen. Da pcen prøver å kjøre de fleste programmer på en minne rad trenger ikke denne å være så viktig.

Hvis vi skal følge en spesifikk adresse fra CPU til RAM og tilbake igjen, og vi forutsetter at banken står i aktiv standby (ingen åpne rader), blir dette rekkefølgen:

 

tRCD angir tiden en rad-aktivering tar -> tCAS bestemmer forsinkelsen før de første 8 bytene er tilgjengelige -> tRP lukker raden når tRAS-verdien nås (hvis ønskelig), og gir dermed rom for aktivering av andre rader i samme bank. 2T command rate forskyver enhver sekvens med minst en syklus, og kan også medføre betydelige ringvirkninger i form av kommando-kollisjoner.

 

En aktivering etterfulgt av en lesing av åtte kolonner, med timings 2-2-2-6-8-1T, og tidligst mulig initsiering av tRP, ser slik ut:

 

 

(NB: Merk at på AMD-systemer forutsetter eksemplet singlechannel, eventuelt en ekstra, overlappende CAS-operasjon i dualchannel. Åtte kolonner vil nemlig alltid splittes mellom kanalene til 2x4)

 

 

Til min store ovverraskelse er CAS 1.5 faktisk mer stabilt enn CAS 2. Dvs. ved høvere frekvenser så får CAS 2 flere feil enn CAS 1.5.

Det er strengt tatt ingen overraskelse, for 1.5 vil som regel tilsvare 2.5 i *egentlig* CAS latency. Jeg regner med at ingen enheter støtter CAS 1.5, og er 100% sikker på at Winbond BH/CH ikke gjør det. BH-serien støtter ikke engang CAS 3.0, bare 2.0 og 2.5. CAS Read har nemlig en særegenhet i at hver eneste timing må være implementert i chipene i form av pipeline-trinn, og det er komplett umulig å operere på øvrige verdier uansett spenning og klokkefrekvens.

[un0kai]

Haha, jeg visste jeg var i "deep shit" naar jeg saag at du hadde svart i mine inlegg

 

Takk for en god og utfyllene avklaring paa dette, jeg skal redigere litt i guiden og faa det til aa passe litt bedre inn der. JEg var egentlig veldig usikker paa dette naar jeg skrev det og stoettet meg til diverse artikkler paa nettet som tydeligvis ikke har vert helt "up to date"

 

Men som sagt saa er det heldigvis ikke saa veldig sentralt i guiden saa tviler paa at jeg har voldet noen noe skade, ang cas1.5 saa mener jeg dette er cas 2 samtidig som hket strammer inn noen skjulte sub timings for aa paa en maate emulere cas1.5, ddt gir iallefall samme/litt bedre ytelse enn cas2. Minnekontrolleren til amd stoetter iallefall ikke cas1.5, bare 2, 2.5, og 3, de andre verdiene er reservert eller noe mener jeg aa huske..

 

Jeg synes du skulle ha skrevet en minne relatert guide og postet her paa forumet, jeg har notert meg at du har postet mye intressant angaaende temaet rundt omkring, men savner en plass jeg finner all infoen uten aa maatte lete igjennom traader osv..

[Quintero]

Ja, jeg kom jo med en ganske "nådeløs" gjennomgang, men du tok det ihvertfall som en mann

 

ang cas1.5 saa mener jeg dette er cas 2 samtidig som hket strammer inn noen skjulte sub timings for aa paa en maate emulere cas1.5, ddt gir iallefall samme/litt bedre ytelse enn cas2. Minnekontrolleren til amd stoetter iallefall ikke cas1.5, bare 2, 2.5, og 3, de andre verdiene er reservert eller noe mener jeg aa huske..

Mjo, jeg tror Bigtoe sa at Oscar Wu fikk CAS 1.5 til å yte litt bedre enn CAS 2.0, etter å ha tweaket koden i halvannet år... Så jeg skal ikke utelukke at CAS 1.5, ved å forandre på diverse andre parametre, kan gi bedre ytelse i noen BIOSer.

 

Jeg synes du skulle ha skrevet en minne relatert guide og postet her paa forumet, jeg har notert meg at du har postet mye intressant angaaende temaet rundt omkring, men savner en plass jeg finner all infoen uten aa maatte lete igjennom traader osv..

7548615[/snapback]

Takk for det. Men det spørs om jeg gidder å skrive noen guide. Det er litt for mange "parasitter" her inne, og jeg har ikke akkurat inntrykk av at det er overveldende interesse for en mer teknisk tråd. Det er nok de færreste som henger seg opp i slike detaljer, og det ville dessuten tatt lang lang tid å skrive en helhetlig guide...

[un0kai]

Ja, jeg kom jo med en ganske "nådeløs" gjennomgang, men du tok det ihvertfall som en mann

 

Takk for det. Men det spørs om jeg gidder å skrive noen guide. Det er litt for mange "parasitter" her inne, og jeg har ikke akkurat inntrykk av at det er overveldende interesse for en mer teknisk tråd. Det er nok de færreste som henger seg opp i slike detaljer, og det ville dessuten tatt lang lang tid å skrive en helhetlig guide...

7551283[/snapback]

For aa vaere aerlig saa har jeg ventet paa at noen skulle pirke (eller som i ditt tilfelle, slakte) paa det som jeg skreiv. Informasjonen jeg hadde tilgjengelig naar jeg skreiv det var meget vanskelig aa faa noe fornuftig ut av, de fleste artikler jeg fant var nemlig meget motstridende. JEg ente opp med aa delvis oversette en artikkel jeg ikke husker hvor jeg fant, samtidig som jeg kontrollerte noen fakta mot en tekst jeg fant fra corsair. HVis jeg ikke har vert helt paa jordet selv, saa virker det som om de tekstene ikke har vert helt gode I tillegg saa var det ingen paa diverse fora som gadd aa svare meg naar jeg spurte om ting jeg lurte paa Det virker i bunn og grunn som om meget faa vet noe som helst om dette emnet. Men nok forsvarstaler, jeg er glad du fikk rettet paa meg siden det er teit aa spre misinformasjon, jeg pleier stort sett aa holde kjeft om jeg ikke er saa og sii sikker paa at jeg har rett, men jeg synest at guiden maatte ha med litt om tilgangstider og forklarte etter beste evne

 

Jeg lurer egentlig litt paa hvilken bakgrunn du har siden du virker meget kunnskapsrik paa omraadet?

 

Ang en guide saa har du vel rett ja, sikkert faa som er intressert. Foroevrig saa er vel forum generellt sett plaget med parasitter og spredere av misinformasjon

 

 

Guiden er naa redigert btw.

[Quintero]

Informasjonen jeg hadde tilgjengelig naar jeg skreiv det var meget vanskelig aa faa noe fornuftig ut av, de fleste artikler jeg fant var nemlig meget motstridende. JEg ente opp med aa delvis oversette en artikkel jeg ikke husker hvor jeg fant, samtidig som jeg kontrollerte noen fakta mot en tekst jeg fant fra corsair. HVis jeg ikke har vert helt paa jordet selv, saa virker det som om de tekstene ikke har vert helt gode

Joda, det er ingen tvil om at artikler om emnet stort sett er meget dårlige. Når det gjelder RAM er kunnskapsnivået til testere og skribenter rett og slett skremmende lavt. Uten å påstå at jeg i samme grad er i stand til å vurdere kvaliteten på f.eks. CPU-guider, kan jeg vanskelig forestille meg at de kan være i nærheten av lavmålet man finner i minnerelaterte artikler. Det er også vanlig at de få som har peiling på minnet i seg selv, har altfor liten kunnskap om og/eller fokus på plattform-spesifikke faktorer. Dvs at de trekker frem mye irrelevant stoff som gjelder for andre minnekontrollere enn hva de tester, osv.

 

Jeg oppfatter det ikke som om du kommer med "forsvarstaler", men bare oppgir helt forståelige grunner til hvorfor du klamret deg til noen misforståelser. Alle er jo avhengige av å hente informasjon et sted, og det er jo ikke så greit når man kommer over en rekke motstridige opplysninger. Tonen din var jo heller ikke noe bastant, men mer "jeg skal forklare så godt jeg kan".

 

Jeg lurer egentlig litt paa hvilken bakgrunn du har siden du virker meget kunnskapsrik paa omraadet?

7561844[/snapback]

Jeg er en selvlært lekmann, som bare har vært veldig kresen i mine valg av kilder, og heldig med tilgangen. Gjennom kontakter har jeg fått tak i en bråte design-guider og bøker, som jeg har gått igjennom. Det ble mye lettere etterhvert, men til å begynne med var det et grusomt vanskelig puslespill av begreper og forkortelser som jeg hadde minimal forståelse av...

[skylinepower]

at når man klokker så spill hk, ram og cpu selvfølgelig

er det grunn legende bra nok til meg, sitter det i hodet mitt nå?

ram på 533 delt på 2= max FSB

266*multipler som kan være mye forskjellig=Ghz

hva er multipleseren på de forskjellige cpu er?

 

er dette det grunn legende?

[CIder]

Sniker denne inn i "mine innlegg"...

[Morten K]

er dette det grunn legende?

7765323[/snapback]

Hæ?

Ta det engang til.

[2bb1]

Hei igjen! Prøvde for en stund tilbake å klokke min AMD A64 3200+ (Winchester), men gav opp etter at PC-en kræsjet og ikke ville mer.

 

Men nå har jeg imedlertid funnet ut hva problemet var. Siden jeg har PC-3200/DDR400, noe som vil si at RAM-en min kjører på 200MHz*2 (DDR), så klarer ikke RAM-en fungere når jeg øker FSB/HTT for å få klokket CPU. Derfor må jeg klokke RAM-en også for å få klokket CPU-en (ja, er litt treig ).

 

Men det er fortsatt to ting ang. klokking av minnet jeg ikke forstår.

 

1. Hva vil det si å sette på en "divider"? Noe med FSB:RAM = 4:3 f.eks. slik at når jeg skrur opp FSB/HTT så vil RAM-en kun bruke 3/4 av det FSB står på? (Eks. FSB=250MHz, og FSB:RAM = 4:3. Da kan jeg skru opp FSB til 250MHz, men RAM-en får vanlige 200MHz?

2. Og så må jeg underklokke/skru ned MHz på minnet for å finne stabil CPU-hastighet, men får jeg klokket når jeg skrur "underklokker" minnet, da?

Endret 22. januar 2007 av 2bb1

[un0kai]

1. Du har forstått det sånn noenlunde ja

 

2. Man underklokker kun minnet for å utelukke det som en variabel i regnestykket. Det skal ikke være underklokket til vanlig..

[2bb1]

Okei, får jeg lurer på om jeg bare skal ta å sette en divider på FSB:RAM slik at jeg slipper å overklokke minnet (blir litt tullerusk av alle uttrykkene).

 

Blir det merkbar ytelsesøkning selv om jeg bare setter på divider i steden for å overklokke RAM-en?

Evt. hvor stor forskjell på divider vs. overklokket minne (det er vel litt, men ca. hvor mye?)

[un0kai]

Det er ikke snakk om så mye igrunn... test det ut selv så ser du

[2bb1]

Flott, da bare bruker jeg divider mellom ram og fsb Klokkingen finner sted til helgen

[Dragavon]

Det er egentlig så lite ytelse å hente på å klokke ram at det ikkje er noe å bry seg med i det hele tatt.

 

En Opteron 170 har i utgangspunktet en klokkefrekvens på 2ghz. Dersom du får tak i en god klokker, så får du den opp til 3ghz, og du får tilnærmet nøyaktig 50% bedre ytelse på PCen.

 

Gode DDR400 brikker klarer å kjøre på DDR600 hastigheter. Dersom du oppnår 300mhz hastighet på brikkene dine oppnår du 1-2% bedre ytelse på PCen. Det betyr ingenting. Det eneste stedet du ser store forskjeller når du klokker minnet er testeprogrammer som tester minnebåndbredde. Men det har kun bagatellmessig innvirkning på hele PCen sin ytelse, og det er jo det vi klokker for, ikkje for å sitte og kjøre testeprogrammer hele tiden

 

Klokk prosessoren så mye du klarer, og klokk ned minnet så mye du må, og ikkje bry deg mere med det

[hølands_gutt]

ble utrolig overaskelset da jeg kjøpte en AM2 prossesor altså 3500+ 2,2ghz, som ikke idet hele tatt går ann å klokke, så jeg tror jeg selger denne prossesorern og kjøper med opteron eller en X2.

[2bb1]

Driver og forbereder de siste tingene før jeg skal klokke i morgen, og vil bare forsikre meg om at jeg har oppfattet rett ang. diverse navn og uttrykk.

 

"Hyper Transport Frequency" aka HT multi (HT multi * HTT/FSB = < 1000MHz):

 

 

"CPU Frequency" aka HTT/FSB:

 

 

"CPU Multiplier" aka Multiplieren:

 

 

"Max Memclock (MHz)" aka divideren??

 

 

Og til slutt,

 

Oversikt over CPU Freq. og volt til ram og cpu:

 

 

Temperatur og volt @ stock:

 

 

 

Stemmer det jeg har ramset opp her?

Er litt usikker på divideren.. ?

Endret 25. januar 2007 av 2bb1

[Dragavon]

Det ser ut som om du har skjønt ting riktig ja

[2bb1]

Til og med divideren? I så fall, hva må gjøres utifra skjermbildene over for at jeg da skal få RAM:FSB = 4:5 ?