[Thread Ufficiale] CPU serie FX: AMD Bulldozer/Piledriver - Aspettando Steamroller

[R.O.N.I]

Non vi seguo, quindi alla fin fine dicono tutti la stessa cosa in modi diversi? Vedendo aod mi sembra di avere più margine di temp però, solo una impressione?

[maexss]

Originariamente inviato da isomen

Veramente a parte il primo che é a 2,8 gli altri sono tutti a 4,4 anche se con un uso del 2/3% ma se hai disattivato il C&Q e nn hai opzioni risparmio energia su bilanciato o risparmio energia é normale... anzi dovrebbe essere a 4,4 anche il primo.

ciauz

Avevi perfettamente ragione. Avevo il profilo creato da samsung magician, ma quando usavo k10stat era lui che mi gestiva i pstate....

[plainsong]

In effetti cercando sul web risulta che in alcuni casi core temp indica come tj max per gli fx8350 90° e in altri 70°. Non sono in grado di stabilire se questo è da imputare a diverse versioni del programma, della cpu o altro. Quello che tuttavia sembra assodato è che programmi come core temp e hwinfo riportano come temperature dei cores un valore che è direttamente confrontabile con la soglia dei 70° di margine termico utilizzata da aod. Come nel caso postato da isomen, ad una lettura di 47° sui cores di hwinfo, ne corrisponde una di 23° di margine su aod (70-47= 23).

[isomen]

Originariamente inviato da maexss

Avevi perfettamente ragione. Avevo il profilo creato da samsung magician, ma quando usavo k10stat era lui che mi gestiva i pstate....

Anche a me piaceva k10stat... ma con gli FX nn funziona

ciauz

[isomen]

Originariamente inviato da plainsong

In effetti cercando sul web risulta che in alcuni casi core temp indica come tj max per gli fx8350 90° e in altri 70°. Non sono in grado di stabilire se questo è da imputare a diverse versioni del programma, della cpu o altro. Quello che tuttavia sembra assodato è che programmi come core temp e hwinfo riportano come temperature dei cores un valore che è direttamente confrontabile con la soglia dei 70° di margine termico utilizzata da aod. Come nel caso postato da isomen, ad una lettura di 47° sui cores di hwinfo, ne corrisponde una di 23° di margine su aod (70-47= 23).

Si, come ho detto anch'io, corrisponde... ma se metti insieme quanto dichiarato da amd, che 70° come temp massima supportata da una cpu é bassa e che la temp esterna nn puè essere superiore a quella interna... qualcosa nn quadra

anche se nella realtà dei fatti a noi poco importa se la temp reale dei core é 65° o 85° quando sappiamo che finchè quel valore nn supera una certa soglia é tutto ok.

ciauz

[fracama87]

Originariamente inviato da isomen

Si, come ho detto anch'io, corrisponde... ma se metti insieme quanto dichiarato da amd, che 70° come temp massima supportata da una cpu é bassa e che la temp esterna nn puè essere superiore a quella interna... qualcosa nn quadra

anche se nella realtà dei fatti a noi poco importa se la temp reale dei core é 65° o 85° quando sappiamo che finchè quel valore nn supera una certa soglia é tutto ok.

ciauz

Sto provando occtpt invece di ibt (di cui usavo la versione avx)... Quali sono le impostazioni consigliate? Ho visto che tu nel test con occtpt non avevi selezionato avx...

Voglio vedere se almeno in inverno riesco a salire almeno a 4,4...

[isomen]

Originariamente inviato da fracama87

Sto provando occtpt invece di ibt (di cui usavo la versione avx)... Quali sono le impostazioni consigliate? Ho visto che tu nel test con occtpt non avevi selezionato avx...

Voglio vedere se almeno in inverno riesco a salire almeno a 4,4...

Io seleziono cpu linpack e automatic, anche per un uso intensivo é più che sufficente per la stabilità... selezionando AVX capable linpack é anche più tosto come test e scalda un po' di più, secondo alcuni sono test anche troppo pesanti, secondo altri va fatto almeno per 24h... a me dopo aver superato un'ora senza avx nn ha mai dato problemi, quindi mi basta così.

