[Thread Ufficiale V3.0] AMD K10 Phenom Quad/Triple/Dual Core

[capitan_crasy]

Originariamente inviato da maxsona

Bench MCP78U

---

Foto MoBo MCP78U

http://forum.hkepc.com/viewthread.ph...3D1&sid=t5RAmE

Grazie per la segnalazione...

[Vifani]

Originariamente inviato da capitan_crasy

Secondo il sito digitimes.com Nvidia avrebbe ritardato ancora una volta le consegne del chipset MCP780U ( chipset Geforce9200 ) per problemi legati alle temperature.
Il chipset AMD 780G sarebbe più veloce di 15/20% rispetto al chipset Nvidia MCP780S ( chipset 8200 ), mentre MCP780U causa frequenze più alte della IGP avrebbe problemi di calore non ancora risolti da Nvidia.
Questo problema sta avvantaggiando AMD in quando i chipset 780G e 780V sono già stati consegnati hai produttori di schede mamme, mentre Nvidia ha rimandato il tutto a fine gennaio/inizio febbraio.
Viene segnalato un problema al nuovo SB700 dove ci sarebbe un malfunzionamento al generatore di clock interno del southbridge.
I produttori hanno già risolto per vie esterne il problema, ma AMD ha comunicato che presto rilascerà una revisione del Southbridge (SB710) per risolvere internamente il problema.

Clicca qui...

Beh lato chipset penso che AMD stia facendo abbastanza bene. Anche con il SB450 prima, SB600 durante ed il SB700 dopo, qualcosa che non va esce sempre, però alla fine si tratta di aspetti su cui si può andare oltre. Io sto trovando molto buone, ad esempio, le soluzioni A690. La grafica integrata è ottima per le applicazioni d'ufficio, Windows Vista, la riproduzione video (anche HD) e anche qualche giochino semplice (alla The Sims 2 per intenderci).

[capitan_crasy]

Originariamente inviato da Shang Tsung

Il bug anche nel sb700? orami fanno tutto con bug, è una caratteristica.

Non viene specificato nel dettaglio, ma può darsi che sia un problema di alimentazione o qualcosa legata ad essa.
Comunque se i produttori hanno risolto loro stessi significa che il problema non è affatto grave, anzi...

Ma questo sb700 chi l'ha progettato? intendo: è sb600 con quanche aggiunta o totalmente nuovo?

Ossia: è sempre promise (o silicon image, non ricordo?) o è amd?

Ha dire la verità non lo sò di preciso chi ha progettato la logica delle SATA2, sicuramente non è AMD...
Quello che si sa è che il SB700 è pin to pin con SB600, ma quest'ultimo non è compatibile con i nuovi chipset 780G e 780V.
Quello che occorre è aumentare la banda passante di collegamento tra il Northbridge e Southbridge

[maporca]

Scusate..... ma fin qui.... i bench che ci sono in giro sono riguardanti il phenom e win. E in questo ambito hanno dato risultati per ora deludenti ( vedremo B3 e 45nm poi) rispetto a intel.

Ma siccome avevo letto di una comparazione tra amd e intel in ambito linux dove amd avrebbe dato le mazzate anche al penryn in ambito server, e siccome il bug tlb sotto win deve essere corretto via bios, con degrado forte, mentre in linux con patch e senza degrado forte....

mi sovviene un dubbio..... non e' che sti phenom sotto linux vanno molto meglio che sotto win ? ovvero il phenom sotto linux non e'' sotto intel ma addirittura in linea con le aspettative ?

Servirebbero dei bench incrociati intel vs amd vs linux vs win , su applicativi reali.

Porca zozza... in pratica trovo solo bench intel vs amd e SOLO in ambito win.

Perche' non hanno fatto le stesse prove ma in ambito linux ???????

Ps. ma poi ... tutto sto casino col bug tlb e corretto via bios, quando con linux e' suff una patch al kernel e senza degrado apprezzabile.... ma non potevano fixare anche il kernel di windows ? senza intaccare il bios e senza creare degradi forti ???

[Capozz]

Cmq questo hybrid sli sembra interessante, ci sono maggiori informazioni in merito ? Sapete se magari supporta anche lo sli tra due tipi di gpu differenti (se si montano due schede discrete, ad esempio) ?

[Scrambler77]

Originariamente inviato da maporca

