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

[paolo.oliva2]

Originariamente inviato da Ratatosk

Che vengano dalla stessa linea produttiva è molto probabile, ma architetturalmente non sono identici come pensava Paolo :>

Io rispondevo veramente ad un altro post dove si evidenziava che i proci per reparto server hanno caratteristiche di silicio superiori e che gli Opteron sopportano temperature anche di 15° superiori e con Vcore inferiori.
Questo è vero ma ora con gli Shanghai e Deneb la produzione del silicio dei 2 proci è la stessa catena di montaggio... probabile che venga bruciato o disattivato nell'MC il supporto per quel tipo di memorie, ma io ho scritto uguali non per le differenze dell'MC, ma per le caratteristiche del silicio... cioé che un Deneb se viene fuori dalla stessa catena del Shanghai, non credo che abbia caratteristiche di minor OC o di sopportare temperature di esercizio più basse... chiaramente io su queste basi li giudico uguali, anche perché dimmi chi ci schiafferebbe in desktop le memorie molto più costose del tipo server (e pure più lente), anche se le supportasse e ci fossero mobo che le potrebbero montare...
Cosa diversa invece sarebbe che uno comprerebbe un procio Deneb e poi nel caso sia possibile uno zoccolo adattatore per renderlo 1207 compatibile... e risparmiare un totale di soldini... quindi reputerei molto probabile che AMD avrà fatto un qualche cosa per rendere incompatibile la cosa, seppur con proci simili

[paolo.oliva2]

Originariamente inviato da giogts

paolo
1)non è che ti va di comprarti la Asrock 790gx?
2)quanti Deneb hai intenzione di comprarti?
3)ne lascerai qualcuno anche a noi?

Nell'immediato sicuramente un 3GHz.
Poi vediamo come va... chiaro che se il prezzo è ottimo come pure i consumi, upgradare al Deneb i miei 9950 direi che sarebbe una cosa già fatta.
Ma sto guardando pure il thread del Nehalem... sono parecchio incuriosito.
Mi ha sorpreso l'affermazione di uno che ha acquistato il Nehalem a 2,666GHz e lo sta occando... e alla mia domanda se con i proci superiori vi sono OC maggiori lui ha risposto che al mom non c'è alcuna differenza... e può capitare che un 2,666 sia più occabile di un 3,2GHz (per il discorso TDP stanno tutti cercando di capire la reale temp del procio, perché le temp sono veramente alte, molto più alte dei Core2 anche se il TDP dichiarato del Nehalem è il medesimo. Ma a me non genera prb, in quanto ho il liquido e tutto sommato i 4GHz sono fattibili con Nehalem e Deneb sotto carico estremo)
Questo mi fa vedere in ottica diversa il Nehalem, nel senso che il costo del procio a 2,666 è tutto sommato accettabile, e che le mobo costicchiano, si, ma sono comunque mobo di ottima qualità sia di progettazione, dissipazione che alimentazione... direi solo 50-100€ di ladrocinio e basta... probabilmente poi destinate a calare di prezzo.

Tornando in tema... sono un attimo invogliato dal Nehalem... e potrei anche decidere di acquistarlo... Quindi 1 Deneb a 3GHz, magari un 3,2 o FX come uscirebbe, ed un Nehalem per confronto... così schianto tutte le disinformazioni sul nascere...

Per la 790GX direi che non mi attira... non perché Asrock, ma perché comunque sono mobo non destinate all'OC estremo ma direi al minor consumo possibile che è tutt'altra cosa rispetto al massimo OC. Gli OC attuali sono solo una cosa momentanea... e sono disposto a scommettere il mondo che con i Deneb tra una 790GX ed una 790FX/SB750 ne vedremo di differenza, e non poca, specialmente con dissi a liquido... e mi sento un avvoltoio per poter confermare con i fatti le mie teorie... aspetto solo di ordinare sto Deneb.

Se siete curiosi leggete questo mio OT

[astroimager]

Originariamente inviato da bonzuccio

Veramente i primi Barcelona erano appetibili a prescindere,

