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

[esticbo]

Cose importanti dette da Tony:

Originariamente inviato da Tony

K10 was not designed to run massive HTT speeds, it was designed to be super efficient at lower HTT but with high CPU NB clock speed....so we all need the 9600BE (Black Edition) as this will have an unlocked CPU multi...so no need to push massive HTT, although upto 300 would be nice

Originariamente inviato da Tony

KTE...i had to lose the K10 for a while, it was frustrating the tits off me

max HTT was 240, max NB clock 1940 ish, DFI bios...some issues

Working with a 6400+ now and having some fun for a couple of hrs

etc etc...

Sembra ke queste mobo AM2+ x il momento vanno benissimo x i AM2 invece ke x i Phenom.

Una cosa ke avevo letto ke mi aveva lasciato un po' basito é ke un forero (nn ricordo ki) aveva detto ke le mobo nvidia AM2 riuscivano a tener testa alle mobo AM2+ della Gigabyte, supponendo ke il pcb di quest'ultime fosse disegnato male ; volete vedere ke adesso devono ristudiare sia bios ke mobo!!!

[paolo.oliva2]

Originariamente inviato da DoctorZ

si in effetti è strana la cosa, il perchè vanno così male intendo.
Io per fortuna cado a pennello perchè mi ero prefisso di fare l'upgrade a marzo
quindi teoricamente dovrei fare in tempo a vedere un po' di bench del 9900

però ricordate che qualche post fa qualcuno fece un ottimo discorso sulle diversità di implementazione, e relativi benchmarks, fatti su sistemi windows e linux. Su Linux sti phenom rullano come si deve, quindi c'è da ragionarci molto attentamente su quest'aspetto. Il mio sentore, è di poter confidare nella prossima cpu 9900. La cosa che non mi spiego è il tempo che ci hanno messo per sfornare sti proci.. e in un anno e passa non si sono accorti che queste cpu, che rullano come si deve su linux, quindi il potenziale all'atto pratico lo hanno, c'è, esiste.. non fanno lo stesso su sistemi windows?
caxxo ragazzi, io a ste cose non ci credo. In AMD, in Intel, che ci piaccia o no, che li critichiamo oppure no, ci lavorano ingegneri che hanno sotto due coglioni così..! Non sono fessi. A me i commenti del tipo "in AMD sono dei babbi, lavorano col culo.. ecc.. ecc.." mi fanno ridere. Sono d'accordo che a sto giro i conti non tornano.. ma imho hanno avuto i loro motivi, difficili da spiegare.. ma comunque non certo perchè non se ne sono accorti o chissà perchè. Giusto per fare un esempio, tenete presente che AMD negli ultimi anni ha incrementato notevolmente le partnership con i collossi come HP, Fujitsu S., Acer... ste cpu saranno tra qualche mese lo standard all'interno dei preassemblati.. e siccome i colossi sopra citati hanno raggiunto volumi di vendita negli ultimi anni spaventosi (e ci lavoro fidatevi) ed in aggiunta ste cpu hanno un costo abbortabile, il privato che compra il modello HP M9899 col suo bel phenom col bug se ne sbatte le balle perchè non segue perforza di cose hwupgrade e sta a scannarsi come noi dalla mattina alla sera su pregi e difetti delle cpu. Date retta a un fesso.. imho amd ha previsioni di vendita da qui al 2020 e si saranno fatti bene i loro conti e sanno che possono permettersi ciò che sta accadendo. Tutto ciò è un'opinione personale.

