Navigate:

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

Search Prices:








































































































































What are you
shopping for?



































































































































































LOSTCIRCUITS

SHORTCUTS:
The Bug that Wasn't
-50 Series / B3 Silicon
Test Configurations
Memory Subsystem
Power Consumption
TrueSpace and Power Efficiency
Cinebench
DVD-Shrink, MainConcept
VirtualDub/DivX
3DMark'06
World In Conflict
Crysis
F.E.A.R.
UnrealTournament3
Overclocking - The Final Analysis

Give Us Some Feedback on this Review

 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!
Thank you!

General disclaimer: This page only reflects the author's personal opinion and assumes no responsibility whatsoever regarding any of the contents or any damages that may occur explicitly or implicitly from reading the contents of this site. All names and trademarks mentioned in this review are the exclusive property of the respective parent companies.
All contents of this site are protected by international copyright laws. Reproduction of the contents even in parts is not allowed except after written permission by the author and referral to this site.
Copyright 2002 - 2008 LostCircuits