Overklokking av OCZ Titanium Alpha VX2 PC-8000

[Cortinarius rubellus]

er ikke noe farlig at viften kommer i kontakt med minne, plasten som kommer i kontakt( den treffer bare kjølern på minne). Hvilken vei den bør blåse....jeg personlig velger at den blåser på.

Endret 14. juni 2007 av Fluesopp

[aspic]

Oki.. Men eg har erfart tideligare (ved tweaking av ram) at pc'n ofte klikker heilt og nekter å boote, som igjen gjer at eg må resette cmos (noko som er ei kjedelig oppgåve). Eg må nemlig skru utav skjermkort osv, i tillegg til å stille alt inn på nytt.. Nokon måte å unngå dette på ? =o Ein kan ikkje lagre settingsa i bios eller noko ?

[Cortinarius rubellus]

åssen hk har du? så skal jeg finne det ut

[aspic]

P5B-Deluxe =)

[Cortinarius rubellus]

det har jeg hatt og det var bare i de mest ekstreme forsøkene jeg måtte restarte cmos.Uansett et utsnitt om hket: O.C. Profile

Conveniently store or load multiple BIOS settings

Freely share and distribute favorite overclocking settings

The motherboard features the ASUS O.C. Profile that allows users to conveniently store or load multiple BIOS settings. The BIOS settings can be stored in the CMOS or a separate file, giving users freedom to share and distribute their favorite overclocking settings.

 

så haddejeg vært deg, så hadde jeg brukt en diskett eller usb-pinne siden du sliter med det du gjør

Det gjør ikke cmos restartinga lettere, men du slipper å stille inn alt igjen.

Endret 14. juni 2007 av Fluesopp

[aspic]

Takker.. Får gjere det... Så lenge eg slepp å loade alle settingsa kvar gong så er eg nøgd Kva BIOS-versjon har du? Trur eg har rundt 800 eller noko, er det anbefalt å oppgradere då? =p

 

Må seia eg er litt skeptisk til flashing av bios. Eg har aldri vore ute for uhell, men vil ikkje sjå eit kort til 1400,- gå i søpla.. =/

Endret 14. juni 2007 av aspic

[Cortinarius rubellus]

Solgte det, desverre men jeg anbefaler å oppgradere biosen bare hvis du må eller har problemer med pcen.

[aspic]

Har no:

 

1000MHz@ 4-4-4-6 med 2,25v

 

Kva bør eg gå lavare på etterkvart?

Korleis stiller eg command rate?

 

Kjører ORTHOS og stresser ram. Kjører ca. eit kvarter før eg tweaker meir. Har enno ikkje fått noko problem. Er dette ein grei metode?

[Cortinarius rubellus]

Kan desverre ikke skifte command-rate på kortet der eller de fleste andre for den saks skyld, tro det bare er 680 korta som kan det( er ikke helt sikker på hvem andre)

Du kan prøve å la 4-4-4-6 stå å se hvor langt oppover du får de eller er det bare å sette de ned over hvis du vil se hvor lavt du får de. du har fine timings nå og får du de enda litt raskere så er det bare artig.

Du kan prøve programmet mem-test, som er meget bra til å teste rammen.

[Misantropen]

Hei. Det er et eller annet med at den siste verdien (4-4-4-6) ikke må være for lav i forhold til de tre første, da det kan påvirke ytelsen negativt. Men det du kan prøve er å la den først stå som 6, kjøre en memory benchmark (f.eks. SiSoft SANDRA) deretter sette den til 12 (som er normalt når de tre første står til 4) og se hvordan det påvirker ytelsen.

[Cortinarius rubellus]

Jo lavere du får timingsene og høyere mhz jo bedre, men så klart kommer strapping, sub-timings osv. i tillegg. Det er rett som du sier at det finnes en regel, men jeg husker ikke hele regla. Men å kjøre 4-4-4-12 imot 4-4-4-6 har ikke store forskjellen, selv om en god del som har disse brikkene kjører på 4-4-4-5 eller 4-4-4-6 for de klarer det med ikke altfor høy volt. Største forskjellen ser man når man kan kjøre disse brikkene på 1t og ikke 2t.

