AMD's Phenom X4 9850

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.

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.