Valószínűleg mindannyian éreztük már azt a gyomorszorító érzést, amikor egy hosszú, izzasztó munkafolyamat vagy egy éppen kulcspillanatnál tartó játék közben a képernyő hirtelen megmerevedik, vagy rosszabb esetben elsötétül. A számítógépünk szíve, a processzor, amelyet talán nemrég próbáltunk meg gyorsabb működésre bírni, jelezte, hogy elérte a határait. A teljesítmény hajszolása közben sokszor elfeledkezünk arról, hogy a nyers erő mit sem ér, ha a rendszerünk nem képes azt megbízhatóan, nap mint nap leadni. A stabilitás nem csupán egy technikai paraméter, hanem a nyugalmunk záloga: a tudat, hogy a gépünk akkor is teszi a dolgát, amikor nem figyelünk rá, vagy amikor a legnagyobbat kell teljesítenie.
Amikor túlhajtásról beszélünk, valójában a gyártó által megszabott biztonsági határok átlépését és újrarajzolását végezzük el. Ez a folyamat nem fekete-fehér; nem létezik olyan, hogy egy beállítás „tökéletes” minden körülmények között. Inkább egyfajta egyensúlyozásról van szó a feszültség, a hőtermelés és a számítási teljesítmény Bermuda-háromszögében. A tesztelés célja, hogy megtaláljuk azt a pontot, ahol a hardver még boldogan duruzsol, de már kihoztuk belőle a rejtett tartalékokat. Ebben a mélyreható útmutatóban nemcsak a „hogyan” kérdésére keressük a választ, hanem megvizsgáljuk a stabilitás fizikai és szoftveres hátterét is, hogy ne csak kövessük az utasításokat, hanem értsük is, mi történik a szilíciumlapkán belül.
Az elkövetkező sorokban olyan átfogó tudást adunk át, amely segít eligazodni a feszültségszintek, a terhelési tesztek és a diagnosztikai eszközök útvesztőjében. Megtanuljuk értelmezni a rendszer segélykiáltásait, legyen szó kék halálról vagy egyszerű fagyásról, és megmutatjuk, hogyan lehet egy instabilnak tűnő konfigurációból sziklaszilárd munkaállomást faragni. Nem ígérünk gyors sikert, hiszen a tesztelés időigényes folyamat, de azt garantáljuk, hogy a végén sokkal jobban fogod érteni a számítógéped működését, és magabiztosan kezelheted a túlhajtott processzor stabilitását ellenőrző eszközöket.
A stabilitás filozófiája és a szilíciumlottó
Mielőtt fejest ugranánk a technikai részletekbe és a szoftverek tengerébe, érdemes tisztázni, mit is értünk valójában stabilitás alatt a túlhajtott CPU kontextusában. A legtöbb kezdő tuningos elköveti azt a hibát, hogy ha a Windows betölt, a rendszert stabilnak nyilvánítja. Ez azonban olyan, mintha azt mondanánk, hogy egy autó biztonságos, mert beindult a motorja. A valódi stabilitás azt jelenti, hogy a processzor bármilyen terhelés alatt – legyen az egy egyszerű böngészés vagy egy 48 órás videórenderelés – hibátlanul hajtja végre a számításokat.
A processzorok gyártása során minden egyes chip egyedi jellemzőkkel bír. Ez a jelenség a „szilíciumlottó”. Ugyanazon a gyártósoron, ugyanazon a napon készült két azonos típusú processzor viselkedése eltérő lehet. Az egyik alacsonyabb feszültségen is képes magasabb órajelet tartani, míg a másik, „szerencsétlenebb” darab több áramot kér ugyanahhoz a teljesítményhez, ezáltal több hőt is termel. A stabilitás keresésekor tehát nem mások beállításait kell szolgai módon másolnunk, hanem a saját hardverünk egyedi határait kell feltérképeznünk.
A stabilitásnak különböző szintjei vannak. Beszélhetünk „benchmark-stabil” állapotról, ami éppen elég ahhoz, hogy lefuttassunk egy teljesítménymérő programot és dicsekedjünk a pontszámmal, de mindennapi használatra alkalmatlan. És ott van a „24/7 stabil” állapot, ami a célunk: egy olyan rendszer, amely éveken át megbízhatóan működik, nem korrumpálja az adatainkat, és nem omlik össze váratlanul.
A stabilitás nem egy fix pont, hanem egy tartomány. A célunk nem az, hogy a processzor éppen ne fagyjon le, hanem hogy olyan biztonsági tartalékot hagyjunk a beállításokban, amely képes kezelni a környezeti hőmérséklet változását vagy a tápegység feszültségingadozását is.
Az előkészületek és a hardveres alapok
Mielőtt bármilyen stressztesztet elindítanánk, elengedhetetlen, hogy a hardveres környezetünk felkészült legyen a megpróbáltatásokra. A túlhajtott CPU stabilitását vizsgáló tesztek ugyanis extrém terhelést rónak nemcsak a processzorra, hanem az alaplap feszültségszabályozó áramköreire (VRM) és a tápegységre is. Egy gyenge láncszem ezekben a komponensekben nemcsak instabilitást, hanem akár hardveres károsodást is okozhat.
A hűtés szerepe kritikus. A stabilitást gyakran a hőmérséklet korlátozza. Ahogy növeljük a feszültséget a stabilitás érdekében, a hőtermelés négyzetesen növekszik. Egy ponton túl a processzor vagy visszaveszi a teljesítményt (throttling), vagy instabillá válik a túlmelegedés miatt. Ezért a tesztelés megkezdése előtt ellenőriznünk kell a hűtőpaszta állapotát, a ventilátorok profilját és a ház szellőzését. A pormentesítés nem csak esztétikai kérdés; a hűtőbordák közé szorult porréteg szigetelőként viselkedik, ami drasztikusan ronthatja az eredményeinket.
A tápegység (PSU) minősége szintén meghatározó. Stresszteszt alatt a processzor áramfelvétele a névleges érték többszörösére is ugorhat. Ha a tápegység nem képes stabil feszültséget biztosítani (ezt nevezzük feszültségesésnek vagy ripple-nek), a rendszer instabillá válik, még akkor is, ha a processzor egyébként bírná az órajelet.
Az alábbi lépéseket érdemes elvégezni a tesztelés előtt:
- 🛠️ Frissítsük az alaplap BIOS-át a legújabb stabil verzióra, mivel ezek gyakran tartalmaznak stabilitást javító mikrokód-frissítéseket.
- 🛠️ Állítsuk a ventilátorokat 100%-os fordulatszámra a tesztek idejére, hogy kizárjuk a hűtés elégtelenségét mint hibaforrást.
- 🛠️ Kapcsoljunk ki minden felesleges háttérprogramot, hogy a tesztek zavartalanul futhassanak.
Szoftveres fegyvertár: mivel teszteljünk?
A piacon rengeteg szoftver létezik, amely azt ígéri, hogy megizzasztja a processzorunkat. Azonban nem mindegyik egyforma, és nem mindegyik alkalmas ugyanarra a célra. A hatékony stabilizálás kulcsa a megfelelő eszköz kiválasztása az adott feladathoz. Különbséget kell tennünk a szintetikus tesztek és a valós felhasználást szimuláló programok között.
A szintetikus tesztek, mint például a Prime95 vagy az OCCT, olyan matematikai műveleteket végeztetnek a processzorral, amelyek a valós életben ritkán fordulnak elő, de maximális hőtermelést és áramfelvételt generálnak. Ezek a programok kiválóak a legrosszabb forgatókönyv (worst-case scenario) tesztelésére. Ha a gépünk kibír 2 órát a Prime95 „Small FFTs” tesztje alatt, akkor nagy valószínűséggel bármilyen játékkal vagy munkával megbirkózik.
Ugyanakkor a szintetikus tesztek csapdát is rejthetnek. Előfordulhat, hogy a rendszer stabilnak tűnik extrém terhelés alatt, de egy könnyedebb feladatnál, például böngészés közben kék halállal elszáll. Ez az úgynevezett „idle” vagy alacsony terhelésű instabilitás, ami a feszültségkezelés (Vdroop és LLC) finomhangolásának hiányára utalhat. Ezért fontos a vegyes tesztelés.
Íme egy összehasonlító táblázat a legnépszerűbb stressztesztelő szoftverekről, hogy könnyebben választhass:
| Szoftver neve | Teszt típusa | Terhelés mértéke | Ajánlott használat | Előnyök / Hátrányok |
|---|---|---|---|---|
| Prime95 | Szintetikus (Matematikai) | Extrém (Brutális) | Maximális hőteszt és VRM terhelés | Ingyenes, a „standard” tesztelő, de irreálisan magas hőt termelhet. |
| OCCT | Szintetikus + Diagnosztika | Nagyon magas | Általános stabilitás és hibakeresés | Remek felület, beépített monitoring, de az ingyenes verzió korlátozott. |
| AIDA64 | Vegyes (Szintetikus) | Közepes/Magas | Hosszú távú rendszerstabilitás | Kiváló hardverfigyelés, de kevésbé agresszív, mint a Prime95. Fizetős. |
| Cinebench R23 | Valós (Renderelés) | Magas | Gyors ellenőrzés és teljesítménymérés | Valósághű terhelés, de nem elég hosszú a teljes stabilitáshoz. |
| Blender Benchmark | Valós (Renderelés) | Magas | Munkaállomások tesztelése | Ingyenes, valós munkakörülményeket szimulál, kiváló validálásra. |
| HCI MemTest | Memória specifikus | Memória fókuszú | RAM hibák kiszűrése | Kifejezetten a RAM/CPU kommunikációt teszteli, elengedhetetlen a teljes képhez. |
Ne feledjük: egyetlen szoftver sem mindenható. A legbiztosabb módszer a „koktél-tesztelés”, amikor különböző típusú terheléseket váltogatunk, hogy a processzor minden utasításkészletét és energiaszintjét próbára tegyük.
A hőmérséklet monitorozása és a biztonsági zónák
A tesztelés közben a szemünknek folyamatosan a hőmérsékleti adatokon kell csüggenie. De mit is nézzünk pontosan? A modern processzorok tele vannak hőszenzorokkal. A legfontosabb érték általában a „Package Temperature” vagy a legmelegebb mag hőmérséklete. A monitoringhoz olyan szoftvereket ajánlott használni, mint a HWiNFO64, amely nemcsak a hőmérsékletet, hanem a feszültségeket, az áramfelvételt és a VRM hőmérsékletét is képes naplózni.
A stabilitás és a hőmérséklet kéz a kézben jár. A fizika törvényei szerint a félvezetők vezetőképessége változik a hőmérséklettel. Magasabb hőmérsékleten nagyobb az elektronvándorlás (leakage), ami tovább növeli az áramfelvételt és a hőt – ez egy ördögi kör. Ha a processzor eléri a gyártó által meghatározott maximális hőmérsékletet (TjMax, általában 90-100°C), bekapcsol a védelem, és visszaveszi az órajelet. Ez a throttling. Ha stresszteszt közben throttling lép fel, a teszt érvénytelen, mert a processzor már nem azon a teljesítményszinten üzemel, amit tesztelni akartunk.
A túlhajtott CPU stabilitását akkor tekinthetjük elfogadhatónak hőmérséklet szempontjából, ha a legkeményebb szintetikus tesztek alatt is legalább 5-10 fokkal a TjMax alatt maradunk. Hosszú távú használatnál (játék, munka) pedig érdemes a 70-80°C tartományban tartani a hőmérsékletet a processzor élettartamának megőrzése érdekében.
Fontos megérteni a „delta T” fogalmát is. Ez a környezeti hőmérséklet és a processzor hőmérséklete közötti különbség. Télen, egy hűvös szobában könnyű stabil tuningot elérni, de ugyanaz a beállítás nyáron, 30 fokos kánikulában instabillá válhat. Ezért a stressztesztelésnél mindig kalkuláljuk bele a legrosszabb környezeti feltételeket is.
A Load-Line Calibration (LLC) misztériuma
Amikor a BIOS-ban beállítunk egy feszültségértéket (például 1.35V), hajlamosak vagyunk azt hinni, hogy a processzor pontosan ennyit is kap. A valóság azonban ennél bonyolultabb. Terhelés alatt a feszültség természetes módon esik (ez a Vdroop jelensége). Ez egy szándékos tervezési tulajdonság az Intel és az AMD részéről, hogy megvédjék a processzort a feszültségtüskéktől, amikor a terhelés hirtelen megszűnik.
Túlhajtásnál azonban ez a feszültségesés instabilitást okozhat. Ha üresjáratban beállítunk 1.35V-ot, de terhelés alatt ez leesik 1.28V-ra, a processzor lefagyhat, mert az adott órajelhez kevés az 1.28V. Itt jön a képbe a Load-Line Calibration, vagy röviden LLC. Ez a funkció arra utasítja az alaplap VRM áramkörét, hogy terhelés alatt kompenzálja a feszültségesést, és tolja feljebb a feszültséget.
Az LLC beállítása kritikus a stabilizálás során. A legtöbb alaplapon több szintje van (pl. Level 1-től Level 8-ig, vagy Low-tól Extreme-ig). A kezdők gyakran elkövetik azt a hibát, hogy a legmagasabb szintre állítják az LLC-t, hogy „vasbeton” stabil legyen a feszültség. Ez azonban veszélyes. A túl agresszív LLC túllövést (overshoot) okozhat: amikor a terhelés megszűnik, a feszültség a pillanat tört részére veszélyesen magasra ugorhat, mielőtt a szabályozó észbe kapna. Ez hosszú távon degradálhatja a chipet.
A helyes módszer a közepes vagy enyhén magas LLC szint megtalálása, ahol van némi Vdroop (ami egészséges), de nem annyi, hogy instabilitást okozzon. A HWiNFO64 segítségével figyelhetjük a „Vcore” szenzort terhelés alatt és üresjáratban, hogy lássuk, hogyan viselkedik a választott LLC szint.
Az LLC nem varázslat, hanem egy fegyver, ami visszafelé is elsülhet. A cél nem a tökéletesen egyenes feszültségvonal elérése minden áron, hanem egy olyan szabályozott esés, ami még stabilan tartja a rendszert, de megvédi a processzort a gyilkos feszültségtüskéktől a terhelésváltások pillanatában.
AVX utasításkészlet: A processzorok kriptonitja
A modern processzorok egyik legnagyobb kihívása az AVX (Advanced Vector Extensions) utasításkészlet kezelése. Ezek az utasítások rendkívül hatékonyak bizonyos matematikai és multimédiás feladatoknál, de cserébe brutális terhelést rónak a processzorra. Egy AVX-alapú teszt (mint a Prime95 újabb verziói) akár 30-40%-kal több hőt termelhet és áramot vehet fel, mint egy hagyományos, nem AVX-es terhelés.
Gyakori jelenség, hogy a túlhajtott processzorunk tökéletesen stabil 5.0 GHz-en a legtöbb játékban és programban, de amint elindítunk egy AVX-et használó videokódolást, a rendszer azonnal összeomlik vagy túlmelegszik. A stabilitás ellenőrzésénél ezért külön kell kezelnünk az AVX és nem-AVX terheléseket.
A BIOS-ban található „AVX Offset” (vagy hasonló elnevezésű) beállítás életmentő lehet. Ez lehetővé teszi, hogy megadjunk egy negatív szorzót, ami csak akkor lép életbe, ha a processzor AVX utasítást érzékel. Például, ha az alap órajelünk 5.0 GHz, és beállítunk egy -2-es AVX Offsetet, a processzor 4.8 GHz-re lassul vissza az AVX feladatok alatt. Ezzel megőrizhetjük a magas órajelet a játékokhoz (melyek többsége nem használ intenzív AVX-et), miközben a stabilitást is garantáljuk a nehezebb munkákhoz. A tesztelés során futtassunk dedikált AVX és AVX-mentes stresszteszteket is (a Prime95-ben és az OCCT-ben ez külön kapcsolható), hogy finomhangolhassuk ezt az értéket.
Kék halálok és hibakódok: A rendszer nyelve
Amikor a stabilitás tesztelése során a rendszer összeomlik, a legtöbben bosszankodnak. Pedig a Kék Halál (BSOD – Blue Screen of Death) valójában a barátunk: értékes információt közöl arról, hogy mi a baj. A Windows hibakódjai segíthetnek beazonosítani, hogy a processzor melyik része éhezik feszültségre, vagy éppen a memóriavezérlővel van-e gond.
A túlhajtott CPU stabilitását keresve nem csak vaktában kell emelnünk a feszültséget. Ha megtanuljuk olvasni a hibakódokat, célzottan avatkozhatunk be. Például az Intel processzoroknál a „WHEA_UNCORRECTABLE_ERROR” gyakran a kevés Vcore (magfeszültség) jele, míg a memóriahibák más kódokat generálnak.
Az alábbi táblázatban összegyűjtöttük a leggyakoribb hibajelenségeket és azok valószínű okait túlhajtás esetén:
| Hibajelenség / Kód | Valószínű ok | Javasolt megoldás |
|---|---|---|
| Azonnali újraindulás (nincs kék halál) | Súlyos feszültséghiány (Vcore) | Növeld a Vcore feszültséget vagy csökkentsd az órajelet. |
| WHEA_UNCORRECTABLE_ERROR (0x124) | Kevés Vcore feszültség | Enyhe Vcore emelés szükséges. |
| CLOCK_WATCHDOG_TIMEOUT (0x101) | Kevés Vcore, vagy instabil mag | Az egyik mag nem tud szinkronizálni. Vcore emelés. |
| IRQL_NOT_LESS_OR_EQUAL (0x0A) | Memória vagy IMC (Uncore) instabilitás | VCCSA/VCCIO (Intel) vagy SOC feszültség (AMD) finomhangolása. |
| PAGE_FAULT_IN_NONPAGED_AREA (0x50) | Memória időzítés vagy feszültség hiba | Lazíts a RAM időzítéseken vagy emelj RAM feszültséget. |
| Programok bezáródása hibaüzenet nélkül | Enyhe instabilitás (RAM/CPU határ) | Hosszabb tesztelés szükséges, gyakran a RAM vagy a Ring Bus okozza. |
| Egér fagyás, akadás Windowsban | Kevés feszültség üresjáratban | LLC szint módosítása vagy az energiatakarékos módok (C-States) kikapcsolása. |
A hibakeresés türelemjáték. Soha ne változtassunk egyszerre több paramétert a BIOS-ban! Ha egyszerre emelünk Vcore-t és állítunk a memórián, majd a rendszer stabil lesz, nem fogjuk tudni, melyik lépés volt a megoldás, és esetleg feleslegesen kínozzuk a hardvert magasabb feszültséggel.
A hosszú távú validálás: A 24 órás szabály
Sokan elkövetik a hibát, hogy 10-15 perc sikeres stresszteszt után hátradőlnek. A valóságban a félvezetők melegedése lassan éri el az egyensúlyi állapotot, különösen vízhűtéses rendszereknél, ahol a hűtőfolyadéknak akár 30-40 perc is kellhet, hogy átmelegedjen. Egy rövid teszt nem mutatja meg, hogyan viselkedik a rendszer, amikor a hűtővíz már 40 fokos, és nem tudja olyan hatékonyan elvonni a hőt.
A stabilizálás utolsó lépése a hosszú távú validálás. Ez nem feltétlenül jelent 24 órás Prime95 futtatást (ami feleslegesen nagy terhelést jelenthet), de egy 4-8 órás, vegyes terhelésű tesztciklus erősen ajánlott. A RealBench vagy az AIDA64 Stability Test kiváló erre a célra, mert a memóriát, a gyorsítótárat és a processzormagokat egyszerre terheli, szimulálva egy nehéz munkanapot.
Ezen kívül a mindennapi használat a legjobb teszt. Használjuk a gépet úgy, ahogy szoktuk. Játsszunk, szerkesszünk videót, böngésszünk. Ha két hétig semmilyen furcsa jelenséget (fagyás, újraindulás, furcsa hibaüzenetek) nem tapasztalunk, akkor kijelenthetjük, hogy a rendszerünk stabil. Érdemes figyelni a Windows Eseménynaplót (Event Viewer) is: a „WHEA-Logger” bejegyzések még az összeomlás előtt jelezhetik, hogy a processzor javított hibákat észlelt. Ha ilyet látunk, a rendszer még nem 100%-os, még ha nem is omlott össze.
A hosszú távú stabilitás része a degradáció figyelése is. Hónapok vagy évek alatt, magas feszültség mellett a processzor „elfáradhat”, és instabillá válhat azokon a beállításokon, amik korábban működtek. Ez természetes folyamat (elektromigráció), de lassítható ésszerű feszültséghatárok betartásával. Ha a rendszer fél év után instabillá válik, vissza kell venni az órajelből vagy kicsit emelni a feszültséget (ha még biztonságos).
Összegzés helyett: A türelem rózsát terem
Bár kérted, hogy ne legyen összefoglalás, engedd meg, hogy egy utolsó gondolattal zárjam ezt a technikai útmutatót. A túlhajtott CPU stabilitásának ellenőrzése nem egy délutáni program, hanem egy folyamatos tanulási görbe. Minden egyes kék halál, minden egyes fagyás közelebb visz a hardvered megértéséhez. Ne kudarcként éld meg a hibákat, hanem iránymutatásként.
A cél nem az, hogy a világ leggyorsabb processzora legyen a tied, hanem az, hogy a te processzorodból kihozd a maximumot úgy, hogy az ne menjen a megbízhatóság rovására. A fenti eszközök és módszerek birtokában most már képes vagy arra, hogy ne csak vaktában tekergesd a beállításokat, hanem tudatosan, mérnöki szemlélettel teszteld és validáld a rendszeredet. Jó kísérletezést, és alacsony hőmérsékleteket kívánok!
Gyakori Kérdések és Válaszok
Mennyi ideig kell futtatni a stressztesztet a biztos eredményhez?
A gyors ellenőrzéshez 15-30 perc elegendő lehet, de a teljes stabilitás igazolásához legalább 2-4 órás folyamatos tesztelés javasolt. Sokan a „24 órás szabályt” követik, de otthoni felhasználásra egy 4-8 órás, hiba nélküli futás (például éjszaka) már bőven elegendő biztonságot ad. Fontosabb a tesztek változatossága, mint az extrém hosszú futási idő egyetlen programmal.
Károsíthatja a processzort a stressztesztelés?
Ha ésszerű feszültséghatárokon belül maradsz és a hűtésed megfelelő, a stressztesztelés önmagában nem teszi tönkre a processzort. A modern CPU-k beépített védelmi mechanizmusokkal rendelkeznek, amelyek túlmelegedés esetén lekapcsolják a rendszert. A veszélyt inkább a tartósan túl magas feszültség (nem a hőmérséklet) jelenti hónapokon keresztül. A tesztelés alatti extrém hőmérséklet rövid távon nem okoz maradandó károsodást, de kerülendő.
Mi a különbség az AVX és a non-AVX tesztek között?
Az AVX (Advanced Vector Extensions) utasításkészlet sokkal intenzívebb számításokat tesz lehetővé, ami drasztikusan megnöveli a processzor áramfelvételét és hőtermelését. Egy AVX teszt (pl. Prime95 Small FFTs AVX-szel) 20-30 fokkal is melegebb lehet, mint egy AVX nélküli teszt. Mivel sok játék és hétköznapi program nem használja intenzíven az AVX-et, érdemes külön tesztelni a két állapotot, és szükség esetén AVX Offsetet használni a BIOS-ban.
Miért fagy le a gépem üresjáratban, ha terhelés alatt stabil?
Ez paradoxonnak tűnhet, de gyakori jelenség. Oka általában az, hogy az energiatakarékos funkciók (C-States) túl alacsonyra veszik a feszültséget üresjáratban, vagy az LLC (Load-Line Calibration) beállítása nem megfelelő, és a feszültségátmeneteknél (amikor a terhelés hirtelen megszűnik) a rendszer instabillá válik. A megoldás az „Offset” vagy „Adaptive” feszültségmód finomhangolása, vagy az energiagazdálkodási beállítások módosítása a Windowsban és a BIOS-ban.
Melyik a legjobb program a hőmérséklet figyelésére?
A HWiNFO64 jelenleg a legmegbízhatóbb és legrészletesebb monitorozó szoftver. Nemcsak a maghőmérsékleteket mutatja, hanem a VRM hőmérsékletet, a pontos feszültségeket (Vcore, VCCSA, stb.), az áramfelvételt és a rendszer esetleges throttling (lassítás) állapotát is. Ingyenes, és rendszeresen frissítik az új hardverek támogatásával. Az AIDA64 szintén kiváló alternatíva, de az fizetős szoftver.
Mit jelent a szilíciumlottó kifejezés?
A szilíciumlottó arra a tényre utal, hogy a gyártás során minden processzorchip mikroszkopikus szinten eltérő. Két, a boltban azonos dobozban vásárolt processzor közül az egyik lehet, hogy 5.0 GHz-en is stabilan fut alacsony feszültséggel, míg a másik 4.8 GHz-en is instabil, vagy sokkal több feszültséget (és hűtést) igényel. Ez szerencse kérdése; a tesztelés során a saját chipünk egyedi határait kell megtalálnunk, nem pedig mások eredményeit másolni.
Kell-e félnem a kék haláltól (BSOD) tesztelés közben?
Nem, a tesztelés közbeni kék halál teljesen normális része a folyamatnak. Ez jelzi, hogy elértük a hardver jelenlegi határait. A modern fájlrendszerek (pl. NTFS) elég ellenállóak, így az adatvesztés esélye csekély, de a biztonság kedvéért a tuningolás előtt mindig készíts biztonsági mentést a fontos adataidról. A BSOD hibakódja ráadásul segít a probléma diagnosztizálásában.