Mah... non so... ne sei sicuro? Certamente non erano molto utilizzabili in virtualizzazione e per workstation...

per quanto riguarda i consumi sappiamo che un Sciangai 2.7 ghz consuma meno di un B3 a 2.3 mi pare
tipo il 35% in idle e il 10% in full scusa se è poco

E chi ha detto il contrario?
Grazie alla prodigiosa architettura "esterna" il K10 è ancora fortemente competitivo nel settore server, per non dire che spacca... e il bello è che le potenzialità di questo sistema, ideato diversi anni fa, sembrano non esaurirsi in Shanghai... vedremo.

Io mettevo in guarda sulla situazione desktop, un mondo completamente diverso, dove entrano in gioco architetture, software ed esigenze molto diversi. Con ciò non dico che Deneb deluderà, è un passo avanti comunque notevole rispetto ad Agena B3, però non aspettatevi il boost che abbiamo visto con Shanghai.
Naturalmente, come sempre, felice di essere smentito.

[Megakirops]

Originariamente inviato da Ratatosk

I Santa Ana sono identici agli A64. Vedi tutta quella cache perché gli Opteron dual core sono tutti a 90nm, come i relativi A64, e non a 65nm e cache dimezzata come gli ultimi A64 usciti.

Per l'altra questione dipende semplicemente dal fatto che solitamente i die per gli Opteron vengono da centro wafer e sono di qualità migliore, ma architetturalmente sono del tutto identici.

Hai parzialmente ragione. Gli A64X2 a 90nm su am2 sono solo i Windsor e tra questi solo i modelli
* 4000+: 2000 MHz
* 4400+: 2200 MHz
* 4800+: 2400 MHz
* 5200+: 2600 MHz (F2/F3)
* 5600+: 2800 MHz (F3)
* 6000+: 3000 MHz (F3)
* 6400+: 3200 MHz (F3)
hanno 1024KB di cache L2, tra i quali i primi 2 ed il 3° non li ho mai trovati disponibili negli shop per non parlare del fatto che furono ritirati dal mercato in breve tempo ( primo rilascio 23 maggio 2006 ) perchè sostituiti dai Brisbane a 65nm SOI rilasciati il 5 dicembre 2006 che dissero addio alla chace L2 da 2mega. Tornando ancora + indietro al socket 939, che tralasciando il controller ddr1 e qualche altro elemento di controllo hanno la stessa architettura, solo i core Toledo 4400+ e 4800+ hanno la stessa cache. Il fatto del centro wafer te lo appoggio tutto.

in conclusione hai ragione a dire che hanno la stessa architettura, su questo non ci piove, ma si differiscono per la qualità nettamente superore degli opteron ed è questo che volevo dire nel mio post precedente

[bjt2]

La buona notizia è tutti i vecchi bachi fino al B3 sono stati corretti. Il terribile 298, il 309, i bachi sulla divisione, sulle funzioni stringa, sull'accesso in memoria con dati non allineati e molto importante per l'OC, l'instabilità con DIMM 1066 (355 e 370)...

Il C2 ha dei bachi che non hanno le precedenti revisioni.

327: violazione di resistenza elettrica sull'HT con nessuna conseguenza.

339: leggero ritardo tra 35 e 90 ns in stato attivo e fino a 640 ns in risparmio energetico (C1E) del riazzeramento del timer APIC. Per la precisione che ha questo timer il ritardo è non significativo. Errore poco grave, tanto più che si verifica solo quando il timer è arivato a fine corsa e deve riazzerarsi.

342: baco grave per la virtualizzazione. In determinati casi il guest può girare con le interrupt disabilitate rischiando che l'hypervisor perda la possibilità di riprendere il controllo. Se in quell'intervallo in cui le interrupt sono disabilitate il SO guest si blocca l'hypervisor non riuscirà più a riprendere il controllo.

343: se il BIOS usa la cache L2 come memoria tampone prima di inizializzare il controller RAM, dei dati possono essere invalidati. Il BIOS deve disabilitare qualcosa della L2 prima di usarla e riabilitarla quando ha finito. Bug non grave.