Condivido... e l'unica cosa che potrebbe spiegare questo modus operandi criticabilissimo è l'impossibilità di risolvere a priori il problema. Facciamo un esempio che il Phenom potrebbe essere stato ideato proprio per i 45nm, e che in realtà il B3 non sia una evoluzione del B2 ma bensì il B2 sia una castrazione del B3. Sembra che la maggior parte dei problemi vengano dalla L3 e più in generale sembrerebbe (sempre supposizioni) che manchi una sorta di alimentazione di dati in modo veloce ai core, nonostante sulla carta il transfer sia ben superiore al K8. Per far stare il tutto in un die a 65nm, hanno ridotto la L2 a 512, hanno ridotto la L3 e questo avrebbe portato dei problemi a tutti gli effetti che così come è, andrebbe rivista la logica della L3, non tanto bug ma quanto così non va. Tanto mi sembra impossibile che con tutti i raddoppi di registri e nuove istruzioni alla fine c'è un margine risicato sul K8. Intendiamoci, io non sto difendendo AMD o trovando scuse tipo il Phenom sarà più veloce del Nehalem, ma il K8 parte già su buone basi, ha una logica innata per il multi-core, non hanno fatto altro che raddoppiargli i registri e velocizzare il transfer e teoricamente con il 65 e successivamente 45nm aumentargli la cache e il clock, tutto sulla carta farebbe prevedere faville... ed in realtà è un accrocchio di problemi.
Condivido che i tecnici di AMD e sicuramente anche più di Intel abbiano le palle. Intel ha avuto problemi a suo tempo, perché era arrivata al massimo della potenzialità che poteva dare la "materia", ed hanno cambiato. Non credo che il progetto sia bacato, perché la base è il K8 che tutto è tranne che bacato. Boh... ormai si va solo di fantasia.

[khael]

scusate, ma se non errro non era uscita una scheda madre di asus che integrata un raffreddamento a liquido? perchè devo cambiare mobo in futuro...e mi piacerebbe prendere questa!

[astroimager]

Originariamente inviato da marchigiano

azz allora serviranno a dagon sono gli FX!!!!!

ora che ci penso ci sono anche 2 controller ram 64+64bit

A dagon l'UNICA cosa che poteva tirarlo su di morale dopo la bella notizia di AMD che lo riguardava da vicino è proprio una coppia di PhemmineX(XX), altro che Phenom.

Per questa volta i componenti li abbiamo analizzati tutti, moh tocca aspettare Bulldozer...

[capitan_crasy]

Originariamente inviato da billuzzo

Erratum, to those in the hardware or software industry, is a nice way of saying "we missed a test case" during development and design.

Yesterday, The Tech Report confirmed AMD's iteration of Intel's F00F bug. The bug, which has been documented since at least early November, can cause a deadlock during recursive or nested cache writes.

How does the TLB erratum occur? All AMD quad-core processors utilize a shared L3 cache. In instances where the software utilizes nested memory pages, this processor will experience a race condition.

AMD's desktop product marketing manager Michael Saucier describes a race condition as a series of events "where the other guy wins who isn't supposed to win."

In the software world, a typical memory race condition occurs when the memory arbiter is instructed to overwrite a n older block of memory, but write the old block of memory to somewhere else in cache. In the instance where two arbiters follow this same rule set, its easy to see how a race condition can occur: both arbiters attempt to overwrite the same blocks of information, resulting in a deadlock.

From what AMD engineers would tell DailyTech, this example is very similar to what occurs with nested memory pages in virtualized machines on these K10 processors.

AMD has since released a new BIOS patch for all K10 motherboards, including the often cited but rarely seen MSI K9A2 Platinum. This patch, confirmed by DailyTech, will result in at least a 10% reduction in general computing speed.

AMD partners tell DailyTech that all bulk Barcelona shipments have been halted pending application screening based on the customer. Cray, for example, was allowed its latest allocation for machines that will not use these nested virtualization techniques. Other AMD corporate customers were told to use Revision F3 (K8) processors in the meantime.

The TLB erratum will be fixed in the B3 stepping of all AMD quad-core processors, including Phenom and Barcelona. However, AMD considers the B3 stepping a "March" item on its 2008 roadmap. Processors shipped between then and now will still carry the TLB bug, though with the BIOS workaround these machines will not experience a lockup.

The delayed Phenom 9700 is affected by the TLB bug, though AMD insiders tell DailyTech the upcoming 2.6 GHz Phenom 9900 is not affected. This indicates Phenom 9900 will carry the B3-stepping designation.

AMD's latest roadmap hints that its tri-core processors are merely quad-core processors with one core disabled. The company also indicated that it will introduce some of these tri-core processors with the L3 cache disabled. Removing the shared-L3 cache from the chip design eliminates the TLB bug.

