Newsgroup: it.comp.hardware.cpu
Titolo: Protezione termica 3

Nonostante i fischi e gli insulti :-)), eccomi a riproporvi i miei ultimi
test sul mio famigerato PIV 2.53Ghz su P4PE.
L'altra notte quando conducevo i test con CPUBurn usavo (per indipedenza dal
sistema, P6, P5, K6, K7) il test MMX.
Oggi ho provato ad usare il test P6 e ho fatto delle interessanti scoperte.
Lanciato il test con la C...@3.001Ghz (fsb = 158Mhz), dopo pochi secondi
(40-50 circa) il test si sganciava (CPU load a zero).
Il bello è che lo faceva a temperature relativamente basse, una volta anche
a 47°C.
Allora ho provato ad overvoltare fino a 1.7V sulla CPU ed il test non si è
sganciato per un bel pezzo (almeno 5 minuti) e la temperatura è arrivata
fino a 64°C. Lanciando il solito Sandra anche a 64°C, nessun problema sempre
i soliti 5850/5900 punti.
Poi ho provato ad abbassare la freq. a 155Mhz, cioè CPU @ 2950 Mhz, overvolt
a 1.55V (quindi minimo): rilancio CPUBurn, nessun problema, temperatura
stabile a 57°C, il test non si sgancia mai (ho aspettato una bella ventina
di minuti, la situazione era rock-solid).
Poi ho provato ad abbassare la freq. a 150Mhz, CPU@2850, overvolt a 1.55V,
sempre nessun problema, temperatura sui 56°C.
Come sopra a 2.53 e 1.5V: nessun problema, temperatura a 54°/55°C, mostruosa
perchè a 2.53Mhz MadOnion stava sui 50.
In tutti i casi, ho sempre ripetuto Sandra al culmine della temperatura ed i
risultati sono sempre stati proporzionali alla freq.
Cosa deduco? Che secondo me si confermano le mie teorie dell'altro giorno.
1. La protezione termica non entra mai in azione, nemmeno a 64°C, non è
quello il problema, la CPU fa sempre il massimo, al massimo non ce la fa.
2. CPUBurn test P6 è un programma "bestiale" che stressa la CPU come nessun
applicativo può fare, ed anche molto di più del test MMX (che mi faceva
arrivare a 57°C nella peggiore delle ipotesi, ma senza alcun problema di
"sgancio"), e che mette in evidenza i limiti di stabilità della CPU anche
non legati alla temperatura. Infatti overvoltando il test funziona molto più
a lungo e si raggiungono temperature notevolmente superiori. Se avessi il
coraggio, potrei provare un 1.75V, ma aspetto consigli da chi ha molta più
esperienza in oc su PIV.
3. Che la mia CPU è in realtà (effettivamente, non nominalmente) un 2.8Ghz,
che si overclocca senza problemi a 2.95Ghz in modo rock-solid assoluto (come
succede con un 2200+ tra i 1800 ed i 1900) e che tra 2.95 e 3.001 si trova
già in quel range di frequenze in cui soffre (in cui, per dirla con parole
mie, la pendenza della retta temp. vs. freq. è molto più ripida), ed ecco
che si riscontrano le crescite di temperature classiche dell'overclock
all'AMD (tipo tra 1950 e 2000 per un 2200+), bastano pochi Mhz per avere
bloccaggi (sia pure, in questo caso, solo con un torturatore come CPUBurn
perchè nell'uso comune, inclusi giochi, MadOnion e altro non ho alcun
bloccaggio) e per raggiungere temperature molto più elevate.
Aspetto le vostre considerazioni
Massimo

 Aspetto le vostre considerazioni
Sintetico: bravo :-).
Usa un dissy migliore e una ram di qualità top e vedrai che
potrai fare di più. Ma non superare i 1.75V, paiono critici
per i P4.
Ciao.
Alberto.

 per i P4.
Sono arrivato "solo" a 1.7V e già avevo gli occhi fuori delle orbite e il
naso pronto a cogliere il minimo "profumo" di cottura!!!
Massimo

 naso pronto a cogliere il minimo "profumo" di cottura!!!
