The first B3 Stepping Phenom

We managed to get our hands on a 2.2GHz engineering sample B3 stepping Phenom:

AMD will begin shipping production B3 Phenoms later this quarter, presumably at higher clock speeds than the 2.2GHz - 2.3GHz launch parts. Our B3 sample was very similar to our B2 chip in that we could get it stable at 2.6GHz but didn't have much luck getting it to run comfortably any faster. We suspect that it'll take a move to 45nm before AMD can really start to push the clock speed on Phenom.

To get an idea of how much of a performance hit the software/BIOS TLB fix incurs we took a small selection of our normal CPU tests and ran with the patch enabled/disabled on a B2 stepping Phenom 9600 (2.3GHz):


  SYSMark 2007 DivX CineBench R10 3dsmax 9 WinRAR
AMD Phenom 9600 (B2 Stepping) - TLB Fix Disabled 117 74.3 fps 7396 7.20 1348 KB/s
AMD Phenom 9600 (B2 Stepping) - TLB Fix Enabled 105 72.0 fps 7031 6.47 367 KB/s
Performance Impact -10.3% -3.1% -4.9% -10.1% -72.8%

 

The smallest performance impact was a meager 3.1% reduction, but we suspect that 10%+ would be far more typical. WinRAR is a particularly extreme case where performance dropped by over 70%, which AMD indicated would happen given the heavy memory access nature of file decompression applications.

The new B3 stepping Phenom shouldn't perform any differently to a B2 stepping chip with the TLB fix disabled, but to confirm we ran the most extreme test once more:

512 256MB
  WinRAR
AMD Phenom 9600 (B2 Stepping) - TLB Fix Disabled 1348 KB/s
AMD Phenom 9600 (B2 Stepping) - TLB Fix Enabled 367 KB/s
AMD Phenom B3 @ 2.3GHz 1357 KB/s

 

As expected, all is good with B3. The TLB Fix option actually disappeared from the Gigabyte 780G's BIOS upon inserting a B3 chip, it's like the problem never existed.

Final Words

With the TLB erratum fixed in B3, AMD is one step closer to a competitive Phenom part. Unfortunately Phenom still suffers from low clock speeds and that's something AMD will be working on in the coming months. It will take a combination of higher clock speeds and very competitive pricing to really save Phenom.

The "TLB Bug" Explained
POST A COMMENT

29 Comments

View All Comments

  • eok - Thursday, March 20, 2008 - link

    The article, while great news, still leaves me guessing at what they actually tested and how.

    They say they got their hands on a 2.2ghz B3. The CPUZ data confirms that. But in the final "extreme" test, they show the B3 @ 2.3ghz. So, they overclocked?? Via unlocked multiplier or by increasing the FSB???
    Reply
  • eye smite - Saturday, March 15, 2008 - link

    I don't typically read your site anymore as the articles since phenom launch, particularly the phenom launch article reads more like a rant than a review. Every AMD article reads the same, it's a good cpu but........and then this laundry list of issues and why you see them as critical or distasteful and so on. Why the hell can't you just do a straight forward review based on the facts and leave the colorful commentary for the political videos on youtube? You lot suffer from some idiotic perception issues. Reply
  • Narg - Friday, March 14, 2008 - link

    Personally I think the problem lies within the 3 levels used. When I first read the Phenom specs, I was sad to see there were 3 levels of cache. The complexity that adds to a processor is exponential! I would have been far more happy to see a single L2 cache between all processors of much larger size and better access. I can't imagine why they opted for 3 levels. Seems to be a hurried solution to get the Phenom to market, since so many of the single core chips AMD has built in the past have 3 levels of cache, which of course helped those chips. They need to design an effective 2 level cache only chip. Reply
  • BernardP - Friday, March 14, 2008 - link

    About the article, I am thankful for the most complete and understandable explanation of the TLB error and fixes I have seen since Phenom was released. Reply
  • bradley - Wednesday, March 12, 2008 - link

    We finally have more concrete instances of the bug being induced and documented. Though maybe we have different opinions of what constitutes a rare bug. If it took AMD to inform us, perhaps they are fairly rare instance. In hindsight, the coverage on the TLB issue does appear vastly disproportionate to the actual threat itself. Reply
  • DigitalFreak - Wednesday, March 12, 2008 - link

    On the desktop, yes. My understanding is that it's a huge issue with the Opterons, which are more likely to be used in situations where the bug crops up (VMWare, etc.) It also explains why you still can't buy a quad-core AMD server from HP, Dell, etc. Reply
  • Griswold - Thursday, March 13, 2008 - link

    Its not so much of an issue with opterons if you use a unix/linux derivate and apply AMDs own kernel patch which solves the problem with almost zero performance loss (it doesnt just disable the TLB like the BIOS option does). Windows Servers on the other hand...

    Still, understandable that some vendors just stay away from it until B3.
    Reply
  • JumpingJack - Friday, March 14, 2008 - link

    http://www.amd.com/us-en/assets/content_type/white...">http://www.amd.com/us-en/assets/content...e/white_...

    As most have stated, errata are a fact of life for every CPU, the fact that Intel or AMD publish errata is because the found something so obscure, the typical quality assurance testing (which must be rigorous and thorough) never expressed the bug. The occurence so rare that the problems it may cause would likely go unnoticed to the average user. This is fine for DT, a crash or lock up would probably result in a few choice, colorful words with regard to Microsoft and they reboot and on their way.

    In the enterprise space, though, uptime is everything, and more importantly the sanctity of the data.... from AMD's own publication on Errata 298 ...

    " One or more of the following events may occur:
    • Machine check for an L3 protocol error. 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.
    • Loss of coherency on a cache line containing a page translation table entry.
    • Data corruption. "

    It is last possibility that most likely resulted in AMDs decision to hold off service the mainstream server market and they made the absolute right decision doing so...
    Reply
  • bradley - Wednesday, March 12, 2008 - link

    Yes, that goes without saying. I guess most assumed the same held true for Phenom as Barcelona, when taking the TLB errata into consideration. And there wasn't one clear voice to dissent or say otherwise, which is unfortunate. For whatever reason Intel's own C2D TLB bug didn't receive nearly as much press, which could also cause system instability. Every chip has bugs, but only when documented does it become errata and revised. Reply
  • larson0699 - Wednesday, March 12, 2008 - link

    SPEC CPU 2006 in Vista x64 may be real world for enough to warrant the fix (though IMO it should have been right the first time), but it's really not that common.

    Only labrats and enthusiasts run benchmarks (but at least they have my respect), and only complete tools run the version of an already heavy OS that further bottlenecks most of today's apps. As a tech, I have no sympathy for anyone who chooses to run down MS's path and patronize their every mistake--yes, it may be a hasty opinion, but it is backed by common sense. There is nothing XP or an Xbox 360 cannot do better.

    Anyway... *sigh*

    High fives to Anand for another awesome in-depth review, for making me one article smarter, and to AMD for more practical results as of late.

    P.S. These guys run their own show--not plagiarize others. Please cite your evidence to them directly instead of FUD the forums.
    Reply

Log in

Don't have an account? Sign up now