In a likely-related event, AMD's newest corporate roadmap scheduled three Phenom processors for the first half of 2008; one of which is the Phenom 9700. The company will launch eleven new 65nm K8 processors in the same time period.



fonte http://www.dailytech.com/Understandi...rticle9915.htm

Grazie per la segnalazione...

[joy69]

Io ho un amico che deve farsi un pc nuovo..meglio un e6750 o un quad phenom?

[peppecbr]

quindi da quello che leggo... nessuno l'ha comprato giusto? io online lo devo disponibile insieme anche alle nuove mobo...

[Errik89]

Originariamente inviato da paolo.oliva2

Condivido... e l'unica cosa che potrebbe spiegare questo modus operandi criticabilissimo è l'impossibilità di risolvere a priori il problema. Facciamo un esempio che il Phenom potrebbe essere stato ideato proprio per i 45nm, e che in realtà il B3 non sia una evoluzione del B2 ma bensì il B2 sia una castrazione del B3. Sembra che la maggior parte dei problemi vengano dalla L3 e più in generale sembrerebbe (sempre supposizioni) che manchi una sorta di alimentazione di dati in modo veloce ai core, nonostante sulla carta il transfer sia ben superiore al K8. Per far stare il tutto in un die a 65nm, hanno ridotto la L2 a 512, hanno ridotto la L3 e questo avrebbe portato dei problemi a tutti gli effetti che così come è, andrebbe rivista la logica della L3, non tanto bug ma quanto così non va. Tanto mi sembra impossibile che con tutti i raddoppi di registri e nuove istruzioni alla fine c'è un margine risicato sul K8. Intendiamoci, io non sto difendendo AMD o trovando scuse tipo il Phenom sarà più veloce del Nehalem, ma il K8 parte già su buone basi, ha una logica innata per il multi-core, non hanno fatto altro che raddoppiargli i registri e velocizzare il transfer e teoricamente con il 65 e successivamente 45nm aumentargli la cache e il clock, tutto sulla carta farebbe prevedere faville... ed in realtà è un accrocchio di problemi.
Condivido che i tecnici di AMD e sicuramente anche più di Intel abbiano le palle. Intel ha avuto problemi a suo tempo, perché era arrivata al massimo della potenzialità che poteva dare la "materia", ed hanno cambiato. Non credo che il progetto sia bacato, perché la base è il K8 che tutto è tranne che bacato. Boh... ormai si va solo di fantasia.

quoto il tuo ragionamento e lo condivido.
Io spero in Phenom vs Nehalem alla pari, se guardate nehalem ha dei tdp assurdamente alti anche a 45nm!!
E poi secondo me basta aumentare la cache a 8mb (4*1mb + 4mb) per avere sostanziali aumenti di prestazioni. B3 spero che comunque già così pareggi almeno conroe e spero risolvano il problema della frequenza dell'nb o comunque vendano le cpu con molti sbloccato per l'overclock...
Speriamo che il nuovo bus QPI di intel non soffra degli stessi problemi, intel di black edition non ne ha mai fatti...

[Wing_Zero]

stavo leggendo questo post, dove si spiega in dettaglio le problematiche dei 2 bug dei phenom...e sono rimasto allibito.

Se fosse cosi', la perdita di prestazioni rispetto al C2Duo sarebbe da imputare a questi 2 bug, che, sono gravissimi.Andiamo per ordine:

1) per quanto riguarda il primo bug, un cache miss nella TLB (che per chi non lo sapesse e' una tabella temporanea frapposta tra le 2 cache che serve per volocizzare la ricerca indirizzando direttamente alla cella del dato passando dalla prima alla 2° cache) sarebbe grave. costringere amd a disabilitare il caching della cache table nella cache normale, comporta una perdita di prestazioni cmq importante.
Tanto piu' quando a causa di un cache miss nella TLB il phenom e' costretto ad accedere alla RAM che , come sapete tutti, e' qualche ordine di grandezza piu' lenta della cache. Se si hanno grandi carichi di lavoro la penalizzazione diventa davvero consistente.

2)per quanto riguarda il secondo bug invece cosa succede:
poiche il bug riguarda una possibile corruzione quando si scrive in memoria una linea parziale di cache, amd cosa fa...Disabilita la scrittura parziale!
Quindi il K10 si trova a dover leggere tutta la linea di cache, per poi effettuare i calcoli e riscriverla tutta.
Questo fatto e' aberrante. Una delle funzioni basilari e piu' utili del caching dei dati e' inutile, e se anche come dice BJT2 questo problema e' mitigato dal Write Combining , si tratta di un errore gravissimo.
Questo fatto nel calcolo con numeri interi e quidni relativamente limitati, comporta delle perdite di prestazioni enormi..spero davvero di sbagliarmi.