346: se un core ha frequenza maggiore del NB e se un altro core ha una frequenza minore del NB ma ottenibile da una divisione pari (2,4,6,8 ecc...) il processore potrebbe non essere in grado di fare un cache probe e bloccarsi. La soluzione è disabilitare qualcosa, ma non sono riuscito a trovare il registro nella guida e non so cosa si disabilita. Potrebbe impattare le prestazioni ma non è possibile determinarlo.

348: la resistenza di terminazione ha valore maggiore delle specifiche. Questo potrebbe ridurre i margini delle memorie e potenzialmente ridurre l'OC.

350: durante un cold reset la RAM può fallire l'inizializzazione. E' specificata una procedura per evitare che ciò accada. Questo non ha impatto sulle prestazioni. Bug lieve.

351: lo stato di riposo LS2 dell'HT non funziona correttamente. Bisogna usare LS1. Dovrebbe comportare solo un minore risparmio energetico.

352 353: SYSCALL e SYSRET eseguite incorrettamente se c'è un breakpoint. Questo baco affligge solo idebugger del kernel. E' specificato come evitare il problema. Non interesa l'uso normale del sistema.

359: la CPU ritarda di 200 microsecondi l'inizio del clock alla memoria. Non è stato rilevato alcun malfunzionamento, ma se qualche DIMM è sensibile a questo ci potrebbero essere problemi al BOOT.

360: prossibile riduzione dei margini della memoria se i registri di intensità dei PIN della RAM sono diversi tra loro e diversi dai valori raccomandati. Problemi si possono verificare solo con timing 1T. Nessun problema con timing 2T. Quindi questo significa che se le DIMM non sono identiche potrebbe essere necessario impostare timing 2T per avere più margine sulla memoria (per esempio in OC).

361: in un caso particolare potrebbe perdersi un breakpoint di una istruzione in un sistema guest. Bug veniale, che inderessa solo il debugging di applicazioni in macchine virtuali.

362: la CPU può bloccarsi sul warm reset se durante esso riceve dei pacchetti illegali sui link HT non coerenti. Non influisce sul cold reset. Se i dispositivi sul bus HT non generano mai pacchetti illegali, questo bug non si verifica.


L'unico baco potenzialmente grave del C2 è il 346. Non è possibile sapere cosa è disabilitato (non ho trovato il registro descritto nel manuale) e quindi quanto impatta le prestazioni. Ma se si evitano i moltiplicatori pari, è possibile che tale workaround non debba essere applicato.

[capitan_crasy]

Ho ricevuto la risposta da bjt2 sul documento Revision Guide for AMD Family 10h dove è incluso lo step C2 delle CPU core Deneb e Shanghai:

Originariamente inviato da bjt2

La buona notizia è tutti i vecchi bachi fino al B3 sono stati corretti. Il terribile 298, il 309, i bachi sulla divisione, sulle funzioni stringa, sull'accesso in memoria con dati non allineati e molto importante per l'OC, l'instabilità con DIMM 1066 (355 e 370)...

Il C2 ha dei bachi che non hanno le precedenti revisioni.

327: violazione di resistenza elettrica sull'HT con nessuna conseguenza.

339: leggero ritardo tra 35 e 90 ns in stato attivo e fino a 640 ns in risparmio energetico (C1E) del riazzeramento del timer APIC. Per la precisione che ha questo timer il ritardo è non significativo. Errore poco grave, tanto più che si verifica solo quando il timer è arivato a fine corsa e deve riazzerarsi.

342: baco grave per la virtualizzazione. In determinati casi il guest può girare con le interrupt disabilitate rischiando che l'hypervisor perda la possibilità di riprendere il controllo. Se in quell'intervallo in cui le interrupt sono disabilitate il SO guest si blocca l'hypervisor non riuscirà più a riprendere il controllo.

343: se il BIOS usa la cache L2 come memoria tampone prima di inizializzare il controller RAM, dei dati possono essere invalidati. Il BIOS deve disabilitare qualcosa della L2 prima di usarla e riabilitarla quando ha finito. Bug non grave.