Non cuoce, semplicemente defunge di botto, senza incendi
o odori strani.
Ciao.
Alberto.

3. Che la mia CPU è in realtà (effettivamente, non nominalmente) un 2.8Ghz,
Questo è quasi certo. Il bello che lo sono anche i P4 2.26Ghz. Ma
parecchi 1.8A fanno i 166 di bus.
E' solo il marketing a stabilire ciò che diventa P4 2.8Ghz e ciò che
diventa 2.0 Ghz.
Ciao Mariop

 diventa 2.0 Ghz.
Questo è esattamente ciò che io ho sostenuto fin dall'inizio dei miei
commenti: la sensazione chiara che in questo momento Intel stia vendendo CPU
undercloccate per questioni di marketing e che per questa ragione questo è
il momento giusto per comprare Intel. Al contrario AMD, in questo momento,
si trova nella fase opposta, è costretta a vendere CPU che sono già
overcloccate dalla casa, per reggere il confronto in qualche modo.
Ciao
Massimo

 lo trovi su 
www.mersenne.org
.
Ho scaricato e ho fatto le prove: nessun problema, a differenza del CPU_Burn
(che risulta ancora più bestiale, dopo questa prova) il Torture Test sia a
2950 che a 3001MHz non crasha, va avanti liscio come l'olio, con tensione a
1.575V (ma credo che andrebbe anche a 1.55V) e temperatura costante sui
55-56°C, con brevissimi e rarissimi picchi a 57°C e a 54°C. Ha girato per
un'ora, ma sinceramente, già dopo 15 minuti si era capito che non sarebbe
più cambiato nulla.
Da come sono andate le cose, credo che funzionerebbe anche con FSB a 162Mhz,
magari farò una prova uno di questi giorni.
In CPU_Burn deve proprio esserci qualcosa di "cattivo", ma credo che sia più
un problema di CPU-to-RAM (e io finora ho sempre provato con tutti i timing
al massimo dei massimi) che di operatività CPU.
Ciao
Massimo

overcloccate dalla casa, per reggere il confronto in qualche modo.
I P4 sono molto overcloccabili, quasi a livelli assoluti (erano anni
che non si vedevano cpu come il P4 1.6A capaci anche di 70-80% di
overclock). Ma gli Amd non sono poi così male.
E dopo aver visto oggi l'OC di Fluctus (Thoro 2400+ @ a 2400 Mhz ad
aria con 1.95V) direi che ci sono margini di divertimento anche con
gli Amd.
Ciao Mariop

 gli Amd.
Resta il fatto che Fluctus è un overclocker "assatanato" (mi sembra di
capire), io non ho fatto proprio nulla di speciale per raggiungere i 3.001 e
DEVO per forza avere il massimo della stabilità su tutto e sempre, visto che
il PC lo uso per lavoro. Se non fosse così, sicuramente qualche numerino in
più si potrebbe ancora ottenere, sicuramente i 162Mhz di fsb che ho già
impostato e che "sostanzialmente" reggono senza problemi, ma forse anche
ancora qualcosina (tipo i 165Mhz a 3138Mhz).
Inoltre, tieni presente, che io ho la RAM settata a 421Mhz, a 2, 2, 2, 5 con
tutti i settaggi turbo, se "scalassi" un po' anche qui ci sarebbe da
ridiscutere il tutto e non tanto perchè sia la RAM il collo di bottiglia, ma
credo il chipset e la sua gestione della connessione con la RAM a quelle
frequenze e con quelle tempistiche.
Ciao
Massimo

 causa del pazzesco assorbimento in atto.