Quindi, concludendo, per quel poco che so io di architettura dei processori, con questi 2 bug, combinati ad una cache L3 con latenze troppo alte, rende il sistema di caching dei phenom...vediamo di trovare il termine esatto...come dire....



























UN COMPLETO SKIFO !


Spero che riesca a risolvere subito questi 2 bug, magari con la revision B3, xke' se le cose stanno davvero cosi potrebbero essere determinanti questi 2 bug.
Ciao
Wing

[paolo.oliva2]

Originariamente inviato da Ratatosk

C'è la sezione consigli per gli acquisti per questo genere di domande, comunque ti poni la domanda sbagliata, perché sono due :>

La prima è:
"Voglio un quad?"

La seconda è:
"Meglio un Intel o un AMD, al prezzo che sono disposto a pagare?"

Sul dualcore, io preferirei AMD sia per la piattaforma AM2+ che promette un buon margine di tempo senza doverla cambiare, sia per le ram e sia per il costo cella cpu, un B.Ed. costa poco e sminchia. Per il discorso quadcore, riparliamone a febbraio, con lo step B3 che poi non sarebbe in realtà un B3, in quanto il B3 da come preannunciato da AMD sarebbe quello a 45nm e raddoppio delle cache... occhio e croce.

[Crystal1988]

Io spero nella Z-RAM per i 45nm....

[paolo.oliva2]

Originariamente inviato da Crystal1988

Io spero nella Z-RAM per i 45nm....

pure io.... ma spero che non ti sentano... se fanno altre implementazioni, che stiamo ad aspettare? Lo step B99? Che mettano a posto quello che hanno nel cassetto ora... A me basterebbe anche 2 6400+ in parallelo... senza menate varie

[capitan_crasy]

AMD rilascia una patch per il sistema operativo "Red Hat Enterprise Linux" che risolverebbe il bug "TLB" senza l'utilizzo del bios "castrante".
Secondo il sito "The Tech Report" grazie a questa patch le prestazioni sarebbero penalizzate solamente del 1%, contro il 10/20% causato dalla correzione del bios:

Unlike AMD's BIOS fix and microcode update, which we've heard induces a 10-20% performance hit, the Linux patch was said to reduce performance by less than 1%. However, we were also told that customers would need to sign a non-disclosure agreement in order to obtain it.

AMD però sconsiglia su tutta la linea di utilizzare questa Patch:

Due to the very invasive nature of this patch and the very small number of affected customers (you know it if you have an affected part), we do not recommend the use of this patch on a regular Linux system. This patch is NOT intended for mainline acceptance or inclusion with a Linux distribution! The patch has only received minimal functional testing. Every user must evaluate it prior to production use to make sure it meets the necessary quality standards.

Ecco la descrizione del Bug denominato "Erratum 298":
( questo è per bjt2 )

"The processor operation to change the accessed or dirty bits of a page translation table entry in the L2 from 0b to 1b may not be atomic. A small window of time exists where other cached operations may cause the stale page translation table entry to be installed in the L3 before the modified copy is returned to the L2. In addition, if a probe for this cache line occurs during this window of time, the processor may not set the accessed or dirty bit and may corrupt data for an unrelated cached operation. The system may experience a machine check event reporting an L3 protocol error has occurred. In this case, the MC4 status register (MSR 0000_0410) will be equal to B2000000_000B0C0F or BA000000_000B0C0F. The MC4 address register (MSR 0000_0412) will be equal to 26h."

Per maggiori informazioni Clicca qui...

