a tweak for Prescott owners

[Elektro Slime]

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!

-Slime

 

[Perris Calderon]

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

 

[Elektro Slime]

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

 

[Elektro Slime]

hey got in touch with the guy, heres what he said:

In 3DMark03's CPU Score, on my overclocked 2.8e, I went from 720 to 908. Windows seemed faster. I haven't turned it off since I got my 3.2e, but nothing seems to not be working.

BTW did you get your info from http://xhardwarereviews.com? the guy is a mod there.

 

[NetRyder]

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.

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).

 

[Perris Calderon]

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

 

[Elektro Slime]

okok! i get the hint, say since i dun wanna spread any wrong info maybe you mods should delete this thread?

 

[Perris Calderon]

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.