ciauz

[dav1deser]

Originariamente inviato da isomen

Io seleziono cpu linpack e automatic, anche per un uso intensivo é più che sufficente per la stabilità... selezionando AVX capable linpack é anche più tosto come test e scalda un po' di più, secondo alcuni sono test anche troppo pesanti, secondo altri va fatto almeno per 24h... a me dopo aver superato un'ora senza avx nn ha mai dato problemi, quindi mi basta così.

ciauz

Secondo me è tutta questione di LLC, quanto più è spinto l'LLC tanto più lungo dev'essere il test. Mi spiego:

Se hai LLC attivo in maniera tale da avere la tensione effettiva alla CPU praticamente identica a quella impostata da BIOS, devi fare un test lungo per trovare l'effettiva stabilità, perchè durante l'utilizzo normale del PC potrai fare operazioni lunghe, la CPU avrà la stessa tensione di quando hai fatto lo stress test, e devi essere al sicuro anche da microcali di tensione che potrebbero avvenire in qualunque momento.
Se non hai LLC durante lo stress tes avrai tensione effettiva inferiore a quella impostata da BIOS, e quanto più lo stress test è pesante tanto più bassa sarà la tensione, durante normale utilizzo quindi avrai una tensione effettiva più alta di quella dello stress test e questo aumenta di molto il margine di sicurezza che hai, quindi anche in caso di microcali, fintanto che stai ad una tensione maggiore di quella dello stress test sei al sicuro da instabilità, perciò lo stress test stesso non ha bisogno di essere troppo lungo.

Io inoltre una volta trovata la stabilità con lo stress test, per l'utilizzo di tutti i giorni do almeno un step in più di tensione, quindi spesso mi accontento di test da mezz'ora. E questo metodo non mi ha mai dato problemi.

[fracama87]

Originariamente inviato da dav1deser

Secondo me è tutta questione di LLC, quanto più è spinto l'LLC tanto più lungo dev'essere il test. Mi spiego:

Se hai LLC attivo in maniera tale da avere la tensione effettiva alla CPU praticamente identica a quella impostata da BIOS, devi fare un test lungo per trovare l'effettiva stabilità, perchè durante l'utilizzo normale del PC potrai fare operazioni lunghe, la CPU avrà la stessa tensione di quando hai fatto lo stress test, e devi essere al sicuro anche da microcali di tensione che potrebbero avvenire in qualunque momento.
Se non hai LLC durante lo stress tes avrai tensione effettiva inferiore a quella impostata da BIOS, e quanto più lo stress test è pesante tanto più bassa sarà la tensione, durante normale utilizzo quindi avrai una tensione effettiva più alta di quella dello stress test e questo aumenta di molto il margine di sicurezza che hai, quindi anche in caso di microcali, fintanto che stai ad una tensione maggiore di quella dello stress test sei al sicuro da instabilità, perciò lo stress test stesso non ha bisogno di essere troppo lungo.

Io inoltre una volta trovata la stabilità con lo stress test, per l'utilizzo di tutti i giorni do almeno un step in più di tensione, quindi spesso mi accontento di test da mezz'ora. E questo metodo non mi ha mai dato problemi.

