Has anybody noticed incorrect CPU cache shown on the host description pages? For my AMD 4200+ Dualcore it shows 488.28 KB, but CPU-Z says I have 512KB L2 cache per core, plus 64KB of L1 for code and 64KB of L1 for data (both also per core).

---

Has it ever shown correctly then?
Mine says 976.56 KB even though I'm sure I only have 512KB L2. I remember it showing that number on my old Celeron as well, even though that one had only 256KB L2.

---

Hmm... The only thing I noticed with CPU cache is that BOINC shows only one CPU cache (4096kb) of my dual CPU machine which should actually be 8192kb for both CPUs...

http://www.cosmologyathome.org/show_host_detail.php?hostid=6203

... Mine says 976.56 KB ....

All windows PCs seem to say 976.56 KB which would be 1000000/1024 (value of the <m_cache> tag / k)

Maybe cs_benchmark.C still says

host_info.m_cache = 1e6;    // TODO: measure the cache

On Linux it takes the value from /proc/cpuinfo I guess - and it should not be multiplied with the CPU count as only the cache of one CPU is available for a task.

Maybe this would do :

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\SecondLevel\DataCache

It seems to have the total cache size in k so for m_cache it had to be multiplied with 1024 and divided by the number of physical CPUs, which would be

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\NUMBER_OF_PROCESSORS

p.s.: "edit" eats backslashes :-(

Quick & dirty test thingie, no error handling at all :

#include <windows.h>
#include <stdio.h>

void main(void);

void main()
{
  long  lSizeL2, lNumProc;
  char  NumProc[10];
  DWORD lBufSiz;
  HKEY  HKLM;

  RegOpenKeyEx (HKEY_LOCAL_MACHINE,
       "SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Memory Management",
       NULL, KEY_QUERY_VALUE, &HKLM);

  lBufSiz = sizeof(lSizeL2);

  RegQueryValueEx (HKLM, "SecondLevelDataCache", NULL, NULL, (LPBYTE) &lSizeL2, &lBufSiz);

  RegCloseKey (HKLM);


  RegOpenKeyEx (HKEY_LOCAL_MACHINE,
       "SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Environment",
       NULL, KEY_QUERY_VALUE, &HKLM);

  lBufSiz = sizeof(NumProc);

  RegQueryValueEx (HKLM, "NUMBER_OF_PROCESSORS", NULL, NULL, (LPBYTE) NumProc, &lBufSiz);
  lNumProc = atol(NumProc);
  RegCloseKey (HKLM);


  printf ("\n# of Processors = %ld\n", lNumProc);
  printf ("L2 cache size   = %ld\n\n", lSizeL2);

  printf ("Value for m_cache = %ld\n", lSizeL2/lNumProc*1024);
}

http://oct31.de/tmp/l2_from_reg.zip (12k download, W32 console app)

Output on my dual MP2600+ :

# of Processors = 2
L2 cache size = 512

Value for m_cache = 262144

Quick & dirty test thingie, no error handling at all :

You could add that to Trac, you know? ;-)

---

Quick & dirty test thingie, no error handling at all :

You could add that to Trac, you know? ;-)

I gave it up to keep track of the BOINC dev boards, bug report places and sources for the sourcecode ;-)

My latest local version of BOINC is still an old CSV from alien.ssl.berkeley.edu so it makes not so much sense to use that version of cs_benchmark.C for the full change.

p.s.: I still have an ancient entry in the volunteer devs list so if you want to use the code snippet, no additions would be needed there ;-)

Want to bet?

I just updated BOINC Source code, opened cs_benchmark.c and found:

dhrystone(vax_mips, int_loops, int_time);
host_info.p_iops = vax_mips*1e6;
host_info.p_membw = 1e9;
host_info.m_cache = 1e6;    // TODO: measure the cache

But I did send that bit of code to David&Rom, if you don't mind me to. :)

---

Want to bet?

I didn't have any doubts *g

