|
Advice Beginners BIOS Guide CPUs Links Mainboards Memory Network Storage Video/Sound Cards Contact Forum SiteMap Sponsors WebNews Home |
. | . |
Prices: Mainboards ABIT ASUS Chaintech Shuttle Soyo Tyan CPU Intel P4 2.4C-800 P4 2.6C-800 P4 2.8C-800 P4 3.0-800 P4 3.2-800 AMD AthlonXP XP 1700+ XP 2000+ XP 2400+ XP 2500+ XP 2700+ XP 3000+ XP 3200+ Athlon64 Athlon64 3200+ Athlon64 FX-51 Opteron Opteron 240 Opteron 242 Opteron 244 Opteron 246 Memory Corsair Crucial Kingston Mushkin OCZ |
|
|
|
LOSTCIRCUITS
|
|
| AMD's Phenom X4 9850 - Silicon Revision B3 | |
|
(Author: Michael Schuette, April 6, 2008) |
Summary
The latest re-spin of AMD's multicore die fixes the bug known from Erratum 298 and opens up a bit of overclocking headroom. Gone is also the requirement for a BIOS fix causing the known performance hit. To make things even more appealing, running in native performance mode actually unleashes better performance in memory-intensive applications than what AMD Overdrive ever brought back after the patch. All in all, AMD seems to be on the right track with the latest -50 series.
B3-Revision Silicon
Sometimes good things still happen, even in the computer industry. Last week's good thing was AMD’s release of the -50 series of Phenom processor to finally catch up with reality. The new -50 series is based exclusively on the B3 silicon which does not appear to be prone anymore to wrong TLB entries in situations where virtualization is used or else other memory intensive applications are vying for the same picosecond to update the buffer with the appropriate virtual memory address to generate the correct physical address on demand. So, what is fixed here is essentially the timing, the new TLBs may be faster or else the resolution granularity has increased. Whatever was done seems to work, officially the bug is gone. For the time being at least – granted that it ever even existed to the point where it was really a problem.
The new -50 series of Phenom featuring Quad (X4) and Triple (X3) cores
The 3 Months of Phenom: A Retrospect
Without trying to flog a dead horse,the original launch of AMD’s Phenom last year was a mishap of gargantuan dimensions, with the preamble of a terrible PR event, followed by even worse kneejerk reactions on the corporate / liability side of AMD, forcing everybody to put up with BIOS versions that contained a work-around for the TLB-bug described in Erratum 298. We have used the affected Phenom 9900 and 9600 BE for approximately 3 months now on a day-to-day basis and it does appear time and appropriate to provide a bit more feedback on what the but does and what the workaround does, not in terms of flagging memory pages but in terms of what the consequences are for the users. Ever heard the expression “Putting out fire with gasoline”? Or “the cure is worse than the disease”? This seems to be a fairly accurate description of the BIOS workaround for the TLB bug. Without using AMD OverDrive or with AOD set to “green” mode, there are numerous applications that will repeatedly and reproducibly crash within a few minutes. Case in point: UT3 when running in conjunction with any other multithreaded application. Curiously, with AOD set to “red” mode, no such crashes ever occur.
Why?
At first glance this seems to be a conundrum but at second thought, it actually does make sense. The BIOS fix prevents mis-entries into the TLBs by treating all memory pages as if the data were accessed and modified, regardless of whether any of this ever happened as, for example in a simple read (e.g. instruction or streaming data) operation, the instruction or source will not be modified. However, because of corporate paranoia every bit of data will have to be written back from the cache to the memory page as if they had been changed and that is where bus contention (in streaming applications), and increased load on the memory controller and memory will add the known increase in latency. If that wasn’t enough, running an application in a mode it was never intended to be run in will cause some problems. The bottom line here is that what we have witnessed is an indoctrination of safety measures that turn an error occurring in 1 in 50 million cases into something that can crash a system every single time more than one multithreaded application is launched. Congratulations, we hand another Darwin Award to AMD.
AMD OverDrive: The Deus Ex Machina
Fortunately in real life, the situation is not that bad since AMD OverDrive or AOD disables the BIOS fix on the level of the OS. Or does it? In a way yes … but … A persistently surfacing rumor has been that AOD is essentially a band aid for the wrist slash and this hypothesis is not overly surprising since there is the Basic Input Output System, and there is the Operating System. And between the two, there is some sort of hierarchy, with the BIOS being the more dominating force. Needless to say that there are also constant re-iterations of AOD to improve performance and fix bugs – in other words, a lot points to the view that AOD is a good band aid but by the end of the day a band aid is still a band aid. This is going to be important later when we are looking at performance comparisons between the B1 and the B3 revision, with the first one “patched” and then “dispatched” and the latter running just as Mother Nature would have intended it had she ever talked to the design team in Austin.
next page: => B3 Revision Silicon =>
All advice and educational articles on LostCircuits are free, but if you feel you can, please make a small donation to us!