346: se un core ha frequenza maggiore del NB e se un altro core ha una frequenza minore del NB ma ottenibile da una divisione pari (2,4,6,8 ecc...) il processore potrebbe non essere in grado di fare un cache probe e bloccarsi. La soluzione è disabilitare qualcosa, ma non sono riuscito a trovare il registro nella guida e non so cosa si disabilita. Potrebbe impattare le prestazioni ma non è possibile determinarlo.

348: la resistenza di terminazione ha valore maggiore delle specifiche. Questo potrebbe ridurre i margini delle memorie e potenzialmente ridurre l'OC.

350: durante un cold reset la RAM può fallire l'inizializzazione. E' specificata una procedura per evitare che ciò accada. Questo non ha impatto sulle prestazioni. Bug lieve.

351: lo stato di riposo LS2 dell'HT non funziona correttamente. Bisogna usare LS1. Dovrebbe comportare solo un minore risparmio energetico.

352 353: SYSCALL e SYSRET eseguite incorrettamente se c'è un breakpoint. Questo baco affligge solo idebugger del kernel. E' specificato come evitare il problema. Non interesa l'uso normale del sistema.

359: la CPU ritarda di 200 microsecondi l'inizio del clock alla memoria. Non è stato rilevato alcun malfunzionamento, ma se qualche DIMM è sensibile a questo ci potrebbero essere problemi al BOOT.

360: prossibile riduzione dei margini della memoria se i registri di intensità dei PIN della RAM sono diversi tra loro e diversi dai valori raccomandati. Problemi si possono verificare solo con timing 1T. Nessun problema con timing 2T. Quindi questo significa che se le DIMM non sono identiche potrebbe essere necessario impostare timing 2T per avere più margine sulla memoria (per esempio in OC).

361: in un caso particolare potrebbe perdersi un breakpoint di una istruzione in un sistema guest. Bug veniale, che inderessa solo il debugging di applicazioni in macchine virtuali.

362: la CPU può bloccarsi sul warm reset se durante esso riceve dei pacchetti illegali sui link HT non coerenti. Non influisce sul cold reset. Se i dispositivi sul bus HT non generano mai pacchetti illegali, questo bug non si verifica.


L'unico baco potenzialmente grave del C2 è il 346. Non è possibile sapere cosa è disabilitato (non ho trovato il registro descritto nel manuale) e quindi quanto impatta le prestazioni. Ma se si evitano i moltiplicatori pari, è possibile che tale workaround non debba essere applicato.

Ringrazio bjt2 per la sua gentilezza e disponibilità!!!

[G-UNIT91]

Originariamente inviato da bjt2

La buona notizia è tutti i vecchi bachi fino al B3 sono stati corretti. Il terribile 298, il 309, i bachi sulla divisione, sulle funzioni stringa, sull'accesso in memoria con dati non allineati e molto importante per l'OC, l'instabilità con DIMM 1066 (355 e 370)...

Il C2 ha dei bachi che non hanno le precedenti revisioni.

327: violazione di resistenza elettrica sull'HT con nessuna conseguenza.

339: leggero ritardo tra 35 e 90 ns in stato attivo e fino a 640 ns in risparmio energetico (C1E) del riazzeramento del timer APIC. Per la precisione che ha questo timer il ritardo è non significativo. Errore poco grave, tanto più che si verifica solo quando il timer è arivato a fine corsa e deve riazzerarsi.

342: baco grave per la virtualizzazione. In determinati casi il guest può girare con le interrupt disabilitate rischiando che l'hypervisor perda la possibilità di riprendere il controllo. Se in quell'intervallo in cui le interrupt sono disabilitate il SO guest si blocca l'hypervisor non riuscirà più a riprendere il controllo.

343: se il BIOS usa la cache L2 come memoria tampone prima di inizializzare il controller RAM, dei dati possono essere invalidati. Il BIOS deve disabilitare qualcosa della L2 prima di usarla e riabilitarla quando ha finito. Bug non grave.