But I did send that bit of code to David&Rom, if you don't mind me to. :)

That's why I posted it here ;-)


It should be checked on Win9x/ME though (can be done with the test proggie), somehow I feel that the keys might not exist there, so if one of the RegOpen/RegQuery functions fails, it would still have to be "= 1e6; // TODO" for those OS versions.


Win2k has those keys, that's where I tested the program.

David must be checking old emails. Got a reply. ;-)

I looked at this registry entry on my XP machine - it was zero.
I think this registry entry is not automatically set to
the CPU properties - it's there so that you can set it to
the CPU properties, and Windows will take that into account in some way.

-- David

---

David must be checking old emails. Got a reply. ;-)

I looked at this registry entry on my XP machine - it was zero.
I think this registry entry is not automatically set to
the CPU properties - it's there so that you can set it to
the CPU properties, and Windows will take that into account in some way.

-- David

Checking ...


NUMBER_OF_PROCESSORS is documented by Microsoft and even copied into the environment : echo %NUMBER_OF_PROCESSORS%

SecondLevelDataCache is documented by Microsoft too but they describe it like this : If it is zero, the system has to ask the HAL about the correct value or use 256k (default).

The german translation on the Microsoft support page for this key is crappy though so I might have misunderstood it.

I will try to ask the HAL ...


Found the English version : http://support.microsoft.com/kb/183063/en

... I will try to ask the HAL ...

Dang! Neither HAL nor Kernel32 want to tell me :-/

What I found is this : http://fastcode.sourceforge.net/FastcodeFileDownloads/FastcodeCPUID.pas

but they handle it with a long list :-/


The ReactOS code contains nothing but a workaround either so there probably is no smart way to detect it :-(

What I found is this : http://fastcode.sourceforge.net/FastcodeFileDownloads/FastcodeCPUID.pas

but they handle it with a long list :-/

There were already discussions about finding out correct cache size on Seti in the past, maybe you'll find this useful? -> Boinc optimized client and CPU cache

Peter

... There were already discussions about finding out correct cache size on Seti in the past, maybe you'll find this useful? -> Boinc optimized client and CPU cache

Peter

I will check it, thanks :-)

As long as it's 8086 code I should be able to read it, my assembly language knowledge is better for Z80 and 6502 though ;-) I did some simple things with 8086 too but the extension that came after 8086 are completely unfamiliar.

Complex assembly language stuff would be more a task for voodoo men like Akos.


p.s.: The posts in the thread show me that I'm not the first one to have been fallen into those registry traps, nice ;-)

Found the manual with the informations of what CPUID returns - it is what ReactOS must have used, because their program filters out exactly those bits and analyses them.

But after that branch comes the one for AMD having only a comment that the above method didn't work on AMD and they had no method for AMD at all.
______

c't, one of the first german computer magazines (used to be a good source for knowledge before they found out that there are more users than developers) has an old program ("ctcm") that measures the L2 cache size by reading memory blocks of increasing sizes, watching the time used for that and finding out the point when the performance per memory block starts to decrease.

It isn't freesource but I guess Akos could easily make such a thing.

As long as it's 8086 code I should be able to read it, my assembly language knowledge is better for Z80 and 6502 though ;-) I did some simple things with 8086 too but the extension that came after 8086 are completely unfamiliar.

Complex assembly language stuff would be more a task for voodoo men like Akos.

I was left with Z80 and MC68k, partially VAX11/780 dinosaur knowledge. Later just the higher-level languages. I can understand x86 only approximately (the obvious parts).

The posts in the thread show me that I'm not the first one to have been fallen into those registry traps, nice ;-)

Back then my machine was showing the cache size in the registry. But after being informed by others, I've found out a plenty of machines with zeroed SecondLevelDataCache :-(

Peter

c't, one of the first german computer magazines (used to be a good source for knowledge before they found out that there are more users than developers)

That's true, but it is still fairly good, compared to the others.

Peter