[capitan_crasy]

Originariamente inviato da Wing_Zero

ALLORA qua le cose stanno sfuggendo di mano a tutti, neanche la redazione di HWU ci capisce piu' nulla!!!

Leggete cosa scrive Corsini al termine della recensione del PHENOM:


Poi oggi esce la news dicendo che senza il fix i phenom guadagnano in prestazioni anche un 20% e che lo faranno disabilitare dall'overdrive.
Ecco un estratto dalla news di oggi:


SE DURANTE LA RECENSIONE DI HWU il fix nn c'era proprio...NON SERVE NEANCHE RITESTARE I PROCESSORI !

Quindi, senza che ci creiamo tutto sto hype per la versione B3...le prestazioni dei phenom sono quelle viste con HWU. Punto.

STRAdannazione vogliamo leggere i post per costesia?

Originariamente inviato da capitan_crasy

Presa dalla recensione della Sapphire Pure CrossfireX 790FX fatta dal buon Corsini:

Resta da capire che tipo d'interesse potranno generare le nuove schede madri Socket AM2+ di fascia alta soprattutto tra il pubblico degli utenti più appassionati, viste le prestazioni delle cpu Phenom non allineate a quelle delle proposte concorrenti di Intel e i problemi prestazionali legati al bug delle TLB della cache L3 corretto con un update del bios a prezzo di un notevole impatto prestazionale. Un ruolo importante in questo potrà essere svolto dalla piattaforma Spider nel suo complesso, e soprattutto dai livelli di prezzo ai quali i partner AMD saranno in grado di fornire queste soluzioni, soprattutto nel momento in cui AMD immetterà in commercio processori Phenom basati sulla nuova revision B3 e quindi sprovvisti del bug.

Originariamente inviato da 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...

Descrizione del Bug denominato "Erratum 298":

"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...

Originariamente inviato da bjt2

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...

Originariamente inviato da 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...

Domanda di MonsterMash:

Io non capisco...
Tutti i test visti fino ad oggi non avevano castrazione da parte del bios, eppure erano deludenti. L'introduzione del workaround (per chi vorrà usarlo) abbasserà ulteriormente le prestazioni.
Lo step b3 renderà semplicemente non necessario l'uso del workaround, ma non vedo proprio perchè dovrebbe andare meglio del b2. A meno che non introduca anche ottimizzazioni di altro genere (ma ne dubito molto fortemente, perchè queste non sono cose che si fanno tra uno step e un altro...).

Originariamente inviato da bjt2

Perchè lo step B2 ha altri due bug scoperti PRIMA di settembre, data a cui risale il documento contenente gli errata e che NON CONTIENE il bug 298, scoperto, sembra, a metà novembre, che si corregge ora. Io supposi, e lo suppongo ancora, che i BIOS attuali correggano quei due bug di settembre, che comunque sono gravi. Questo è un bug aggiuntivo e AMD ha colto la palla al balzo per unificare i 3 bug, dal punto di vista mediatico... Quindi lo step B3 correggerà tutti i bugs gravi, e non ci sarà più bisogno di quei workaround...

P.S.: AMD ha specificato di NON mettere nel BIOS l'opzione per disabilitare il workaround, perchè lo farà della utility OverDrive...