346: se un core ha frequenza maggiore del NB e se un altro core ha una frequenza minore del NB ma ottenibile da una divisione pari (2,4,6,8 ecc...) il processore potrebbe non essere in grado di fare un cache probe e bloccarsi. La soluzione è disabilitare qualcosa, ma non sono riuscito a trovare il registro nella guida e non so cosa si disabilita. Potrebbe impattare le prestazioni ma non è possibile determinarlo.

348: la resistenza di terminazione ha valore maggiore delle specifiche. Questo potrebbe ridurre i margini delle memorie e potenzialmente ridurre l'OC.

350: durante un cold reset la RAM può fallire l'inizializzazione. E' specificata una procedura per evitare che ciò accada. Questo non ha impatto sulle prestazioni. Bug lieve.

351: lo stato di riposo LS2 dell'HT non funziona correttamente. Bisogna usare LS1. Dovrebbe comportare solo un minore risparmio energetico.

352 353: SYSCALL e SYSRET eseguite incorrettamente se c'è un breakpoint. Questo baco affligge solo idebugger del kernel. E' specificato come evitare il problema. Non interesa l'uso normale del sistema.

359: la CPU ritarda di 200 microsecondi l'inizio del clock alla memoria. Non è stato rilevato alcun malfunzionamento, ma se qualche DIMM è sensibile a questo ci potrebbero essere problemi al BOOT.

360: prossibile riduzione dei margini della memoria se i registri di intensità dei PIN della RAM sono diversi tra loro e diversi dai valori raccomandati. Problemi si possono verificare solo con timing 1T. Nessun problema con timing 2T. Quindi questo significa che se le DIMM non sono identiche potrebbe essere necessario impostare timing 2T per avere più margine sulla memoria (per esempio in OC).

361: in un caso particolare potrebbe perdersi un breakpoint di una istruzione in un sistema guest. Bug veniale, che inderessa solo il debugging di applicazioni in macchine virtuali.

362: la CPU può bloccarsi sul warm reset se durante esso riceve dei pacchetti illegali sui link HT non coerenti. Non influisce sul cold reset. Se i dispositivi sul bus HT non generano mai pacchetti illegali, questo bug non si verifica.


L'unico baco potenzialmente grave del C2 è il 346. Non è possibile sapere cosa è disabilitato (non ho trovato il registro descritto nel manuale) e quindi quanto impatta le prestazioni. Ma se si evitano i moltiplicatori pari, è possibile che tale workaround non debba essere applicato.

quindi c'è da essere ottimisti?

[astroimager]

Originariamente inviato da Ratatosk

Infatti dipende dalla posizione dei die opteron sul singolo wafer

Ora mi viene in mente... se la linea Shanghai/Deneb è unica, siete sicuri che i Deneb AM2+ saranno migliori di una linea dedicata AM3?

Io inizialmente pensavo di sì... però, a pensarci bene potrebbe essere il contrario!
Non è che riservano la regione centrale a Shanghai e la rimanente corona circolare, di qualità mediamente peggiore, va a Deneb?

[capitan_crasy]

Originariamente inviato da G-UNIT91

quindi c'è da essere ottimisti?

Direi proprio di si...

Originariamente inviato da astroimager

Ora mi viene in mente... se la linea Shanghai/Deneb è unica, siete sicuri che i Deneb AM2+ saranno migliori di una linea dedicata AM3?

Io inizialmente pensavo di sì... però, a pensarci bene potrebbe essere il contrario!
Non è che riservano la regione centrale a Shanghai e la rimanente corona circolare, di qualità mediamente peggiore, va a Deneb?

Di solito le linee produttive Opteron/CPU desktop sono diversi, in questo modo non ci sarà problemi di produzioni o di disponibilità.
Nel caso del Deneb AM2+ utilizzando la linea produttiva degli Opteron AMD non deve creare una linea dedicata per poi interromperla dopo pochi mesi...

[bjt2]

Originariamente inviato da G-UNIT91

quindi c'è da essere ottimisti?