Ps. ma poi ... tutto sto casino col bug tlb e corretto via bios, quando con linux e' suff una patch al kernel e senza degrado apprezzabile.... ma non potevano fixare anche il kernel di windows ? senza intaccare il bios e senza creare degradi forti ???

Mi spieghi perchè io (per esempio) che non ho AMD dovrei "fixare" un kernel windows che va già bene?

Su linux il 99% degli utenti (me compreso) ricompilano il proprio kernel, per cui una patch la si applica in funzione delle proprie necessità, ed essendo open, permette a chiunque di sviluppare patch e a chiunque di utilizzarla senza imposizioni di sorta.

Windows dovrebbe invece fixare il proprio kernel (e poi fixare cosa, se il bug è di AMD - al massimo "patchare") su tutta la sua linea (da xp home a 2003 server, da x32 a x64, via webupdate, coinvolgendo anche coloro che non hanno problemi.

L'unica che deve fixare è AMD (anche e soprattutto per una questione di immagine). Per ora il modo più rapido è stato via BIOS... ed è per ora la cosa più giusta. Domani dovrà fixare AMD, senza costringere l'utente a patchare il proprio sistema operativo.

[Capozz]

Originariamente inviato da Scrambler77

Mi spieghi perchè io che non ho AMD dovrei "fixare" un kernel windows che va già bene?

Su linux il 99% degli utenti (me compreso) ricompilano il proprio kernel, per cui una patch la si applica in funzione delle proprie necessità, ed essendo open, permette a chiunque di sviluppare patch e a chiunque di utilizzarla senza imposizioni di sorta.

Windows dovrebbe invece fixare il proprio kernel (e poi fixare cosa, se il bug è di AMD - al massimo "patchare") su tutta la sua linea (da xp home a 2003 server, da x32 a x64, via webupdate, coinvolgendo anche coloro che non hanno problemi.

L'unica che deve fixare è AMD (anche e soprattutto per una questione di immagine). Per ora il modo più rapido è stato via BIOS... ed è per ora la cosa più giusta. Domani dovrà fixare AMD, senza costringere l'utente a patchare il proprio sistema operativo.

E che c'è di male a mettere una patch scusa ? Se hai AMD la metti, se hai Intel non la metti, non vedo dove sia il problema.

[Cloud76]

Originariamente inviato da capitan_crasy

Viene segnalato un problema al nuovo SB700 dove ci sarebbe un malfunzionamento al generatore di clock interno del southbridge.
I produttori hanno già risolto per vie esterne il problema, ma AMD ha comunicato che presto rilascerà una revisione del Southbridge (SB710) per risolvere internamente il problema.

Clicca qui...

Originariamente inviato da capitan_crasy

Non viene specificato nel dettaglio, ma può darsi che sia un problema di alimentazione o qualcosa legata ad essa.
Comunque se i produttori hanno risolto loro stessi significa che il problema non è affatto grave, anzi...


Ha dire la verità non lo sò di preciso chi ha progettato la logica delle SATA2, sicuramente non è AMD...
Quello che si sa è che il SB700 è pin to pin con SB600, ma quest'ultimo non è compatibile con i nuovi chipset 780G e 780V.
Quello che occorre è aumentare la banda passante di collegamento tra il Northbridge e Southbridge

Ci mancava pure il bug nel SB700
Ora che fanno? Prima fanno uscire le nuove schede AM2+ con il vecchio SB600... ora faranno uscire la rev.2 con il SB700 buggato... per vedere una piattaforma "normalmente funzionante" dobbiamo aspettare ancora l'SB710...

Da quello che c'è scritto nel link il bug invece sembra grave: l'SB700 ha un bug nel generatore di clock interno e questo non è che può essere corretto via software.... i produttori di schede madri hanno dovuto aggiungere sulle mobo un generatore di clock esterno che sostituisce quello interno del southbridge. Alla fine il problema viene aggirato ma è pur sempre una toppa messa per un altro grave bug... qualche peggioramento secondo me lo porterà essendo di fatto un controller esterno che ne sostituisce uno interno.

@Shang Tsung
Nella recensione di techreport che confronta le schede AM2+ viene detto che l'SB600 è di Silicon Image.

[capitan_crasy]

Originariamente inviato da Cloud76

@Shang Tsung
Nella recensione di techreport che confronta le schede AM2+ viene detto che l'SB600 è di Silicon Image.

La logica SATA2 del SB600 è stato progettato da promise; The Tech report si sbaglia alla grande...

[Cloud76]

Originariamente inviato da capitan_crasy

La logica SATA2 del SB600 è stato progettato da promise; The Tech report si sbaglia alla grande...

Infatti mi sembrava di ricordare che avessi detto che era di Promise, si vede che stanno festeggiando anche loro insieme agli ingegneri AMD
Teoricamente però se l'SB700 è di Promise alla fine il bug è colpa di Promise, non di AMD... no?
Non è che il chip possa essere fatto per un pezzo da AMD e per un pezzo da Promise...

[paolo.oliva2]

Originariamente inviato da maporca

Scusate..... ma fin qui.... i bench che ci sono in giro sono riguardanti il phenom e win. E in questo ambito hanno dato risultati per ora deludenti ( vedremo B3 e 45nm poi) rispetto a intel.

Ma siccome avevo letto di una comparazione tra amd e intel in ambito linux dove amd avrebbe dato le mazzate anche al penryn in ambito server, e siccome il bug tlb sotto win deve essere corretto via bios, con degrado forte, mentre in linux con patch e senza degrado forte....

mi sovviene un dubbio..... non e' che sti phenom sotto linux vanno molto meglio che sotto win ? ovvero il phenom sotto linux non e'' sotto intel ma addirittura in linea con le aspettative ?

Servirebbero dei bench incrociati intel vs amd vs linux vs win , su applicativi reali.

Porca zozza... in pratica trovo solo bench intel vs amd e SOLO in ambito win.

Perche' non hanno fatto le stesse prove ma in ambito linux ???????

Ps. ma poi ... tutto sto casino col bug tlb e corretto via bios, quando con linux e' suff una patch al kernel e senza degrado apprezzabile.... ma non potevano fixare anche il kernel di windows ? senza intaccare il bios e senza creare degradi forti ???

Sinceramente ho sentito di un fix per linux che faceva il workaround con una perdita minima dell'1%. Ma comunque i fix del Bios, che tu lavori sotto windows o sotto linux, sono delle patch che intaccano la logica di funzionamento, disabilitando (nel caso Phenom) delle implementazioni velocitistiche da un lato e escludento la L3 per altri versi. Il Bios non riporterebbe altro che la caratteristica della CPU al software a basso livello che dialoga con l'hardware. E' come se ad esempio il bios riportasse al SO che la cpu è un core2 e non un Penryn e quindi la cache ulteriore e/o delle istruzioni aggiuntive andrebbero perse.
La migliore performance del Phenom sotto linux non è derivante da questi fix, ma dalla logica sua che come gestione multiprocessore, banda passante ed altro, che anche se buggato, lo rende molto più performante di Core2

[paolo.oliva2]

Originariamente inviato da Scrambler77

Mi spieghi perchè io (per esempio) che non ho AMD dovrei "fixare" un kernel windows che va già bene?

Su linux il 99% degli utenti (me compreso) ricompilano il proprio kernel, per cui una patch la si applica in funzione delle proprie necessità, ed essendo open, permette a chiunque di sviluppare patch e a chiunque di utilizzarla senza imposizioni di sorta.

Windows dovrebbe invece fixare il proprio kernel (e poi fixare cosa, se il bug è di AMD - al massimo "patchare") su tutta la sua linea (da xp home a 2003 server, da x32 a x64, via webupdate, coinvolgendo anche coloro che non hanno problemi.

L'unica che deve fixare è AMD (anche e soprattutto per una questione di immagine). Per ora il modo più rapido è stato via BIOS... ed è per ora la cosa più giusta. Domani dovrà fixare AMD, senza costringere l'utente a patchare il proprio sistema operativo.

A parte che volendo si può fare una discriminazione, perché... è come se windows nell'aggiornamento rileva un nuovo driver aggiornato per la tua VGA. A tutti gli effetti il programma di upgrade ha passato l'informazione del tuo hardware ed in base a questa informazione c'è stata una elaborazione ecc. ecc. Basterebbe che in caso di aggiornamento venga passato il tipo di cpu, e solo chi ha Phenom, ed eventualmente che versione... per poi ritornare alla normalità mediante un altro upgrade con la versione B3 o >. Comunque sarebbe una cosa impensabile
Ma non è questo il punto. Il problema è di AMD. L'errore è di AMD, in una cpu AMD. Perché altri dovrebbero sobbarcarsi lavoro per risolvere una pecca di AMD? Fosse un qualcosa di duraturo, magari pagando, AMD potrebbe prevedere. Ma visto (si spera) il poco tempo e poi su che scala in percentuale? Quanti l'avranno comprato? 10.000 persone in tutto il mondo?

[bonzuccio]

Originariamente inviato da paolo.oliva2

..
La migliore performance del Phenom sotto linux non è derivante da questi fix, ma dalla logica sua che come gestione multiprocessore, banda passante ed altro, che anche se buggato, lo rende molto più performante di Core2

Cioè Linux sfrutta in maniera degna le macchine multiprocessore cosa che windows fa in maniera molto embrionale a confronto

[capitan_crasy]

Originariamente inviato da Cloud76

Infatti mi sembrava di ricordare che avessi detto che era di Promise, si vede che stanno festeggiando anche loro insieme agli ingegneri AMD
Teoricamente però se l'SB700 è di Promise alla fine il bug è colpa di Promise, non di AMD... no?
Non è che il chip possa essere fatto per un pezzo da AMD e per un pezzo da Promise...

esatto...
La logica delle porte SATA2 è di promise, tutto il resto è di ATI/AMD...
Il problema nel far progettare tecnologie esterne da AMD è il pericolo di un intoppo dell'ultimo minuto.
Non ha caso SB600 doveva avere la funzione RAID 5, ma durante le prove di conferma si scoprì un problema sulla gestione di questo RAID, non correggibile se non con una modifica hardware importante.
Ora devo ammettere la mia ignoranza sulla questione del "generatore di clock interno" interno o esterno, ma non dovrebbe compromettere le prestazioni delle porte SATA2 del SB700.
Qualche anno fa ATI aveva l'occasione di acquistare ULI, ma invece si fece fregare da Nvidia e ULi finì nell' oblio più totale...

[Master Mystery]

Domanda tecnica.. i phenom, così come i futuri nahalem di intel, hanno il controller di memoria integrato.. cioè i dati invece di passare dalla ram al procio, va direttamente al controller integrato del procio, non avendo più il problema della velocità delle ram riguardo all'overclock esatto? Quindi si potrebbero fare CPU che arrivano tranquillamente a 4Ghz o anche di più di fabbrica, quindi dal prossimo anno dovremmo aspettarci nahalem e phenom B3 45nm col bug risolto dai 4ghz in su no? Mentre nel thread leggo di possibili B3 da 3ghz che salgono "in overclock" a 3500.. Non è poco?

[paolo.oliva2]

Originariamente inviato da Master Mystery

Domanda tecnica.. i phenom, così come i futuri nahalem di intel, hanno il controller di memoria integrato.. cioè i dati invece di passare dalla ram al procio, va direttamente al controller integrato del procio, non avendo più il problema della velocità delle ram riguardo all'overclock esatto? Quindi si potrebbero fare CPU che arrivano tranquillamente a 4Ghz o anche di più di fabbrica, quindi dal prossimo anno dovremmo aspettarci nahalem e phenom B3 45nm col bug risolto dai 4ghz in su no? Mentre nel thread leggo di possibili B3 da 3ghz che salgono "in overclock" a 3500.. Non è poco?

Alla fine è uguale. Il controller delle ram l'AMD lo ha prima dei Phenom. Ora comunque l'ha diviso, forse perché è stata introdotta la L3.
Per quello che riguarda il clock minimo, questo non è derivante dal clock della ram. I moltiplicatori delle CPU assegnano sempre la stessa velocità alla ram, salvo divisioni dispari e quindi spostate verso il valore più vicino ma più basso rispetto al default.
Comunque al momento, nel casi di AMD, i clock alti delle cpu non sono certo per il problema della velocità della RAM. I Phenom hanno una banda si può dire doppia, quindi ad un uguale IPC gli AMD potrebbero avere un clock doppio degli Intel senza (o perlomeno avendo le stesse) limitazioni attuali.
La produzione Intel è più rodata ed il core2 è già alla seconda release... in più con die a 45nm. AMD è più indietro con la tecnologia e più restia comunque a salire di frequenza.
Comunque sembrerebbe che con il B3 si avrà un IPC superiore al Core2 ed ancora di più con il secondo step al passaggio a 45nm.
Comunque nella logica della singola CPU con massima potenza di elaborazione, dubito che a tempi brevi l'AMD riesca a superare Intel. Credo che Intel i 4GHz siano dietro l'angolo, mentre i 3,5GHz per AMD al momento sarebbero un punto di arrivo. Comunque la possibilità, per altro già comunicata da AMD, di poter realizzare una CPU 8 core "attaccando" 2 Phenom potrebbe portare ad un complessivo raddoppio di prestazioni.

-------

Una cosa. Il Phenom lo "danno" con 285mm2 di die e 480 milioni di transistor. Facendo comparazioni... l'Intel Pentium D900 con 376 milioni di transistor, prodotto sempre a 65nm, avrebbe un die di 280mm2. 100 milioni in meno di transistor ed uguale dimensione? Sempre a 65nm?
Il Core2 Duo, l'E6400, ha 167 milioni di transistor, ed è prodotto a 65nm. è 1/3 dei transistor del Phenom. quindi in teoria dovrebbe avere un Die di 1/3 del Phenom. E6400 = 111mm2, x 3 = 333mm2...
Qualcosa non mi torna.


http://www.tomshw.it/cpu.php?guide=2..._duo_conroe-03

[El Alquimista]

Originariamente inviato da capitan_crasy

... mentre MCP780U causa frequenze più alte della IGP avrebbe problemi di calore non ancora risolti da Nvidia.

un ritorno dei fantasmi del passato?

possono chiedere ai "loro" ottimi sviluppatori ULI

[capitan_crasy]

io passo e chiudo...
Auguro a tutti un buon anno...

[pozen]

Originariamente inviato da capitan_crasy

io passo e chiudo...
Auguro a tutti un buon anno...

buon anno a tutti !!!

[maporca]

Originariamente inviato da paolo.oliva2

Sinceramente ho sentito di un fix per linux che faceva il workaround con una perdita minima dell'1%. Ma comunque i fix del Bios, che tu lavori sotto windows o sotto linux, sono delle patch che intaccano la logica di funzionamento, disabilitando (nel caso Phenom) delle implementazioni velocitistiche da un lato e escludento la L3 per altri versi. Il Bios non riporterebbe altro che la caratteristica della CPU al software a basso livello che dialoga con l'hardware. E' come se ad esempio il bios riportasse al SO che la cpu è un core2 e non un Penryn e quindi la cache ulteriore e/o delle istruzioni aggiuntive andrebbero perse.
La migliore performance del Phenom sotto linux non è derivante da questi fix, ma dalla logica sua che come gestione multiprocessore, banda passante ed altro, che anche se buggato, lo rende molto più performante di Core2

Rispondo a te per far prima ma in realta' anche ad altri.

Io non volevo dire che e' il fix BIOS non fosse fa fare.
Volevo solo dire che sotto linux e' stato risolto il problema con una patch
e che si poteva fare anche sotto win. ( infatti ricordo di patch ( o fix che dir si voglia ( chi voleva capire il mio discorso lo ha capito , chi voleva fare il fighetto no...)) applicabili a chi aveva certi proci.

Ad Ogni modo E' interessante ( ed e' una risposta pertinente alla mia domanda ) quello detto da PaoloOliva 2, ovvero:
Per il phenom, sotto linux le cose sono migliori che sotto win, in termini di confronto tra
il k10e il core2quad.
Questa affermazione e' comprovata ?

Ecco perche' chiedevo di Bench in ambito linux ma della stessa tipologia di quelli effettuati in win, e sotto il profilo ..Desktop.

Quella notizia che diceva Paolo era quella a cui mi riferivo anche io ( meno dell' 1% patch vs fixbios)
In ambito SERVER sembra essere il phenom sotto linux
E S T R E M A M E N T E performante.

Insomma ...se le cose stanno cosi' .. non e' tutto sto MALE questo phenom ..dato che oggi come oggi non esiste SOLO win....
AMD ha fatto un procio che rende meglio sotto linux ?
AMD non riesce a distanziare intel sotto win ma sotto linux si ?


Ps. Buoooooooooonnnnn annnnnnooooooooooooo