Announcement

Collapse
No announcement yet.

AMD Phenom B2 performance, TLB workaround enabled vs. disabled

Collapse
X
Collapse
 
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
  • #1

    AMD Phenom B2 performance, TLB workaround enabled vs. disabled

    I have seen several Phenom 9500/9600 performance reports that show speed differences between the chip with the TLB workaround enabled and with the workaround disabled. They typically show a 5-15% performance drop with the workaround enabled (which is usually the default). My rendering tests showed 40% and 46% performance drop.

    I have an AMD Phenom 9500, Gigabyte MA790FX-DS5 (shipped with BIOS revision level 3, with the TLB workaround toggle), and two Corsair XMS2 DDR2-800 2GB RAM sticks. I have a fresh Fedora 8 64-bit install, updated through pup using Livna and Fedora repositories.

    The test uses the Radiance renderer that I use a lot for art purposes, and for which I have tested and tabulated nearly a hundred other machines. The single-thread test uses only 20MB of RAM, so I expect that the cache is especially active.

    The single-thread test, with the TLB workaround enabled, clocked in at 7739s, or about as fast as an Athlon XP 2500+ or a 2.66GHz Xeon. Disabling the TLB workaround caused the rendering time to decrease to 4617s (40% decrease), or about as fast as an Opteron 250 (2.4 GHz).

    The multithreaded test ran in 2142s with the workaround enabled, and 1154s with it disabled (46% decrease).

    Does anybody else have real-world performance results for the step B2 Phenom TLB workaround?

    Why would my tests indicate a much more significant performance slowdown than the other reported tests?
    Tags: None
  • #2
    Since you are using a 64bit system, just compile the kernel yourself and apply the AMD fix for the problem. With the new kernel the problem does not appear anymore (since the cases are catched by the the kernel) and you can leave the TLB on.

    Yes, this is a Linux only solution, no way for Windows usage to do so. Those who know German can read a how-to about patching the kernel with the fix over here:
    Planet 3DNow - AMD Phenom ohne TLB-Fix - so geht?s

    Comment

    • #3
      That fix was developed to fix stability issues on Linux clusters. Maybe a "standard" user would not be able to identify why the system crashed if that happens. In many cases the fault is somewhere else. Of couse when the system has to be stable for weeks then this fix is really important.

      Comment

      • #4
        Originally posted by ivanovic View Post
        Since you are using a 64bit system, just compile the kernel yourself and apply the AMD fix for the problem. With the new kernel the problem does not appear anymore (since the cases are catched by the the kernel) and you can leave the TLB on.

        Yes, this is a Linux only solution, no way for Windows usage to do so. Those who know German can read a how-to about patching the kernel with the fix over here:
        Planet 3DNow - AMD Phenom ohne TLB-Fix - so geht?s
        Hi, thanks for your reply. I am not really comfortable recompiling the kernel (I have tried several times over the past 10 years, each time ending in failure). Fortunately, I suspect that I can live with the TLB workaroud disabled---the system was just as unstable as with it enabled.

        I am a Linux-only house. Um, except for my MacBook.

        Comment

        • #5
          Originally posted by Kano View Post
          That fix was developed to fix stability issues on Linux clusters. Maybe a "standard" user would not be able to identify why the system crashed if that happens. In many cases the fault is somewhere else. Of couse when the system has to be stable for weeks then this fix is really important.
          So far, I hadn't been able to get my Phenom 9500 system to stay running under full load for more than a half-hour. I do scientific computation, and I expect to have machines loaded for weeks at a time.

          I suspect that the stability problems that I had are not related to the TLB bug, but instead to either inaccurate sensors or improperly-installed northbridge heat sink. I'll try again in a week when the replacement parts show up. Thanks!

          Comment

          • #6
            Well a BIOS update can help too and if you would test your ram it would be good. Maybe you bought accidently overclocker ram that needs more voltage than just 1.8v.

            Comment

            • #7
              Originally posted by Kano View Post
              Well a BIOS update can help too and if you would test your ram it would be good. Maybe you bought accidently overclocker ram that needs more voltage than just 1.8v.
              Good ideas, both. I downloaded and was ready to install the BIOS update (L3 now, L5 is the new one), but I wound up returning the mobo and CPU on Friday.

              I hadn't thought that there could be "overclocker" RAM. I just checked the stats, to be sure. It's Corsair XMS2 (newegg.com), and the website shows 1.9V. The DDR2 slots on the mobo have "1.8V" written in tiny print on them, but the BIOS only gave me the option of setting a differential voltage: "+0.05V, +0.10V," etc., so I don't know what the default voltage is.

              I ran MemTest86+ at default and +0.1V settings, and both ran for over an hour before I stopped the tests.

              Comment

              • #8
                DDR2 default voltage is always 1.8V. If you are not going to OC the ram, finding a cheap 800mhz kit that works at standard 1.8v is a better option imo. BTW do the addon sata ports work on that board? They are the 2 different colored ones.

                Comment

                • #9
                  Yes you have to use +0.1V in your case. 1.9-1.8=0.1.

                  Comment

                  Previous template Next
                  Working...
                  X