[dagon1978]

quindi è ufficialmente un terzo bug e si può sperare che invece fossero gli altri 2 a castrare le prestazioni del phenom? (dalla rece di hwupgrade basterebbe un 5/6% per arrivare al kentsfield... ma forse meno perché sembra che i phenom scalino leggermente meglio in frequenza)

[bjt2]

Originariamente inviato da blindwrite

credi veramente che ad ogni infornata amd cambi maschera per produrre i suoi processori?
io lo vedo come un enorme spreco di denaro... però magari io non sono a conoscenza di nuove tecniche che permettano di modificare i circuiti senza rifare le maschere (che sono le cose più costose del processo produttivo)???

Si tratta di semplice tuning del processo: modifiche a intensità e durata di esposizione a luce UV, modifica concentrazione solventi, aggiunta/modifica/spostamento di passi... Non è che il processo è progettato a tavolino ed è già perfetto... E poi modificando la distanza è possibile, a parità di maschera, ridurre leggermente le dimesioni. Solo che bisogna essere ad uno stadio già buono per poter tentare questa carta senza far schizzare gli scarti... In AMD dicevano che gli ultimi 90nm erano quasi come i primi 65nm (in realtà sembra meglio, tanto è vero che le top gamma sono ancora prodotte a 90nm)...

[bjt2]

Originariamente inviato da capitan_crasy

AMD rilascia una patch per il sistema operativo "Red Hat Enterprise Linux" che risolverebbe il bug "TLB" senza l'utilizzo del bios "castrante".
Secondo il sito "The Tech Report" grazie a questa patch le prestazioni sarebbero penalizzate solamente del 1%, contro il 10/20% causato dalla correzione del bios:

Unlike AMD's BIOS fix and microcode update, which we've heard induces a 10-20% performance hit, the Linux patch was said to reduce performance by less than 1%. However, we were also told that customers would need to sign a non-disclosure agreement in order to obtain it.

AMD però sconsiglia su tutta la linea di utilizzare questa Patch:

Due to the very invasive nature of this patch and the very small number of affected customers (you know it if you have an affected part), we do not recommend the use of this patch on a regular Linux system. This patch is NOT intended for mainline acceptance or inclusion with a Linux distribution! The patch has only received minimal functional testing. Every user must evaluate it prior to production use to make sure it meets the necessary quality standards.

Ecco la descrizione del Bug denominato "Erratum 298":
( questo è per bjt2 )

"The processor operation to change the accessed or dirty bits of a page translation table entry in the L2 from 0b to 1b may not be atomic. A small window of time exists where other cached operations may cause the stale page translation table entry to be installed in the L3 before the modified copy is returned to the L2. In addition, if a probe for this cache line occurs during this window of time, the processor may not set the accessed or dirty bit and may corrupt data for an unrelated cached operation. The system may experience a machine check event reporting an L3 protocol error has occurred. In this case, the MC4 status register (MSR 0000_0410) will be equal to B2000000_000B0C0F or BA000000_000B0C0F. The MC4 address register (MSR 0000_0412) will be equal to 26h."

Per maggiori informazioni Clicca qui...

Allora... Traduzione all buona...
Quando un processo deve scrivere una qualsiasi locazione di memoria, la CPU va a settare un bit nella page table entry corrispondente per dire che in quella pagina almeno un byte è stato modificato, così che se il SO deve buttarla fuori nel file di swap, la deve prima scrivere fisicamente su disco. Se nulla è stato modificato, può semplicemente sovrascriverla. Poi c'è anche il bit di accesso che dice se una pagina è stata acceduta di recente e serve per decidere se deve essere scartata, quindi è modificato ad ogni accesso anche in lettura. Teoricamente questa operazione dovrebbe essere atomica. Invece solo per la TLB di secondo livello, se avviene un altro accesso in memoria che richiede una nuova entry TLB nella TLB di livello 2, una entry deve essere buttata fuori e scritta in cache L3. Se la entry che deve essere buttata fuori è proprio quella appena modificata, può darsi che venga scritta la versione vecchia e non la nuova, corretta! Questo è in sintesi il baco.
La cosa importante è che il fix è almeno la disabilitazione del caching delle TLB, cosa che già è richiesta per uno dei due bachi noti a settembre. Se questa cosa è sufficiente, allora vuol dire che le BIOS attuali non contengono ancora il workaround per almeno uno dei due bugs di Settembre che ho menzionato, perchè in AMD dicono che ci vuole un aggiornamento, ergo le BIOS attuali ancora non lo contengono. Se il workaround non è solo questo, allora è possibile che i bugs di settembre siano stati corretti, ma comunque indipendentemente da questi è necessario un nuovo workaround aggiuntivo e comunque l'unico modo per sapere se i due bugs di settembre sono già corretti è chiedere ai produttori di MB (vero CORSINI?!?! )...