La cosa strana e che con ibt-avx con ram all'80% mi ha fallito il test, valori tutti perfetti: temp basse, voltaggi stabili e immobili (avevo hwinfo, hwmonitor e aod aperti). I core erano sotto i 50° il socket 69°.
Ma guardando sia aod sia hwinfo in tempo reale c'è stato per una frazione di secondo un brusco calo dell'utilizzo della cpu a 0% (su tutti i core in contemporanea, sul grafico c'era una v acutissima per intenderci). L'ha fatto sue volte nei primi due cicli. E ovviamente è fallito il test

Con occptp in automatic (imposta la RAM a 4gb ovvero il 25%) invece ha fatto 50 minuti senza problemi ( mi sono dovuto fermare per cercare una cosa urgente al PC ora ripeto per un'ora intera...).

Quando finisco il test posto anche i dati di test... Tutti i risparmi sono disabilitati e c'ero già impazzito in autunno (isomen se ricordi dai dati mi avevi suggerito fossero le temperature del vrm, allora però usavo solo ibt).

A 4,2ghz il problema non si presenta mai!

Di chi mi dovrei fidare secondo te Occt o ibt? Alla fine ibt stessa la cpu a un livello tale che dubito si verifica mai nell'utilizzo reale....

[isomen]

Originariamente inviato da dav1deser

Secondo me è tutta questione di LLC, quanto più è spinto l'LLC tanto più lungo dev'essere il test. Mi spiego:

Se hai LLC attivo in maniera tale da avere la tensione effettiva alla CPU praticamente identica a quella impostata da BIOS, devi fare un test lungo per trovare l'effettiva stabilità, perchè durante l'utilizzo normale del PC potrai fare operazioni lunghe, la CPU avrà la stessa tensione di quando hai fatto lo stress test, e devi essere al sicuro anche da microcali di tensione che potrebbero avvenire in qualunque momento.
Se non hai LLC durante lo stress tes avrai tensione effettiva inferiore a quella impostata da BIOS, e quanto più lo stress test è pesante tanto più bassa sarà la tensione, durante normale utilizzo quindi avrai una tensione effettiva più alta di quella dello stress test e questo aumenta di molto il margine di sicurezza che hai, quindi anche in caso di microcali, fintanto che stai ad una tensione maggiore di quella dello stress test sei al sicuro da instabilità, perciò lo stress test stesso non ha bisogno di essere troppo lungo.

Io inoltre una volta trovata la stabilità con lo stress test, per l'utilizzo di tutti i giorni do almeno un step in più di tensione, quindi spesso mi accontento di test da mezz'ora. E questo metodo non mi ha mai dato problemi.

L'impostazioni LLC dipendono molto dal reparto d'alimentazione, questa cpu sulla sabertooth (LLC high/medium e oscillazione in full di 0,02) benchava anche a 5ghz, sulla M5A97 (LLC ultra high/high e vcore che in full si mantiene fra 1,428 e 1,44 quindi oscillazione di 0,012) sono stabilissimo a 4,6 ma già a 4,7 nn riesco a fare il boot, mentre sulla 990 UD3 (LLC extreme e oscillazione di 0,04) con molta fatica éro riuscito a passare occt a 4,5.

ciauz

[fracama87]

un'ora di occt a 4,4ghz passata agevolmente, magari posso alzare di uno step i voltaggi come margine di sicurezza di cui si parlava... poi già che ci siamo visti temp e voltaggi estremamente bassi voglio provare almeno i 4,6ghz
Non credo che userò i 4,6ghz forse neanche i 4,4ghz ma vorrei vedere i limiti a cui posso arrivare con questa configurazione...

[maexss]

Originariamente inviato da fracama87

La cosa strana e che con ibt-avx con ram all'80% mi ha fallito il test, valori tutti perfetti: temp basse, voltaggi stabili e immobili (avevo hwinfo, hwmonitor e aod aperti). I core erano sotto i 50° il socket 69°.
Ma guardando sia aod sia hwinfo in tempo reale c'è stato per una frazione di secondo un brusco calo dell'utilizzo della cpu a 0% (su tutti i core in contemporanea, sul grafico c'era una v acutissima per intenderci). L'ha fatto sue volte nei primi due cicli. E ovviamente è fallito il test

Con occptp in automatic (imposta la RAM a 4gb ovvero il 25%) invece ha fatto 50 minuti senza problemi ( mi sono dovuto fermare per cercare una cosa urgente al PC ora ripeto per un'ora intera...).

Quando finisco il test posto anche i dati di test... Tutti i risparmi sono disabilitati e c'ero già impazzito in autunno (isomen se ricordi dai dati mi avevi suggerito fossero le temperature del vrm, allora però usavo solo ibt).

A 4,2ghz il problema non si presenta mai!

Di chi mi dovrei fidare secondo te Occt o ibt? Alla fine ibt stessa la cpu a un livello tale che dubito si verifica mai nell'utilizzo reale....

Per esperienza personale su phenom però, dato che su fx sto testando ancora, ibt stressa maggiormente la cpu. A parità di condizioni ibt mi faceva scaldare di più la cpu e dovevo dare un pò di tetnsione in più per passare il test.
Con fx la temp max per ora sembra essere più o meno la stessa, ma devi dare più prove per esserne sicuro; però ho notato che con un certo voltaggio ibt mi rileva prima se la cpu è instabile.
Comunque sono situazioni limite che in uso normale non vengono mai raggiunte, secondo me. Per quanto mi riguarda le situazioni di maggior carico che ho, sono con any video converter, conversione video con opencl attivo, quindi sfruttando anche la gpu; la max temp sono 55-56 contro 64 raggiunte con ibt

[paolo.oliva2]

Originariamente inviato da capitan_crasy

Ancora rumors provenienti dal sito sweclockers.com stavolta riguardano il futuro dell'infrastruttura AMD per il mercato desktop.
Con il passaggio alle DDR4 è imminente l'arrivo di un nuovo socket chiamato genericamente, almeno per il momento FM3.
Sembra che questo nuovo socket sarà destinato sia per le soluzioni Bristol Ridge ovvero APU con architettura Excavator, sia per le nuove soluzioni Summit Ridge basate sulla nuova architettura ZEN costruita a 14nm FinFET.
Al contrario del FM2+ la nuova infrastruttura non dovrebbe avere nessun southbrige montato sulla scheda mamma, dato che sia Summit Ridge/Bristol Ridge dovrebbero averlo integrato nel DIE.
Secondo gli ultimi rumors l'uscita prevista è per il terzo trimestre 2016...

Clicca qui...

già metto la faccina per prevenire le boiate che dirò.

Io non conosco l'architettura ZEN, ma so che l'Excavator sarebbe l'evoluzione di Zambesi/Piledriver/Steamroller.

A leggere così... sembrerebbe che AMD, visto che era in attesa sia di un silicio migliore del 32nm SOI per HP desktop e comunque pure in attesa delle risposte sul mercato di HSA e similari, si sia concentrata in una soluzione I/O dove sia NB che SB sarebbero integrati nel die, poi sarebbe l'architettura interna (Zen o Excavator) ad inquadrare l'ambito di utilizzo e le potenzialità... magari pure optando per soluzioni APU e non APU.

Quello che mi chiedo... facendo finta che l'FM3 sia il nuovo socket... potrebbe supportare proci APU e non APU? Avendo il PCI integrato nel die... in teoria non ci dovrebbero essere prb... nel senso che se si tratta di un APU, il collegamento IGP-PCI sarebbe già all'interno del die, fermo restando un teorico CF nel caso di una VGA discreta... mentre nel caso di CPU non APU, praticamente resterebbe valido il collegamento CF ma senza IGP nel procio, sarebbe collegata la discreta.

Se riflettiamo un attimo, nella progettazione/evoluzione di una architettura/procio, bisogna accorpare il tutto al silicio, perchè l'architettura deve lavorare nel suo range ottimale, cioè ad una frequenza/IPC migliore (e non più IPC ma con meno frequenza come Kaveri), con un numero di core ottimizzato (magari sarebbe stato meglio un Kaveri con un -5% di IPC ma con la commercializzazione di un X6), configurabile sia come APU che come X86, ottimizzato (credo) come Zen per minor consumi che come Excavator per massime prestazioni.

---------------
Faccio una piccola premessa... non voglio creare il solito battibecco... ma mettere in chiaro alcune cose, se le si vogliono vedere.
La soluzione CMT è stata molto criticata facendo apparire la soluzione HT l'unica valida... ma è così?
Il CMT ha un rendimento uniforme, cioè l'IPC a core (pure a modulo) è quello, la quantità di cache L2 è "fissa" a modulo e quindi lineare per n moduli come pure la L3.
L'HT invece è sensibile allo "spazio" non sfruttato dal core, è sensibile al numero di TH a core, richiede una cache via via superiore, ecc. ecc.
Prendendo il 5960X, a primo acchito abbiamo una potenza inferiore al doppio ma con un die maggiore al doppio rispetto a quello di un 8350 seppur prodotto a 22nm contro i 32nm dell'8350.
Mettiamo subito in chiaro che la max potenza è relativa per entrambi, perchè architetturalmente il 5960X potrebbe girare a 3,5GHz come i fratelli X6 come del resto un 8370 potrebbe uguagliare un 9370 ma nei 125W TDP... ed è chiaro che il 22nm Intel può permettere una potenza/TDP superiore al 32nm di AMD che nulla ha a che vedere con l'architettura.
Ma se guardiamo al numero di transistor, la soluzione CMT al max introduce un raddoppio del numero di transistor al raddoppio dei core (semplicemente perchè ad esempio un 2 moduli portato a 4 moduli incrementa i die dei 2 moduli ma condivide lo stesso I/O e lo stesso MC), mentre la soluzione Intel, perchè l'HT non abbia stalli, necessita della più alta velocità nel reperimento dati nelle cache come, chiaramente, una dimensione notevole.

[Nhirlathothep]

Originariamente inviato da paolo.oliva2

già metto la faccina per prevenire le boiate che dirò.

Io non conosco l'architettura ZEN, ma so che l'Excavator sarebbe l'evoluzione di Zambesi/Piledriver/Steamroller.

A leggere così... sembrerebbe che AMD, visto che era in attesa sia di un silicio migliore del 32nm SOI per HP desktop e comunque pure in attesa delle risposte sul mercato di HSA e similari, si sia concentrata in una soluzione I/O dove sia NB che SB sarebbero integrati nel die, poi sarebbe l'architettura interna (Zen o Excavator) ad inquadrare l'ambito di utilizzo e le potenzialità... magari pure optando per soluzioni APU e non APU.

Quello che mi chiedo... facendo finta che l'FM3 sia il nuovo socket... potrebbe supportare proci APU e non APU? Avendo il PCI integrato nel die... in teoria non ci dovrebbero essere prb... nel senso che se si tratta di un APU, il collegamento IGP-PCI sarebbe già all'interno del die, fermo restando un teorico CF nel caso di una VGA discreta... mentre nel caso di CPU non APU, praticamente resterebbe valido il collegamento CF ma senza IGP nel procio, sarebbe collegata la discreta.

Se riflettiamo un attimo, nella progettazione/evoluzione di una architettura/procio, bisogna accorpare il tutto al silicio, perchè l'architettura deve lavorare nel suo range ottimale, cioè ad una frequenza/IPC migliore (e non più IPC ma con meno frequenza come Kaveri), con un numero di core ottimizzato (magari sarebbe stato meglio un Kaveri con un -5% di IPC ma con la commercializzazione di un X6), configurabile sia come APU che come X86, ottimizzato (credo) come Zen per minor consumi che come Excavator per massime prestazioni.

---------------
Faccio una piccola premessa... non voglio creare il solito battibecco... ma mettere in chiaro alcune cose, se le si vogliono vedere.
La soluzione CMT è stata molto criticata facendo apparire la soluzione HT l'unica valida... ma è così?
Il CMT ha un rendimento uniforme, cioè l'IPC a core (pure a modulo) è quello, la quantità di cache L2 è "fissa" a modulo e quindi lineare per n moduli come pure la L3.
L'HT invece è sensibile allo "spazio" non sfruttato dal core, è sensibile al numero di TH a core, richiede una cache via via superiore, ecc. ecc.
Prendendo il 5960X, a primo acchito abbiamo una potenza inferiore al doppio ma con un die maggiore al doppio rispetto a quello di un 8350 seppur prodotto a 22nm contro i 32nm dell'8350.
Mettiamo subito in chiaro che la max potenza è relativa per entrambi, perchè architetturalmente il 5960X potrebbe girare a 3,5GHz come i fratelli X6 come del resto un 8370 potrebbe uguagliare un 9370 ma nei 125W TDP... ed è chiaro che il 22nm Intel può permettere una potenza/TDP superiore al 32nm di AMD che nulla ha a che vedere con l'architettura.
Ma se guardiamo al numero di transistor, la soluzione CMT al max introduce un raddoppio del numero di transistor al raddoppio dei core (semplicemente perchè ad esempio un 2 moduli portato a 4 moduli incrementa i die dei 2 moduli ma condivide lo stesso I/O e lo stesso MC), mentre la soluzione Intel, perchè l'HT non abbia stalli, necessita della più alta velocità nel reperimento dati nelle cache come, chiaramente, una dimensione notevole.

guarda la maggioranza di 5960x reggono i 4.5 ghz, e penso di non averne mai visti che non reggono 4.4 tranquillamente

[sgrinfia]

Robert Hallock ( Head of Global Marketing Tecnico di AMD ) ha condiviso qualcosa di interessante su Twitter precedenza. Voi ragazzi sapere che quando tu abbia una combo scheda grafica GPU dual-GPU che la memoria contempla per GPU giusto?

Così una scheda grafica da 8 GB è davvero 2x4GB. Così com'è ora, questo sarà diverso quando DirectX 12 entra in gioco e apparentemente già è con manto. Fondamentalmente egli afferma che due GPU finalmente saranno agiscono come 'una grande' GPU. Ecco la sua citazione completa:

Mantle è il primo API grafiche di trascendere questo comportamento e permettere che tanto necessario controllo esplicito. Ad esempio, si potrebbe fare il rendering split-frame con ogni annuncio GPU gestire la rispettiva framebuffer 1/2 dello schermo. In questo modo, le GPU hanno informazioni estremamente minimale, consentendo entrambe le GPU a comportarsi efficacemente come un unico grande GPU / più veloce con un corrispondentemente elevato pool di memoria.

In ultima analisi il punto è che i giocatori credono che due schede da 4GB non può eventualmente dare il 8GB di memoria utile. Che potrebbe essere stato vero per gli ultimi 25 anni di giochi per PC, ma quello non è vero con mantello e la sua non è vero con le basse API aeree che seguono le orme di Mantle. - Thracks (Robert Hallock, AMD)

C'è un fermo, però, questo non è fatto automaticamente, le nuove API consentono memoria stacking ma gli sviluppatori di giochi sarà necessario ottimizzare specificamente i giochi in quanto tali. Una dichiarazione interessante.

Tenete a mente, però, questo è un parlare di marketing rep ...

[fracama87]

O.o chi è che ha fatto la traduzione? In inglese era più comprensibile (senza offesa se sei stato tu)

[sgrinfia]

Both Mantle and DX12 can combine video memory
by Hilbert Hagedoorn on: 02/03/2015 03:33 PM | Source | 14 comment(s) ]

Robert Hallock (Head of Global Technical Marketing at AMD) shared something interesting on Twitter earlier on. You guys know that when your have a GPU graphics card combo with dual-GPUs that the memory is split up per GPU right ?

Thus an 8GB graphics card is really 2x4GB. As it stands right now, this will be different when DirectX 12 comes into play and apparently already is with Mantle. Basically he states that two GPUs finally will be acting as ‘one big’ GPU. Here's his complete quote:

Mantle is the first graphics API to transcend this behavior and allow that much-needed explicit control. For example, you could do split-frame rendering with each GPU ad its respective framebuffer handling 1/2 of the screen. In this way, the GPUs have extremely minimal information, allowing both GPUs to effectively behave as a single large/faster GPU with a correspondingly large pool of memory.

Ultimately the point is that gamers believe that two 4GB cards can’t possibly give you the 8GB of useful memory. That may have been true for the last 25 years of PC gaming, but thats not true with Mantle and its not true with the low overhead APIs that follow in Mantle’s footsteps. – @Thracks (Robert Hallock, AMD)

There is a catch though, this is not done automatically, the new APIs allow memory stacking but game developers will need to specifically optimize games as such. An interesting statement.

Keep in mind though, this is a marketing rep talking ...

[maurix74]

Salve a tutti, scusate l'intromissione in questa discussione, volevo un parere se possibile su queste 2 schede madri:

http://it.msi.com/product/mb/970-GAM...-specification

http://www.asrock.com/mb/AMD/Fatal1t...Specifications

Per quanto riguarda la MSI ho letto recensioni positive e sembra una buona scheda anche considerando il collaudato chipset 970, la scheda della asrock è nuova e non ci sono ancora delle review ma anche qui dalle specifiche sembra una buona scheda.

Grazie per l'eventuali risposte

[paolo.oliva2]

Originariamente inviato da Nhirlathothep

guarda la maggioranza di 5960x reggono i 4.5 ghz, e penso di non averne mai visti che non reggono 4.4 tranquillamente

Se rileggi il mio post, il mio discorso è legato al l'architettura e non all'OC, perché mi sono limitato ad un TDP Def.
Ti spiego meglio. In OC nulla è tranquillo perché quando esci dai margini garantiti, tutto funziona a patto che... come l'ho potuto provare di persona. Nel mio specifico, un 8350 in Costa d'Avorio, il problema non è la temperatura del procio in sé, ma dell'insieme... dove il TDP di partenza conta. Quando la temperatura ambiente è 36° e arriva immediatamente a oltre i 40 come avvii il PC nella stanza, a liquido in OC per assurdo non è il procio il prb, ma tutto il resto.... perché se forzi al massimo ti si resetta il PC ( più probabilmente ti va in protezione) dal lato procio, ma dal lato modo arriva la morte (come defunto le mie CF).
Per assurdo, il prb non è la qualità in sé, ma proprio il TDP, vedi Asrock 95W durata 6 mesi mentre CF V-z, CF-V manco 2 mesi in 2... questo perché? Perché secondo me tiene più botta una mobo 95W portata a 120 di quanto possa fare una 140 a 145, perché alla fine i componenti elettronici sono quelli e quelli saltano, alla faccia di qualsiasi bontà di progettazione.
Ed è qui che conta il TDP nominale, perché più sarà basso quello Def e più margine si avrebbe e per contro più sarà alto e più sarà probabile fare downclock e manco pensare all'OC.

[Nhirlathothep]

Originariamente inviato da paolo.oliva2

Se rileggi il mio post, il mio discorso è legato al l'architettura e non all'OC, perché mi sono limitato ad un TDP Def.
Ti spiego meglio. In OC nulla è tranquillo perché quando esci dai margini garantiti, tutto funziona a patto che... come l'ho potuto provare di persona. Nel mio specifico, un 8350 in Costa d'Avorio, il problema non è la temperatura del procio in sé, ma dell'insieme... dove il TDP di partenza conta. Quando la temperatura ambiente è 36° e arriva immediatamente a oltre i 40 come avvii il PC nella stanza, a liquido in OC per assurdo non è il procio il prb, ma tutto il resto.... perché se forzi al massimo ti si resetta il PC ( più probabilmente ti va in protezione) dal lato procio, ma dal lato modo arriva la morte (come defunto le mie CF).
Per assurdo, il prb non è la qualità in sé, ma proprio il TDP, vedi Asrock 95W durata 6 mesi mentre CF V-z, CF-V manco 2 mesi in 2... questo perché? Perché secondo me tiene più botta una mobo 95W portata a 120 di quanto possa fare una 140 a 145, perché alla fine i componenti elettronici sono quelli e quelli saltano, alla faccia di qualsiasi bontà di progettazione.
Ed è qui che conta il TDP nominale, perché più sarà basso quello Def e più margine si avrebbe e per contro più sarà alto e più sarà probabile fare downclock e manco pensare all'OC.

editato :


il discorso del danno alle mobo anziche' alla cpu quando si e' a temp e umidita' elevate e' interessante, ma non so se siano corrette le conclusioni , cioe' imputare il problema al tdp.

Le CF V tenute a 145 non credo siano sotto stress e la asrock 95w a 120 in teoria lo sarebbe.

non mi rendo conto delle temp, cioe' una mobo a 145 scalda sensibilmente di piu' che a 120w ? di che temp si parla ?
di sicuro i controlli a Tj che ha la cpu, i chipset non li hanno, quindi temp alte potrebbero ucciderle, ma forse ci sono anche problemi legati all' umidita' che non coinvolgono il processore.


poi se fosse proprio legato al tdp, dovresti essere il piu' motivato del forum ad usare processori solo intel

oppure sarebbe da prendere la terza CF V e tenerla a 120