For å finne sin beste klokk så må man bare prøve og feile, har blitt overrasket før når det gjelder klokking av minnet

Endret 15. juni 2007 av Fluesopp

[Misantropen]

Etter litt Googling: CAS latency + tRCD + 2 clock cycles = tRas

 

Så da skal man ha f.eks. 4+4+2 = 10. Uansett er dette en verdi som ikke gir en noe ekstra selv om den settes lavt, annet en høyere skryte og e-penis-faktor :!: Ofte kan man få klokket litt høyere om tRas ikke er for lav (10-12 er fint).

[aspic]

Etter litt Googling: CAS latency + tRCD + 2 clock cycles = tRas

 

Så da skal man ha f.eks. 4+4+2 = 10. Uansett er dette en verdi som ikke gir en noe ekstra selv om den settes lavt, annet en høyere skryte og e-penis-faktor  :!:  Ofte kan man få klokket litt høyere om tRas ikke er for lav (10-12 er fint).

8868647[/snapback]

Takker.. Men kvifor er 4-4-4-15 standard på desse brikkene då? 4+4+4 = 12 imo

[Cortinarius rubellus]

det har du helt rett i, det jeg mente var hvis man kan og er fornøyd så er det bare å kjøre lave timings, selv om jeg liker best å få en optimal combo med fart og timings. Den metoden tar litt tid, men man får litt igjen for det.

Penisforstørrer :!:

[Cortinarius rubellus]

Den regelen er grei hvis du skal være sikker, men du kan kjøre så lave timings man vil. Men de blir ikke alltid raskere for det. Du kan få brikkene dine høyere hvis du kjører 4-4-4-12 enn 4-4-4-5 osv.

På brikkene står det 4-4-4-15 for det er garantert at de skal funke på det, men det er opp til deg å finne ut virklig hva som er bra

Grunnen til at man har så lave timings er for å få alt ut av minne hvis man bencher.....til vanlig bruk så merker du ikke forskjell på 4-4-4-6 og 4-4-4-12( har jo litt med hastigheten også) er i superpi o.g.l at du ser forskjellene.

Uff..tror dette ble litt rotete

Endret 15. juni 2007 av Fluesopp

[Quintero]

Etter litt Googling: CAS latency + tRCD + 2 clock cycles = tRas

 

Så da skal man ha f.eks. 4+4+2 = 10.

8868647[/snapback]

Det stemmer faktisk ikke. Selv om den metoden dukker opp over alt, er den helt feil på alle måter. Forøvrig er det verdt å minne om at den er skrevet med DDR1 i tankene, uten at den er mer korrekt av den grunn.

 

Man kan for den del diskutere hvor viktig tRAS egentlig er, for gale innstillinger ser nærmest alltid ut til å bli korrigerte av kontrolleren. Men iallefall...

 

For DDR2 så beregnes minimum tRAS slik:

 

tRCD + tRTP + ((BL / 2) - 2)

 

hvor tRTP er Read-to-Precharge, og BL er Burst Length. Sistenevnte er antall kolonner som overføres pr kanal pr lesekommando. Denne kan enten være 4 eller 8, og er nok vanligvis 8. Altså, i tilfelle tRCD 4, tRTP 3, BL 8, blir tRAS

 

4 + 3 + 2 = 9

 

Når Burst Length er 4, så vil forsinkelsen til selve dataoverføringen "skjules bak" tRTP, derfor vil BL 4 tilsvare 0 i formelen ((BL 4 / 2) - 2 = 0)

 

Her forklarer jeg dette nærmere. Prinsippet er det samme, selv om jeg baserte meg på DDR1:

 

https://www.diskusjon.no/index.php?showtopi...dpost&p=8696780

Endret 15. juni 2007 av Quintero

[Misantropen]

Aha. Da laærte jeg noe nytt i dag også. Hvor finner en "tRTP" for en gitt minnetype forresten? Uansett så det du sier er at tRAS har lite å si for ytelsen, selv om den ideelt sett ikke bør settes for lavt.

 