Quindi la tua scheda madre (quale?) non e` adatta all'overclock?
-- 
http://fantoibed.da.ru
    |   linux   |  
http://www.spippolatori.com
 UIN:62959208             | addicted  |  email:  
fant...@libero.it


In che senso?
CPU_Burn è evidentemente un programma di tortura che fa cose insensate, se
con tutti gli altri programmi e applicativi compreso Prime95, MadOnion,
ViruScan di McAfee (provate ad usarlo con tutto abilitato ed in particolare
la scansione euristica di macro e file di programma e vedrete che è un
ottimo torture test per la CPU) questi problemi non ci sono (o sono del
tutto nella norma, una differenza di 0.03V tra pieno carico e idle è del
tutto normale) io darei la colpa a quell'unico programma probabilmente non
ottimizzato per il PIV, non a motherboard e PIV.....
Io continuo a lavorare tranquillo a 3.001Mhz, con RAM a 421Mhz, CAS2 (con
timing 2, 2, 2, 5 e turbo), cosa ci vuole per dire che tutto l'insieme è
fanatsticamente overcloccabile????
By the way, P4 2....@3.001 su Asus P4PE con DDR Corsair XMS3500.
Massimo

 By the way, P4 2....@3.001 su Asus P4PE con DDR Corsair XMS3500.
                               ^^^^
L'Asus, infatti,  che una volta era  il non plus ultra  tra le mobo,
ora e`  caldamente sconsigliata  dagli overclockers.  La tua  cpu e`
chiaramente molto overclockabile e, se abbinata ad una mobo in grado
di mantenere  un overvolt  *effettivo* quando realmente  serve, IMHO
potrebbe spingersi ancora oltre... :-))


 ottimizzato per il PIV, non a motherboard e PIV.....
Secondo te un programma chiamato Cpu_Burn che dovrebbe fare ?
E' *ovvio* che deve stressare *pesantemente* il sistema.
In base a quel che dici CPU_Burn sta facendo esattamente il suo lavoro.
Programmi come Viruscan o Prime95 che io sappia non stressano
pesantemente le unita floating point (FPU x86 o SSE/SSE2 che siano)
probabilmente Cpu_Burn usa sequenze (ottimizzate per i vari tipi
di cpu x86) che stressano il piu possibile tutte le varie
unita funzionali (ALU,FPU,unita di load/store, ecc. ecc), tutto li.
L. Micheletto

 unita funzionali (ALU,FPU,unita di load/store, ecc. ecc), tutto li.
Prime95 esegue una sequenza di calcoli matematici quindi credo proprio che
usi tutte le ottimizzazioni SSE2, considerato che nella sua pagina di
risultati i PIV (ottimizzati per SSE2) ci mettono meno della metà degli AMD
a passare gli stessi test.
ViruScan, come ho detto, con la scansione euristica di macro e file di
programma è costretto ad eseguire una mole enorme di calcoli (io ho circa
170.000 file scansionabili sul sistema) e la temperatura sale a 55°-56°C
durante la scansione di certi gruppi di file.
Quindi cosa posso dire? Io uso il sistema a 3.001 @ 1.55V e tutto mi
funziona, compreso il Prime95, non ci sono bloccaggi, non ci sono cadute di
tensione anomale, la temperatura è nella norma anche sotto carico.
La mia conclusione, nonostante tutto, rimane quella di prima, CPU_Burn è
l'anomalia, non la motherboard e/o la CPU.
Massimo

 potrebbe spingersi ancora oltre... :-))
Sul fatto che con un'altra mobo potrei ottenere di più posso anche essere
d'accordo, anche se secondo me l'Asus non è mai stata poi così famosa per
l'overclock, ci sono sempre state altre case ben più piazzate in quel senso.
E' chiaro che potrei spingermi oltre curando meglio la dissipazione del
calore sia di CPU che di chipset (che ha solo un dissy passivo, senza
ventola). Poi, come ho già detto, se lo scopo è solo la frequenza massima
raggiungibile, mi basterebbe abbassare i timing della RAM per dare un po' di
respiro al chipset (la RAM non ha probabilmente problemi, anche se con
2,2,2,5 è fuori dalle sue specifiche che sono 2,3,3,7), ma queste sono tutte
cose che interessano gli overclocker "assatanati", a me basta avere una CPU
a 3Ghz che funzioni perfettamente senza problemi e che ho pagato per una
2.53Ghz :-))) e con la RAM al massimo, lascio a chi di dovere di indagare
sui limiti massimi della CPU in oggetto.
Massimo

 cose assurde che i programmi che effettivamente si usano non fanno mai.
Attenzione: se CPU_Burn fosse "ottimizzato per i PIII" come
dici tu dovrebbe scaldare come gli altri programmi *o anche meno*.
Il motivo e' che codice ottimizzato per PIII produce piu stalli
nelle pipeline del P4 (e quindi la cpu non viene stressata
al limite).
CPU_Burn *non puo* "fare qualcosa di sporco" per il semplice
motivo che e' un programma come gli altri, mica ti riscrive
il microcodice.
Se una cpu va in crisi eseguendo codice perfettamente legale
per essa non e' colpa del programma, il problema e' della cpu.
Tu hai una cpu overclockata che regge tranquillamente
l'esecuzione di codice "normale" (pesante ma pur sempre
normale), ma che evidentemente quando fa girare un programma
che strizza per bene tutte le risorse disponibili viene
messa in crisi, tutto qui.
Ci sono buone probabilita che questo sia dovuto a non sufficiente
amperaggio erogato dall'alimentatore oppure a problemi
dei regolatori di tensione sulla scheda madre (in fin dei conti
la tua cpu opera con un overclock del 20% a frequenze operative
non ancora ufficialmente supportate dalla scheda madre che hai).
L. Micheletto


Possiamo continuare a discutere all'infinito :-)): se tu fossi il
programmatore che ha scritto il programma potrei anche crederti, ma allo
stato delle cose noi non sappiamo assolutamente cosa abbia fatto il tipo pr
creare il massimo del disturbo. Tengo a precisare che già da almeno un
decennio non è assolutamente possibile nè per Intel nè per AMD verificare il
100% delle sequenze di istruzioni che una CPU può potenzialmente trovarsi a
dover affrontare, ma viene coperto "solo" l'enorme insieme delle sequenze
più probabili. Se si tentasse la copertura assoluta, una CPU ci metterebbe
probabilmente una decina d'anni a passare questo test......
Ti correggo solo un paio di cose:
1) L'alimentatore non può essere, dato che è un EnerMax da 431W che spara
qualcosa come 44A sul +5V, 38A sul +3.3V e 20A sul +12V,
2) la motherboard è nata per supportare le CPU da 3.06GHz e oltre e quindi
suppongo che la sua sezione di alimentazione sia adeguatamente "dotata".
Comunque grazie per le idee ed obiezioni.
Massimo

 creare il massimo del disturbo.
Perchè? CpuBurn è free source!
-- 
cat ragazze | grep lapiugnocca | mount

 Perchè? CpuBurn è free source!
Guarda che a me non interessa la diatriba Intel/AMD e non sto dicendo che
qualche cattivaccio dell'AMD ha scritto questo programma per danneggiare
Intel, sto solo dicendo che chiunque abbia scritto quel codice può aver
usato qualunque mezzo pur di fondere la CPU il più in fretta possibile e può
darsi, per quello che ho potuto osservare io, che qualcuno di quei mezzi
impiegati sia (per puro caso) troppo violento o usi sequenze di istruzioni
che il PIV non sopporta o sopporta infinitamente peggio di quanto non
facciano altri tipi di CPU per i quali il sw è stato appositamente scritto.
Quindi non c'era nulla di polemico o "politico" nella mia osservazione...
Tanto per chiarire meglio quanto dicevo sopra e per contestare anche alcune
osservazioni, Prime95 esegue serie mostruose di calcoli molto pesanti e
confronta i risultati ottenuti con un suo database, e quindi mi sembra
chiaro che fa cose lecite, normali e dichiarate, anche se pesanti.
Cosa fa CPU_Burn?????
Ecco tutto quello che si dice sul sito:
CPU testing utilities in optimized assembler for maximum loading P6 (Intel
Pentium Pro/II/III and Celeron TM), AMD K7 (Athlon/Duron/Thunderbird TM) AMD
K6, and Intel P5 Pentium chips.
Come si può ben notare dice che lavora in assembler, parla solo di
istruzioni assembler e già questo è molto poco rassicurante, perchè essendo
linguaggio macchina può usare qualunque sequenza di istruzioni senza alcun
"limite", poi non parla assolutamente di PIV (al contrario di quello che
sosteneva Lorenzo Micheletto non si parla assolutamente di nulla di
matematico e tanto meno di FPU/SSE/SSE2).
Conclusione: a me puzza e sconsiglierei di usare quel test su CPU recenti
(Intel o AMD).
Massimo

 (Intel o AMD).
E' una serie legale di istruzioni macchina, nessuna c
correttamente implementata dovrebbe avere problemi ad eseguirla.
Per la cronaca il test andrebbe fatto a priorità alta, nel caso di
windows esite un programmino "runprio" che permette di lanciare un
qualsiasi eseguibile alla priorità desiderata.
Su Windows in priorità normale il processo riceve solo il 75% del
tempo di cpu, contro il 96% dell'esecuzione a priorità alta.
L'esecuzione in real-time rende impossibile l'interazione
uomo-macchina... (a parte il tasto di reset)...


 probabilmente una decina d'anni a passare questo test......
Tutte le sequenze no, ma tutti gli "schemi" si
(es: non serve testare tutte le istruzioni ADD basta testare
      quelle a cui corrisponde il maggior consumo di potenza nelle
      unita funzionali o quelle in cui e' piu probabile
      che vi siano problemi dovuti a ritardi di propagazione).
Se si passano i test delle combinazioni piu gravose le altre
sono valide di conseguenza.
L. Micheletto

 (Intel o AMD).
e invece dovresti solo ringraziarlo, perche' ti ha (di)mostrato che il 
tuo overclock non era per niente stabile, mentre non penso tu possa dimostrare 
che quelle particolari sequenze di istruzioni non saranno mai indispensabili 
per nessun programma "utile" ...

 dover affrontare
test esaustivo ? altro che "almeno un decennio": non penso sia MAI stato 
fatto un lavoro del genere, nemmeno per il 4004.
questo perche' e' vero che (ad esempio) il 4004 e' molto semplice, ma e' 
altrettanto vero che erano molto semplici anche gli strumenti disponibili 
all'epoca.
soprattutto, se verifichi un componente reale, ti ci devi adeguare. 
un 286 a 10MHz mi sembra che nel migliore dei casi possibili piu' di 2-3 
milioni di somme al secondo non potesse fare (immediato con AX), 
senza contare quindi le istruzioni necessarie per verificare il test, che 
riducono di un fattore 10 almeno (se non si hanno testpoint per macchinari 
esterni). beh, le possibili coppie di operandi a 16 bit sono piu' di 
4 miliardi, il che vuol dire che servono tempi dell'ordine delle migliaia di 
secondi (20 minuti) solo per provare UNA istruzione. figurati le sequenze... 
rischi che il tuo processore muoia per anzianita' prima della fine dei 
test :)

 test :)
Indubbiamente intendevo testare sequenze di istruzioni diverse, non provare
tutte le possibili somme di due operandi, tutte le possibili
moltiplicazioni, etc. etc. Comunque sono d'accordo anch'io che 10 anni sono
pochi, ma è dal 386 che il problema che ho posto io (nei termini che lo
intendevo :-) ) si è fatto rilevante.
Massimo

 [....snip....]
Qui, in pratica, lavora solo la FPU!!! ;-)


 matematico e tanto meno di FPU/SSE/SSE2).
Un momento, io ho scritto:
"
  Attenzione: se CPU_Burn fosse "ottimizzato per i PIII" come
  dici tu dovrebbe scaldare come gli altri programmi *o anche meno*.
"
Guardando poi il codice postato da gigi e' evidente
per chiunque conosca un minimo di codice assembly x86
che il codice stressa "solo" le unita di load/store, le
unita intere e la FPU, ma usa istruzioni FPU "normali".
Non vengono usate ne le SSE e neppure le SSE2 (che in teoria
usandole si dovrebbero "caricare" le unita floating point
MOLTO DI PIU di quanto avvenga con le "vecchie" istruzioni FPU x86).
In altre parole e' codice normalissimo che per quanto pesante
e non e' cosi "aggressivo" come tu pensi.
Da quel che ho visto nel loop "piu caldo" stressa simultaneamente
le ALU (interi ed FPU visto che su P.Pro,PII,PIII il moltiplicatore
e' condiviso tra interi e FPU), le AGU, le unita di load/store
e la BPU (visto che dentro il loop c'e' un branch condizionale
con circa il 50% di salto).
Se il tuo P4 va in crisi per roba simile e' solo perche
lo hai overclockato al limite di quanto permesso
dalla combinazione cpu+scheda_madre+alimentatore
in tuo possesso.
Infine non riesco a capire le tue paranoie riguardo
il codice macchina. Se venissero usate "sequenze proibite"
l'unico risultato sarebbe la generazione di un interrupt
software con il conseguente arresto del programma
o al massimo degli errori di calcolo (se si usassero
delle istruzioni bugate come il FDIV bug che piagava
i primi Pentium).
L. Micheletto

 i primi Pentium).
Bravo, finalmente ci sei arrivato: è quanto ho descritto fin dall'inizio, il
programma crasha, anche a bassa temperatura, dopo un po' (a bassa tensione
un po' molto corto, meno di un minuto) il programma crasha. Alzando la
tensione a 1.7V la temperatura cresce in modo notevole (fino a 64°C) ed il
programma ci mette molto di più a crashare, ma poi crasha.
Le mie obiezioni non erano paranoiche, non ho mai parlato di sequenze
proibite, rilevavo solo il fatto che il programma era evidentemente "troppo
delicato" per servire a qualcosa su un PIV, perchè era troppo facile che
crashasse, considerato che tutti gli altri programmi usati allo stesso scopo
e nati per lo stesso scopo, ma RECENTI, non lo facevano, non solo alle
medesime condizioni ma a condizioni peggiori (overvolt decisamente inferiore
e overclock superiore). E che per utilizzarlo in overclock era necessario
fare cose assurde, che comunque non servivano.
Comunque, se avessi avuto il codice riportato da Gigi me lo sarei letto da
solo, sul sito ho solo visto la frase che ho riportato e che mi lasciava
perplesso perchè non diceva nulla.
L'unica cosa che, per correttezza, devo dire è che a freq. nominale non
crasha e non scalda nemmeno tanto, sui 52°C. Quindi, OK, è un ottimo
programma di test di oc, direi troppo ottimo, perchè praticamente non appena
ti muovi ti fulmina!!!!!
Un giorno se avrò voglia proverò a salire di freq. e vedere a che punto
salta.
Massimo

 l'ali EnerMax da 431W.
Ed io ripeto ancora, cpuburn non tira veramente al limite il P4
(bisognerebbe ricavarne una versione che usa SSE2 invece
  delle istruzioni FPU per avere un "cpuburnP4" capace spremere
  fino in fondo tale cpu).
Il giorno in cui ti ritroverai ad eseguire codice
"ottimizzato al massimo" per P4 scoprirai che cpuburn non e'
il peggio che puo capitare alla tua cpu.
Se ti va di correre il rischio fai pure.
Ma se prima o poi comincera' ad uscire codice *veramente*
ultra-ottimizzato per SSE2 rischi di avere brutte sorprese
[ anche se lo ritengo improbabile considerando come i programmi
   nuovi *non* vengono ottimizzati].
Se vuoi fare un test di stabilita devi concentrarti sul caso
peggiore, perche e' quello che ti puo fottere la cpu, il caso
medio non dice niente.
Non puoi dire "tanto e' improbabile che mi capiti
del codice *vecchio* scritto come cpuburn", quello di cui invece
dovresti preoccuparti e' quello *nuovo* che prima o poi
potrebbe arrivare e fottere tutto.
L. Micheletto