cpuburn

FIGYELEM:
Ez a program célja, hogy erősen betölteni CPU chipeket. Undercooled, túlhajtott vagy más módon gyenge rendszerek nem okoz adatvesztést (fájlrendszer korrupció) és esetleg maradandó károsodást az elektronikus alkatrészek. Ugyanúgy nem lesz fogás minden hibát.
Csak saját KOCKÁZAT
CPU tesztelés közművek optimalizált szerelő maximális rakodási P6 (Intel Pentium Pro / II / III és Celeron TM), AMD K7 (Athlon / Duron / Thunderbird TM) AMD K6, és az Intel Pentium P5 chipek. Ez szabad szoftver, szerzői hanem szabadon a GNU Public Licence etalon.
Ezek a programok célja, hogy betöltéséhez x86 CPU-k erősen a lehető céljából rendszer tesztelése. Ők lettek optimalizálva különböző processzorok. FPU és ALU utasítások vannak kódolva összeállító végtelen ciklusba. Ők nem teszt minden utasítást. A cél az volt, hogy maximalizálja a hőtermelés a CPU-tól, nyomás alatt tartja a CPU is, hűtőrendszer, az alaplap (különösen a feszültség szabályozók) és tápellátás
(Valószínű oka burnBX / MMX hibák).
burnP5 optimalizált Intel Pentium w & w / o MMX processzorok
P6 az Intel PentiumPro, PentiumII & III és Celeron CPU-k
K6 az AMD K6 processzorok
K7 AMD Athlon / Duron processzorok
MMX, hogy tesztelje cache / memória interfész minden CPU MMX
BX egy alternatív cache / memória teszt az Intel CPU-k
HASZNÁLATA: root jogosultságod nem szükséges. Úgy lett tervezve ELF Linux, hanem kipróbált FreeBSD alatt. és a.out. Burn tesztelés legjobb módja egy ramdisk forgalmazás (tomsrtbt) vagy a fájlrendszerek esetén nem szerelt vagy írásvédett.
Bontsd ki a forrást egy kényelmes könyvtár:
`Tar zxf cpuburn`
összeállítása excutables
`Make`
futtatni kívánt program a háttérben [_repeat_ SMP]:
`BurnP6 || echo $? & `
Nyomon követését, cpuburn az `ps`. Ha kész, `kill` az égési * folyamat (ok). Ha a hőmérséklet szondák (ujj) vagy a lm-sensors csomag, akkor nézd meg a CPU hőmérséklet és / vagy a rendszer feszültség.
Ha hiba történik a számítás, akkor megmaradnak, és a program befejeződik, a hibakód 254 egész számára / memória hiba, és hibakódot 255 egy FP / MMX hiba. Hiba ellenőrzés történik minden 10-40 másodperc burnP6 / K6 / K7 és én még nem láttam olyan CPU hibák tesztelése [leállása történik először]. burnBX és burnMMX ellenőrizze hiba minden 512 MB (4-10 sec), és a hiba megszűnése gyakran előfordul, lefagyások ritkábbak.
burnBX és burnMMX alapvetően nagyon intenzív RAM tesztelők. Ők is egy opcionális paraméter alapján a RAM mérete a vizsgálandó:
  A = 2 kB E = 32 kB I = 512 kB M = 8 MB
  B = 4 F = 64, J = 1 MB N = 16
  C = 8 g = 128 K = 2 O = 32
  D = 16 H = 256 L = 4 P = 64
`BurnBX L` (4 MB) és` burnMMX F` (64 kB) az alapértelmezett méreteket. AE leginkább próbára L1 cache, FH teszt L2 cache, és a HP kényszeríteni az utat a RAM. De még AE lesz néhány cacheline writeouts a RAM.
Annak ellenére, hogy nevét, burnBX lehet futtatni bármely chipset [RAM vezérlő] és vizsgálatok sokkal több, mint a RAM vezérlő. Sajnos, burnBX nem optimális az AMD processzorok. burnMMX előnyösebb bármely CPU, hogy van egy MMX egységet.
burnBX / MMX igények mintegy 72 MB a teljes RAM + swap kezdeni (nem feltétlenül ingyenes), de nem használja ezt a sok, ha nem kérik. Ők fog dobni egy `Sig 11` ha nincs elég csere.
Ha nem szeretné, hogy adjunk több, akkor állítsuk be a .bss részén csökkenő amint az a forrás hozzá. Ők is vizsgálatot csere, és legalább az én-rendszer, tudok futni 2 * `burnBX 8` 128 MB SDRAM néhány A swap, de nem túlzott verte [törekszik]. YMMV.
Ha al-spec, a rendszer lefagy, miután 2-10 perc. Nem kellett volna. éget * csak egy unpriviliged felhasználói folyamatok. De ez valószínűleg azt jelenti, a CPU undercooled, valószínűleg nem hővezető pasztát vagy más felületen anyag közötti CPU és a hűtőborda. Vagy valami más hiányosság. A hatalom ciklus újra kell indítani a rendszert. De meg kell javítani.