Skal like å se forskjellen i SuperPI på en 4-4-4-10 og 4-4-4-6 timings... Tror Fluesoppen er ute på tur her.

[Quintero]

Jeg tror ikke det er en parameter som minneprodusentene gir rating på. Hvis den ikke er synlig i BIOS, kan det vel tenkes at noen tweake-programmer gir tilgang til den. På AM2-kort er den ofte i BIOS, og kan enten være 2 eller 3 (på laveste BL), noe som tyder på at den ikke er så veldig sensitiv. tRTP er altså avstanden fra starten av den siste lesekommandoen (CAS) til rad-lukkingen (tRP) kan påbegynnes.

 

Er enig med deg i at denne betyr svært lite for ytelsen. Når en rad leses i lange sekvenser, som er vanlig i praksis, vil ikke tRAS lenger påvirke andre operasjoner. Den er hovedsaklig en minsteverdi som trer i kraft ved korte transaksjoner. En annen ting er at minnet er inndelt i mange interne banker, som kan aktivere og lukke rader uavhengige av hverandre. Det eneste de må dele på er adresse -og databussen. Så selv om en bank blir stående på tomgang i noen sykluser (f.eks. under Precharge) behøver det ikke gi bobler i datastrømmen.

[Cortinarius rubellus]

Aha. Da laærte jeg noe nytt i dag også. Hvor finner en "tRTP" for en gitt minnetype forresten? Uansett så det du sier er at  tRAS har lite å si for ytelsen, selv om den ideelt sett ikke bør settes for lavt.

 

Skal like å se forskjellen i SuperPI på en 4-4-4-10 og 4-4-4-6 timings... Tror Fluesoppen er ute på tur her.

8873712[/snapback]

Tror ikke jeg er på tur, hvis man bencher så teller hvert sekund i superpi foreks.

Og da prøver man å finne lavest og best mulige timings.

Sier ikke at det er store forskjellene.Det er forskjell på 4-4-4-6 og 4-4-4-12, det har jeg sett selv. Så vil jeg frabe meg at du sitter å slenger dritt, men det er jo ikke noe nytt når det gjelder forumet.

Endret 16. juni 2007 av Fluesopp

[Quintero]

Tror ikke jeg er på tur, hvis man bencher så teller hvert sekund i superpi foreks.

Og da prøver man å finne lavest og best mulige timings.

Sier ikke at det er store forskjellene.Det er forskjell på 4-4-4-6 og 4-4-4-12, det har jeg sett selv.

8873939[/snapback]

Tror nok du har rett i det. Jeg har ikke eksperimentert med Superpi og tRAS, jeg pleier bare å sette den til det laveste gyldige alternativet. Men jeg har konstatert at Superpi yter betydelig bedre når man øker mengden, som også er rimelig veldokumentert av overklokkere. Større mengde gir bedre interleaving, dvs at ytelsen øker fordi det blir flere interne minnebanker å spre dataene utover, dermed blir det mindre intern switching mellom forskjellige rader i samme bank. Switching krever ekstra aktivering (tRCD) og lukking (tRP), og det blir også av betydning når de kan påbegynnes - og der spiller tRAS inn.

 

At Superpi yter bedre av større mengde forteller meg at Superpi trolig består av mange små, nokså usammenhengende aksesser, og dermed favoriserer lav tRAS i større grad en de fleste andre applikasjoner. Hvis det bare skal leses noen få kolonner fra en rad, og en annen rad i samme bank skal leses like etter, vil både tRAS og tRP bli direkte involverte i den totale, reelle forsinkelsen før CPU mottar dataene. Hvis den samme banken derimot ikke skal aksesseres igjen på "en stund" så vil hverken tRAS eller tRP ha innflytelse fordi lukkingen da vil foregå i bakgrunnen, og bli fullført før neste aksess til samme bank. Dermed vil banken være klar til å svare på andre forespørsler, uten at den må lukkes først.

Endret 16. juni 2007 av Quintero