a tweak for Prescott owners

Discussion in 'General Hardware' started by Elektro Slime, Dec 26, 2004.

  1. Elektro Slime

    Elektro Slime Harware Guru

    Messages:
    334
    Location:
    Just due South of Heaven
    a tweak for Prescott owners (Doesn't work so dont read it)

    To all Prescott owners, heres something I read that might be worth a shot.

    try it out, let us know if it works:up:

    Instructions:

    1.fire up regedit and go to:

    Hkey local machine>system>currentControll set>Control>Session Manager>Memory Management

    2.Right-click SecondLevelDataCache, click modify, click on decimal and the then type in 1024.





    What this does is it makes XP recognise that you have 1mb of L2 cache instead of 512kb. So now XP will make use of the other 512kb which should provide some noticeable boost.

    If you do decide to try it out please let me know how it went, thanx! :D

    -Slime
     
  2. Perris Calderon

    Perris Calderon Moderator Staff Member Political User

    Messages:
    12,332
    Location:
    new york
    couple of things electro

    That setting is for older chips, not the chips we use...keep it set to "0".

    even on the dinosaur chips that setting was written for, it doesn't control the amount of L2 cache used, it changes the distribution of some OS data within RAM and will optimize what's there, it doesn't to use a differant amount.

    if it's left at default, (set that to zero), the OS detects and uses the correct value on ALL modern processors.

    now, if you have an older processor, for instance a Pentium Pro, and it has with more than 256K L2 cache, then changing this from 0 might be a good idea.

    all this stared with the mskb article 183063, and it's pretty clear

    then again, if you do mess with those settings, and somehow make it wrong it won't have a huge effect on what xp does anyway. From that article:

    SecondLevelDataCache records the size of the processor cache, also known as the secondary or L2 cache. If the value of this entry is 0, the system attempts to retrieve the L2 cache size from the Hardware Abstraction Layer (HAL) for the platform. If it fails, it uses a default L2 cache size of 256 KB. If the value of this entry is not 0, it uses this value as the L2 cache size. This entry is designed as a secondary source of cache size information for computers on which the HAL cannot detect the L2 cache.

    This is not related to the hardware; it is only useful for computers with direct-mapped L2 caches. Pentium II and later processors do not have direct- mapped L2 caches. SecondLevelDataCache can increase performance by approximately 2 percent in certain cases for older computers with ample memory (more than 64 MB) by scattering physical pages better in the address space so there are not so many L2 cache collisions. Setting SecondLevelDataCache to 256 KB rather than 2 MB (when the computer has a 2 MB L2 cache) would probably have about a 0.4 percent performance penalty.


    here's teh history of this non existant "tweak"

    as usual, someone miss read an mskb white paper, (the one I referanced), saw a registry value called SecondLevelDataCache, saw it said it was possbile to get an increase in performance, they didn't see this was older processor specific.

    wanting to make their os faster, and assuming this setting somehow controlled how much cache got used by the CPU in all cases, wrote an article about it...it looks to me like they didn't even re read the article...they certainly didn't check the facts.

    Sooo, a couple of other "experts" saw the article that was written, and said "OH BABY!!!, a TWEAK to write about!" ....they cut and pasted... like too many incorrect "tweaks", this one went forward as a fact.

    the misinformation therefore is repeated time and again, and assumed it's true, since it's wriiten about so much....this happens allot

    this second level cache value won't slow a user down if they set it correctly, but the os allready sets it correctly on any new chip
     
  3. Elektro Slime

    Elektro Slime Harware Guru

    Messages:
    334
    Location:
    Just due South of Heaven
    really? well i saw it on extremeoverclocking.com. every1 said it worked and it was a pretty new post and im sure they were discussing the prescotts. Strange!

    unfortunately i had to return my LGA 775 rig a few days ago, so i didnt test it myself. I dont get it, that site is filled with tech junkies who do know what they are talking about. wait ill have a speak with some guys there and let you know.

    Thanx for pointing it out. BTW it wasnt cut and paste except for the
    Hkey local machine>system>currentControll set>Control>Session Manager>Memory Management

    maybe it was a typo or something. ill check

    -Slime
     
  4. Elektro Slime

    Elektro Slime Harware Guru

    Messages:
    334
    Location:
    Just due South of Heaven
    hey got in touch with the guy, heres what he said:
    BTW did you get your info from http://xhardwarereviews.com? the guy is a mod there.
     
  5. NetRyder

    NetRyder Tech Junkie Folding Team

    Messages:
    13,256
    Location:
    New York City
    As Perris mentioned, modifying this value on modern machines won't have any effect - the MSKB article clearly states that:
    http://support.microsoft.com/kb/q183063/

    Considering the fact that this information comes straight from the folks who wrote the OS, it definitely takes precedence over any other info on the web that states otherwise. The performance difference that the guy noticed has to be because of some other factor(s).
     
  6. Perris Calderon

    Perris Calderon Moderator Staff Member Political User

    Messages:
    12,332
    Location:
    new york
    electro, whenever anyone tries to make a case which is different then what a white paper documents, most of the time disregard the case....you can hardly disregard the kernel team that wrote the os.

    as far as this hack, the white paper is clear, modern processors read the value without help from this hack...however, there are rare times a white paper is wrong, if you suspect this is one of those times, you can find out yourself

    I've seen actual benchmarks...in every case on at least three machines, Hal read the correct cache size when the value was set to "0"

    if you want to check the reading yourself, it's not tough...you don't have to speculate from what me, Microsoft, or anyone writes, you can see it yourself;

    Download the "debugging tools" package from http://www.microsoft.com/whdc/ddk/debugging. , use the default installation

    go to new program group "debugging tools" and start windbg


    File | Symbol file path - set the symbol path to

    SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols

    make sure it's clean...no line breaks, trailing whitespace, clean. now, c:\websymbols doesn't need to exist, it'll be created

    Ctrl K or File - Kernel debug - go to the "local" tab, hit OK.

    a cmd window pops up, and the debugger prompt ("lkd") should appear to the left of the command entry field at the bottom. Type

    !pcr

    hit enter. Note the address of the structure. Then type

    dt _KPCR address

    and press enter... for dual or hyper thread cpu's, use !pcr 0 and !pcr 1 to get the address of each PCR. If you're on an HT system, same thing. Xeons use differant commands, I don't think anyone is on a zeon

    set this reg to "0" before you run the debugger...you'll see Hal reads the second level cache just fine

    that's the way to find out without trusting what anyone has to say about it, me, Microsoft, or 3DMark03.

    or, just change the value, and see if your benchmarks improve
     
  7. Elektro Slime

    Elektro Slime Harware Guru

    Messages:
    334
    Location:
    Just due South of Heaven
    okok! i get the hint, say since i dun wanna spread any wrong info maybe you mods should delete this thread?
     
  8. Perris Calderon

    Perris Calderon Moderator Staff Member Political User

    Messages:
    12,332
    Location:
    new york
    electro, it's a good thread

    when I first started posting here, I also spread some info I thought was true, but wound up being wrong

    for instance, I used to post that lowering the pagefile was a good idea!

    true

    this is a learning thread, and it's a good one.