Tutti i bachi del B3 sono stati risolti. I bachi del C2 che non ci sono nelle versioni precedenti sono quelli che ho scritto sopra. Di tutti il più grave è il 346, ma non lo è poi tanto. Ipotizzo che quel bit che consiglia AMD di mettere a 1 serva per assicurarsi che il divisore del clock della CPU sia dispari. Questo comporta che quando un core va in risparmio energetico abbia un clock divisibile per un numero dispari. Se il workaround fa solo questo (come è probabile) le conseguenze sono assolutamente insignificanti: al massimo consumerà qualche watt in più la CPU in IDLE. In ogni caso AMD ha pianificato di risolvere questo e la maggior parte dei bachi elencati sopra...

[Revenge81]

Originariamente inviato da ozlacs

veramente ancora oggi i chip delle vga sono BGA, così come i chipset, o le cpu dei notebook (quelle saldate), gli Atom, e tutti i chip simili

io ricordo ke è da un pò ke nn si usa sulle schede video, il bga non lo sento + da anni....ormai è quasi sempre associato a prodotti economici(non ricorso quello, più costoso, che lo sostituì nella fascia alta..)

[astroimager]

Originariamente inviato da capitan_crasy

Di solito le linee produttive Opteron/CPU desktop sono diversi, in questo modo non ci sarà problemi di produzioni o di disponibilità.
Nel caso del Deneb AM2+ utilizzando la linea produttiva degli Opteron AMD non deve creare una linea dedicata per poi interromperla dopo pochi mesi...

I vantaggi strategici sono più che ovvi.

Io guardavo il lato "consumatore": non vorrei essere brutale, ma non è che con i Deneb AM2+ ci rifilano i die peggiori di ogni wafer, riservando i migliori, come è giusto che sia, alle CPU server?

E' solamente un'ipotesi, non so come avviene fattivamente la produzione, e non sono a conoscenza di come degradi la qualità dal centro ai bordi con la nuova litografia...

[astroimager]

Originariamente inviato da bjt2

Tutti i bachi del B3 sono stati risolti. I bachi del C2 che non ci sono nelle versioni precedenti sono quelli che ho scritto sopra. Di tutti il più grave è il 346, ma non lo è poi tanto. Ipotizzo che quel bit che consiglia AMD di mettere a 1 serva per assicurarsi che il divisore del clock della CPU sia dispari. Questo comporta che quando un core va in risparmio energetico abbia un clock divisibile per un numero dispari. Se il workaround fa solo questo (come è probabile) le conseguenze sono assolutamente insignificanti: al massimo consumerà qualche watt in più la CPU in IDLE. In ogni caso AMD ha pianificato di risolvere questo e la maggior parte dei bachi elencati sopra...

Bene... quindi c'è da aspettarsi che il C3 consumi ancora meno in idle non solo per eventuali miglioramenti di silicio...

Il 342 per la virtualizzazione quanto è grave?


PS A proposito, lo step C3 quando dovrebbe uscire? Con il package AM3 (Q1 2009)? Dopo si passa direttamente alla rev. D, o è previsto un C4?

[ozlacs]

Originariamente inviato da astroimager

I vantaggi strategici sono più che ovvi.

Io guardavo il lato "consumatore": non vorrei essere brutale, ma non è che con i Deneb AM2+ ci rifilano i die peggiori di ogni wafer, riservando i migliori, come è giusto che sia, alle CPU server?

E' solamente un'ipotesi, non so come avviene fattivamente la produzione, e non sono a conoscenza di come degradi la qualità dal centro ai bordi con la nuova litografia...

veramente è sempre stato così, è cosa risaputa.
al tempo degli Athlon 64 gli utenti enthusiastari preferivano gli Opteron proprio per questo, per il silicio migliore, che dava maggiori margini di oc.
al tempo, moltiplicatore sbloccato a parte, gli Opteron erano gli Fx dei poveri

[capitan_crasy]

Originariamente inviato da astroimager

I vantaggi strategici sono più che ovvi.

Io guardavo il lato "consumatore": non vorrei essere brutale, ma non è che con i Deneb AM2+ ci rifilano i die peggiori di ogni wafer, riservando i migliori, come è giusto che sia, alle CPU server?

E' solamente un'ipotesi, non so come avviene fattivamente la produzione, e non sono a conoscenza di come degradi la qualità dal centro ai bordi con la nuova litografia...

