Today I started using the optimized clients available for Linux, both boinc and seti. It all appears to be working great with noticeable improvments as the first few wu's after the 'upgrade' processed through. I'm curious about one improvement provided by the boinc client. The cpu cache size on the Celeron Coppermine jumped from 256kb to 1mb.
Is this a real figure, or a pseudo-size compiled in to further improve things by making it appear bigger from the server's perspective? I thought the only way to get a bigger cache required a credit card and screwdriver. :)

That refers to the cache on the HD I believe.....

---

Semper Eadem
So long Paul, it has been a hell of a ride.

Park your ego's, fire up the computers, Science YES, Credits No.

That refers to the cache on the HD I believe.....

I based the assumption on info displayed in the kboincspy program...

==
CPU: Celeron (Coppermine)
Cache: 976.34 MB on CPU or CPU module
Measured integer speed (Dhrystone): 2,078.95 MIPS
Measured floating point speed (Whetstone): 1,020.56 MFLOPS
==

The same large number appeared on the host detail page.

For fun, I just shut down boinc and seti and restarted it, now both the kboincspy info and that on the host info page show the expected, meager 128kb. I hadn't interrupted it since upgrading the client, so the strange numbers might have been some fallout from the initial benchmark run after the upgrade. Dang, that 1 meg cache did look good while it lasted. :)

In older times, when the code wasn't able to determine the size of the 2nd level cache, it assumed a cache size of 1 or 2 MBytes. I presume, it's the same case here. Because of the optimized code the difference is not clearly detected by the benchmark code and therefore it assumes a 2nd level cache that big.
[edit]
I have a Pentium III-M 1.0 GHz with 512 KB 2nd level, a Pentium 4 1.8 GHz with 256 KB 2nd level and an Athlon TB 1.4 GHz with 256 KB 2nd level cache and all have a reported cache of 976.56 KB :) I think this is because i have an eye on fast memory, so the difference is not that big and not properly detected by the code.

---

Aloha, Uli

Don't feel bad ... it reports 1M cache for my Xeons when they have 2M ...

---

I don't think this has any thing to do with anything optimized. I went poking around and it looked to me like everybody's says "cache of 976.56 KB".

At least if I'm looking where I think you are looking.

---

Cache is OK for my processors.
I would guess you have found a weakness in whichever C library is called to report processor cache.

---

All my processors have "cache of 976.56 KB". No discrimination here :)

---

even funnier is my G5 which has 256K L2 shows 1M ...

---

even funnier is my G5 which has 256K L2 shows 1M ...

---

I also have this issue. I have a core 2 duo with 2m chache (allendale core)but boinc reports "Cache 976.56 KB". I dismissed this at first as 2 core's, 2m cache, 1m each. But I don't know afetr reading all these post's about cache reporting.

Same here with C2D Conroe (2x2MB cache).

All my host reports 976.56 KB cache ;-)

This "problem" has beeen discussed here in the forum several times.

Kiva

---

Greetings from Norway

Crunch3er & AK-V8 Inside

There used to be code, once upon a time, to attempt to figure out how big the caches were. It wasn't very accurate...and was later dumped. However the display of cache on user's hosts was left. So they put a value in each host's info of 1 Million (but not 1024*1024 which is 1 Meg). So 1,000,000 divided by 1024 = 976.56

What about using the value of HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Memory Management\\SecondLevelDataCache? Sure more reliable than 976.56kB.

Peter

What about using the value of HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Memory Management\\SecondLevelDataCache? Sure more reliable than 976.56kB.

Peter

If you are only targeting Windows....

---

If you are only targeting Windows....

I've found many Linux hosts where it works and many where not, no idea why. Should grep cache /proc/cpuinfo work?. No idea about other Unices.

With the Wndows solution a high percentage of available hosts would be covered.

Peter
[totally edited/]

My windows registry - for that value - displays 0 for both cores of my Athlon 64 X2 3800+.

I suspect Windows O/S is only using 1 or 2 of the 3 methods to gather Cache sizes (apparently not the AMD method).

OK, Ben, you've got me!!

Few weeks ago I've found this link to some Intel devel area and while looking around I found some sources for detection of CPU characteristics (look around for WinCPUID library, down on the page, text "Download the source code for IA-32 and x64 platforms."), with small example app WinTestCPUID.

The source code seems to support HTs and multi-cores, AMDs, is older (non-CPUID) processors-aware, free of charge and maybe worth looking at. I could check the test app only on an Pentium-M, no older or newer or AMD or multi-core proc available.

My windows registry - for that value - displays 0 for both cores of my Athlon 64 X2 3800+.

0 is the default value, = 256 Ko L2
You can modify this value according to your CPU, 100 hexa / 512 decimal, etc

I suspect Windows O/S is only using 1 or 2 of the 3 methods to gather Cache sizes (apparently not the AMD method).

This SecondLevelDataCache registry key will be used ONLY if HAL is unable to identify L2 cache, mostly on ancient computers.

---

OK, Ben, you've got me!!

Few weeks ago I've found this link to some Intel devel area and while looking around I found some sources for detection of CPU characteristics (look around for WinCPUID library, down on the page, text "Download the source code for IA-32 and x64 platforms."), with small example app WinTestCPUID.

The source code seems to support HTs and multi-cores, AMDs, is older (non-CPUID) processors-aware, free of charge and maybe worth looking at. I could check the test app only on an Pentium-M, no older or newer or AMD or multi-core proc available.

Checked this library you referred to. It is only available in library form, not the source. So can't change the way it behaves. Its display found my multiple cores on the 64 X2 3800+ but not the cache (uses the intel CPUID[4] method only apparently).

Anywho, I've written a CPUID which will be in the newest Chicken optimized seti release. It finds all the versions. Will provide the source to Eric K at boinc if he wants it there also.