Navigator
Hjælp (Tryk her for at lukke)
Artikler - Læs: (www.burn-it.dk/index.php?type=post&id=373)
| Overclockede systemer og stabilitet | |
|
Indledning Jeg er overclocker. Jeg har været det i mange år, og jeg er det af et godt hjerte. Alt der kan overclockes eller tweakes i mit system bliver det! Hver gang jeg køber et nyt bundkort, en ny ram klods, et nyt grafikkort eller en ny cpu er jeg altid meget spændt på hvad jeg mon kan få ud af dette nye stykke hardware. Derfor ligger jeg meget tid og energi i at teste det gennemgående. Dette er efter min bedste overbevisning en rigtig god idé, også selv om man ikke har tænkt sig at overclocke det nyindkøbte hardware. Mange systemnedbrud kan trods alt tilskrives fejlbehæftet hardware eller kompatibilitets problemer af én eller anden slags. Da jeg samtidigt stiller store krav til stabiliteten af mit system er der efter min bedste overbevisning ikke nogen vej udenom gennemgående at teste systemets stabilitet. Nogen vil måske mene at det i sig selv er for meget at forlange 100% stabilitet for et Windows baseret system, men ikke desto mindre irriterer ting som et systemnedbrud, en frossen desktop/applikation eller en spontan genstart mig virkeligt meget. Derfor er det ualmindeligt vigtigt for mig at mit overclockede system som udgangspunkt er mindst lige så stabilt som et system, der kører alt ved default indstillinger. Ikke alle har de samme mål Nu er overclockere en broget skare, og mange overclockere bruger måske ikke deres systemer til andet end at lege med, altså f.eks. køre benchmarks på. Mange af de mest ekstreme overclockere i verden kunne end ikke drømme om at putte deres hardware i et kabinet, og bruger kølingsformer (LN2 f.eks.) som mere hører hjemme på et laboratorium end i en dagligstue. Er du denne type overclocker, er denne artikel ikke for dig! Bruger du derimod, ligesom jeg, dit overclockede system til alt hvad almindelige mennesker nu engang bruger deres pc til, så er her nogle råd til hvordan man undgår overclock relaterede stabilitetsproblemer. Nu er overclockeres opfattelse af hvad der skal til for at et overclocket system er stabilt tilsyneladende noget svingende, hvilket en debat om emnet på http://www.overclocking.dk for nyligt tydeligt demonstrerede. Min påstand er dog, at hvis et system ikke kan køre de samme tests stabilt i overclocket tilstand, som det kan når alt er sat til default, så er det IKKE stabilt. Det kan godt være at det er ”stabilt nok” til det brugeren normalt anvender computeren til, men ret beset er systemet ikke stabilt. At nogle så gerne vil køre deres computere på denne måde er jo helt op til dem selv. Personligt ville jeg aldrig køre min computer 24/7 med noget der ikke er 100% stabilt i noget program. Altså f.eks. hvis Prime95 kan køre fejlfrit når pcen ikke er overclocket, men laver fejl når den er overclocket, så er den ikke stabil. Hvorfor vil man under dagligt brug presse en cpu derop hvor den laver fejl, når det typisk max er 1-5 Mhz fsb eller 10-50 Mhz på cpuen der gør forskellen mellem 100% og ~99% stabil? Det forstår jeg ikke. Start rigtigt Når jeg skal finde min 24/7 indstilling for et nyt system bruger jeg en del tid på det. Først starter jeg med at installere Windows på en frisk formateret harddisk. Og her taler vi ikke om en frisk formateret partition af en harddisk, hvor der på andre partitioner ligger vigtige data! Herefter bliver Windows så opdateret, og de nødvendige chipset og grafikkort drivere bliver installeret. Lad være med at installere et system på en disk med vigtige data, heller ikke selv om de ligger på en anden partition, i det jeg vil kalde ”testfasen”, med mindre du har komplet backup af det hele. Fejl i ram eller fejl pga. en ”for” overclocket cpu kan sagtens ødelægge data og/eller evt. en bootsektor. I dag kan man sædvanligvis låse PCI hastigheden til 33 Mhz, men de af os der har haft overclockede systemer med 40+ Mhz pci hastigheder har nok desværre prøvet at smadre data vi helst ville have beholdt. Og selv om man i dag kan låse agp/pci hastigheden på mange bundkort, så kan enten en fejl i bios, eller én enkelt fejlindstilling i samme ødelægge den sikkerhed. Cpu og ram grundlæggende Derfor tester jeg altid rigtig meget når jeg lige har fået nyt hardware, og stort set aldrig, når det én gang for alle er blevet gennemtestet, og bare kører. Som regel bliver cpuen testet først, hvor højt kan den komme stabilt. Dvs. at jeg sørger for at mine ram kører med timings jeg enten ved at de kan klare, eller ved lavere hastighed end de er mærket som, samt de timinger de er godkendt til. Og ikke noget med at lade spd stå til auto i bios, ind og stil den manuelt. Inden jeg begynder at hardcore overclocke cpu’en, foregår dette i Windows med Prime95 torturetest (kan hentes her http://www.mersenne.org/freesoft.htm ) evt. kombineret med et andet eller evt. flere andre programmer. Jeg går forsigtigt frem, men nøjagtigt hvor mange Mhz jeg øger fsb’en/cpu’ens hastighed kommer meget an på hvilken køling der er på systemet. Er systemet luftkølet går jeg mere stille frem end f.eks. i mit Vapochill baserede system. I denne tidlige fase kører jeg blot Prime95 i en 15-20 min ad gangen. Når jeg så begynder at nærme mig grænsen, og cpu’en begynder at lave fejl i Prime95 går jeg mere stille frem. Herefter begynder jeg at teste i Memtest86 (kan hentes her http://www.memtest86.com ) inden jeg booter ind i Windows. Da en del af testene i Memtest86 er cachede, kan man også tit fange fejl i cpu’en med memtest, i alt fald hvis den er hamrende ustabil. Jeg kører i denne test fase blot ét pass med memtest inden jeg booter ind i Windows. Og bemærk, hvis ikke testen er fejlfri, booter jeg IKKE ind i Windows, men går tilbage til bios og justerer Vcore. Alt efter fejltype kan man oftest se om det er ram eller cpu, der fejler. Pas nu på dit hardware Herefter er det den sædvanlige finjustering af fsb/cpu hastighed og Vcore på cpu’en jeg kaster mig over. Der er meget forskel på hvor meget de forskellige cpu typer, og steppings får ud af at man øger Vcore, og hvor meget man kan øge den uden at smadre sin cpu, alternativt forkorte levetiden betragteligt. Jeg anbefaler at man læser de dokumenter fabrikanten har skrevet om ens cpu og retter sig efter de maksimale værdier, der her er angivet. Ofte er gevinsten ved at gå over ”grænseværdien” yderst marginal, hvis der overhovedet er nogen gevinst, og tilmed får ens cpu en stærkt forkortet levetid. Ram optimering og tweaking Derefter begynder jeg at optimere ram timings, og det foregår også med memtest86 (kan som tidligere nævnt hentes her http://www.memtest86.com ), men denne gang adskillige gange. Igen, i testfasen ændrer jeg kun én indstilling ad gangen, og jeg kører blot ét pass Når (hvis) jeg så begynder at få fejl, bliver Vmem øget, timings justeret op /ned indtil jeg finder ud af hvad de kan. Det tager lang tid, men det er efter min bedste overbevisning tiden værd. Mine pcer har stået i mange timer og tygget memtest86 mens jeg så film, spiste, sov eller noget helt andet. Til sidst, når jeg så ved hvad både min cpu og mine ram kan køre max, er det jo ligetil at finde det bedste kompromis for systemets indstillinger. Grafikkort – generelle betragtninger Når så jeg har fundet ud af det, er det grafikkortets tur. Og det er faktisk ikke så let endda. Mange indstillinger i bios kan nemlig let have betydning for hvor stabilt grafikkortet er. Indstillinger som agp transferrate (8x, 4x, 2x), agp hastighed (default 66 Mhz), agp aperture size (256, 128, 64, 32, 16, 8, 4), fastwrites (on/off) m.fl. kan alt efter grafikkort have stor betydning for grafikkortets stabilitet. Min anbefaling er som udgangspunkt at lade de værdier bios vælger som default være, indtil man har testet grafikkortet gennemgående, og herefter kun skifte én indstilling ad gangen. Grafikkortet Hos mig bliver grafikkortet testet igennem med diverse tests. Og det bliver testet i højeste opløsning med højeste grad af FSAA og AF jeg kan bruge på den skærm jeg har på systemet. Naturetesten i 3dmark2001se er ret effektiv, ellers er diverse OpenGL benchmarks i loop ret effektive. Grunden er at det er de færreste nyere (highend) grafikkort, der bliver specielt pressede i 1024x768. Både GPU og grafikram bliver presset rimeligt hårdt i 1600x1200 med 4/6x FSAA og 8-16x AF. Det betyder at grafikkortet trækker mere strøm og udvikler mere varme. Alt sammen ting, der er med til at belaste både agp port og psu meget mere end det ville i f.eks. 1024x768. Med grafikkortet er man nødt til at være lidt mere opmærksom end med cpu/ram. Der er som udgangspunkt ikke nogen termisk sikring på gpu’er. Derfor kan man altså godt komme til at ødelægge sit grafikkort, hvis man ikke sørger for ordentlig køling. Det er dog ikke ”lykkedes” for mig endnu, men jeg er nok trods alt også mere forsigtigt end den gennemsnitlige overclocker. Jeg starter med gpu’en på grafikkortet og clocker den ~10 Mhz, derefter i intervaller af ca. 5 Mhz indtil jeg ser en grafikfejl, eller systemet evt. fryser. Det første plejer dog at komme først. Naturetesten i 3dmark03 er uhyggeligt effektiv til at afsløre pixelfejl. Hvis jeg ser en fejl, bliver hastigheden sat 10 Mhz ned igen. Så starter jeg på grafikram, og de får samme tur. Når jeg har fundet grænsen for begge dele, og har sat begge 10 Mhz ned i forhold til der hvor der kommer fejl, bliver kortet testet igennem. Mange grafikkort relaterede stabilitets problemer kan nemlig henføres til varme ophobning i systemet. Derfor bliver det haglet igennem adskillige timers test for pixel/grafik fejl. Da jeg stort set altid spiller i meget høje opløsninger, foregår denne del af testningen som regel med et spil. Man kunne også gøre det med 3dmark eller lignende, men jeg har svært ved at koncentrere mig om at se efter grafikfejl i 3 timer i rap. En gang UT2003 i 1600x1200 med 4xFSAA og 8xAF, så skal kortet nok blive varmt, og hvis der er fejl skal man nok se dem når man spiller. Hvilket spil man vælger er smag og behag, bare det er ét som presser grafikkortet. Ofte har jeg erfaret at selv om jeg allerede har sat hastigheden ned fra hvor der kom fejl i 3dmark, ja så skal den faktisk i nogle tilfælde længere ned endnu. Enten kommer der fejl (pga. varme) efter nogen tids spil, eller også er gpu’en presset lige præcist hårdt nok til at hakke i det, uden dog at give grafikfejl. Dette har jeg bl.a. oplevet i Colin McRae Rally 3 (rally bilspil), hvor jeg endte med at måtte clocke min gpu hele 20 Mhz lavere end den er testet 100% stabil (og artifakt fri) til, for at det ikke skulle ”hakke” når jeg spillede. Samlet systemtest Sidst men ikke mindst skal hele systemet testes igennem. Det gør jeg så ved at køre Prime95 (med P4 HT cpu’er kører jeg 2 samtidige tests hvor den ene kun bruger cpu’ens onboard cache, og den anden bruger alt hvad systemet har af ram), samtidigt med at jeg kører 3dmark2001se (kun game tests) i 1600x1200 med 4/6xFSAA og 8/16xAF, alt sammen i lukket kabinet med blæserne på min. og helst i et godt opvarmet lokale. Her i Danmark er der en del forskel på temperaturen om vinteren og om sommeren. Når/hvis man tester sit system for stabilitet mener jeg umiddelbart at man bør stræbe efter at få det stabilt, i hvad man kunne kalde et ”worst case scenario”. Hvis man eksempelvis stabilitets tester i et rum, hvor der er 18°C, og computeren kommer til at stå i solen om sommeren, så snyder man kun sig selv. Luftkølede systemer er naturligvis mere følsomme overfor temperatursvingninger end hhv. vand og kompressorbaserede køleløsninger, men selv disse systemers stabilitet afhænger af lufttemperaturen og luftcirkulationen i kabinettet. Nogle gange kører jeg flere/andre programmer samtidigt med ovenstående, for lige at være ekstra sikker. Det vil så typisk være et disk intensivt program, nogle gange har jeg brændt cd’er. Jeg nøjes dog som regel med at teste på denne måde i cirka 3 timer (minimum), men man kunne med rette sige at 24 timer var mere passende. Det har jeg så ikke mulighed for (computeren står i soveværelset og fruen kan ikke sove når den er tændt…), men det ville alt andet lige være det bedste. Det er meget normalt at man så endnu engang må justere hastigheden ned for en eller evt. flere komponenter i systemet for at opnå stabilitet her. Den samlede varmeudvikling, og det samlede strømforbrug når alle komponenter kører på max er noget større end når blot én komponent stress testes og er på mange måder mere lig den belastning ens system udsættes for når man eksempelvis spiller meget. Hvorfor alt det besvær? Min begrundelse for at teste så gennemgående er som tidligere nævnt, at jeg hader pcer der går ned. Der er som jeg oplever det med computere, intet mere irriterende end en maskine der crasher midt i et spil, eller midt i et større seriøst arbejde/projekt. Jeg spiller en del Flight Sim 2004 (flysimulator) og Grand Prix 4 (formel 1 simulator), som begge er pænt cpu afhængige spil, og jeg gør det tilmed i 1600x1200 med 2-4x FSAA og 8xAF (alt efter hvad grafikkortet kan klare i de enkelte spil). Her flyver/racer man ofte i flere timer, og jeg har tidligere, for en del år siden, prøvet at køre en karriere (i GP2), og være lige ved at vinde et F1 championship efter 1½ times intenst racerløb (og langt over 50 timers forudgående grand prix kørsel), og så crashede maskinen...... De sidste mange år er min maskine aldrig crashet midt i et løb eller en flyvning, og det er mere værd end 50 Mhz ekstra for mig. Jeg håber denne lille artikel måske kan være til hjælp for dem, der gerne vil gøre deres overclockede system stabilt, eller dem endnu ikke har turdet overclocke af frygt for stabilitets problemer. Der er naturligvis mange måder at teste for stabilitet på, min er blot én måde. Men den er baseret på mange års erfaring med systembygning og overclocking. Kort sagt den virker! Skrevet af: Lars Krag Copyright © 2003 www.burn-it.dk |
|
Nice artikkel! Dem vil vi gerne se flere af  |
|
| Bamboocha!! |
| Rigtig fed Artikkel! | |
| At tale før man tænker, er som at tørre røven før man skider |
| Du skal være logget ind for at kunne skrive i forummet! |