Diciamo che AMD sceglie quelli che non passano i severissimi test per le CPU Opteron...

Originariamente inviato da ozlacs

veramente è sempre stato così, è cosa risaputa.
al tempo degli Athlon 64 gli utenti enthusiastari preferivano gli Opteron proprio per questo, per il silicio migliore, che dava maggiori margini di oc.
al tempo, moltiplicatore sbloccato a parte, gli Opteron erano gli Fx dei poveri

é proprio l'opposto...
La serie FX erano gli "scarti" della serie Opteron...

[capitan_crasy]

Originariamente inviato da astroimager

Bene... quindi c'è da aspettarsi che il C3 consumi ancora meno in idle non solo per eventuali miglioramenti di silicio...

Il 342 per la virtualizzazione quanto è grave?


PS A proposito, lo step C3 quando dovrebbe uscire? Con il package AM3 (Q1 2009)? Dopo si passa direttamente alla rev. D, o è previsto un C4?

Lo step C3 dovrebbe essere utilizzato per le CPU socket AM3...
L'uscita nel primo trimestre 2009 delle CPU AM3 fa pensare ad un nuovo step ( unicamente pensato per affinare il controller RAM DDR3 ); altrimenti non si spiega perchè AMD dovrebbe presentare prima CPU Deneb socket AM2+ e poi CPU Deneb socket AM3...
Lo step D dovrebbe essere utilizzato per le CPU core Istanbul...

[carpo93]

se io prendessi una mobo am2+ con supporto am3 potrei montarci il processore con 6core?

[astroimager]

Originariamente inviato da ozlacs

veramente è sempre stato così, è cosa risaputa.
al tempo degli Athlon 64 gli utenti enthusiastari preferivano gli Opteron proprio per questo, per il silicio migliore, che dava maggiori margini di oc.
al tempo, moltiplicatore sbloccato a parte, gli Opteron erano gli Fx dei poveri

Ok, questo lo so e l'ho capito bene...

Quello che non ho compreso è: due o più linee di produzione diverse usano lo stesso wafer, se l'architettura è identica?

Il discorso è questo: per i Deneb AM2+ usano lo stesso wafer degli Opteron... quindi gli Opteron sono mediamente migliori. Ok.

Quando apriranno la nuova linea per gli AM3, pescheranno i die sempre dallo stesso wafer o li prenderanno da un wafer dedicato? In quest'ultimo caso, ci sarebbe una bella differenza, perché tutti i die andrebbero a Phenom e quindi fra gli AM3 ci sarebbe maggiore probabilità di beccare CPU buone!

A meno che i die centrali del "wafer AM3" non li dedicheranno comunque agli Opteron disabilitando il ctrl DDR3. In questo caso, la differenza fra CPU AM2+ e AM3 sarebbe nulla, sotto questo aspetto...

[bjt2]

Originariamente inviato da astroimager

Bene... quindi c'è da aspettarsi che il C3 consumi ancora meno in idle non solo per eventuali miglioramenti di silicio...

Il 342 per la virtualizzazione quanto è grave?


PS A proposito, lo step C3 quando dovrebbe uscire? Con il package AM3 (Q1 2009)? Dopo si passa direttamente alla rev. D, o è previsto un C4?

E' grave nel senso che costringe i produttori come VMWare ad applicare il workaround per i Deneb e agli utenti a scaricarsi la versione aggiornata. Non ho approfondito se il workaround fa perdere in prestazioni o no.

Nel C3 saranno più i W risparmiati per il silicio che per il baco detto sopra...

[ozlacs]

Originariamente inviato da capitan_crasy

Diciamo che AMD sceglie quelli che non passano i severissimi test per le CPU Opteron...




é proprio l'opposto...
La serie FX erano gli "scarti" della serie Opteron...

non per il prezzo, a quello mi riferivo
ok che gli FX erano gli scarti degli Opteron, ma pur sempre entrambi con silicio mediamente migliore delle normali CPU desktop, solo che gli FX costavano un botto rispetto agli Opteron serie 1xx, che ebbero enrome diffusione tra gli overclocker