A questo punto io credo che nessun produttore di MB abbia ancora implementato nessuno dei workaround e questo calo del 10/20% è da attribuire ai workaround per tutti e tre i bugs e AMD tramite un'abile mossa di marketing sta facendo credere che il bug sia uno solo, anche perchè i non tecnici non se ne fregano se sono uno o 100... Sanno solo che ci sono...

[bjt2]

Ho letto il proseguio del link passatomi dal capitano...

In pratica se i bit accessed e dirty non venissero toccati, il bug non si verificherebbe. La patch opera emulando i bit A e D in software: al primo accesso o alla prima scrittura viene generato un page fault e i bit A e D simulati vengono memorizzati dal SO (e non dalla CPU in automatico) in altri bit liberi della page table entry. Quindi c'è un calo di prestazioni perchè è come se i bit li dovesse scrivere il SO e non la CPU in hardware, ma è contenuto perchè deve essere fatto solo per il primo accesso in lettura o il primo accesso in scrittura... ma invece di farlo la CPU al volo, deve essere chiamata una routine del SO, quindi invece di 1-2 cicli di clock, ce ne vogliono qualche decina (forse anche un centinaio)... Ma solo per il primo accesso in lettura e uno in scrittura. Poichè il biti di accesso è azzerato periodicamente e quello Dirty è azzerato quando la pagina è scritta fisicamente su disco, ogni tanto qualche pagina sperimenta questo overhead... Si spera una volta ogni qualche secondo...

[Scrambler77]

Originariamente inviato da dagon1978

allo stesso prezzo (anzi leggermente meno) dell'e6550 oggi trovi il 6000+, che, carta alla mano, va di più, quindi?

hai ragione... va di più dello 0,03%

...ma costa 4 euro di più. Quando vuoi sai essere preciso.

[capitan_crasy]

The Tech Report ha testato un Phenom 9600 con una MSI K9A2-PLATINUM e Bios di vecchia data (versione VP.0B7), esso dovrebbe essere esente dalla correzione del "TLB".
Ecco il riassunto dei risultati:



Per maggiori informazioni Clicca qui...

[viscm]

Originariamente inviato da Scrambler77

hai ragione... va di più dello 0,03%

...ma costa 4 euro di più. Quando vuoi sai essere preciso.

Beh veramente i prezzi che ho trovato (in un noto shop online) sono molto + bassi 138€ x il 6000+ e 142€ x il e6550.

Cmq il discorso nn riguarda solo le cpu e visto che reputo la maggior parte delle persone che sono in questo forum competenti, penso che tu ,come altri, venga qui apposta x flammare.

Prendendo solo le schede madri. la nuova top di gamma (con 2 slot pci-e , quella con 4 nn ha equivalente x intel) con il 790x costa 80-84€ , quanto costa una scheda con le stesse prestazioni x Intel? e le memorie?

Chiudo questo OT aprendone un altro.
Ho letto nei post precedenti che alcuni avevano difficoltà a legger l'inglese usato nei forum, provate ad usare questo vocabolario online:
http://www.urbandictionary.com/
io mi ci sono trovato veramente bene x tradurre i fumetti , magari vi potrà essere utile.

Per ritornare IT

Domanda x gli esperti , ma l'workaround dei primi due bug deve essere x forza inserito nei bios delle schede madri o può essere 'inserito' nella cpu con l'aggiornamento del microcode o qualcosa del genere?