Think MM means that the specific "Nahelem" CPU is not allowed to be visible and though the device is hidden, the particular CPU as a none-person related item would and why would it be kept a secret if it would disappear in for instance a pool of e.g. X9650's of which there are 254 showing? If there is a very exclusive chip with any of the team members and not visible in that BOINCstat table, then you're right.

Hiding devices is an option on any BOINC project which is where the WCG option came from, but that's old news

Something that hasn't been mentioned here is that the 64-bit version of BOINC runs its benchmarks in 64-bit mode, and the integer benchmark runs MUCH faster than in 32-bit BOINC. Because they are based on your BOINC benchmarks, Points Claimed will be higher with 64-bit, even though the science app is 32-bit and may run no faster. On projects where Points Awarded is influenced by Points Claimed, 64-bit will generate you more points. After the introduction of zero-redundancy to FAAH and DDDT, the only remaining WCG project where Pts Claimed has a large influence on Pts Awarded is, surprise, surprise, HCC. In the Rice project, one inflated Claim will have only a small influence on the average of the first 10 results on which a WU's pts are awarded. I think that with FAAH and DDDT, Pts Claimed now has no influence on Pts Awarded. And HPF2?

I note that on W2k on a dual-core system that spends very little CPU time on apps other than WCG, one calendar day results in some hours less than 48 of WCG CPU time. Other OSes, especially 64-bit ones, could reduce this gap and result in higher WU throughput.

If XP-64 gave an increase in WU throughput of, say, 5% over XP-32, especially on FAAH and DDDT, I would probably upgrade from XP-32. MovieMan, do you think the difference on these projects would be that great?

BTW, A downside of 64-bit Windows is that in the Explorer, the right-click menu will run only 64-bit applications, not 32-bit ones, eg virus scanners, media players, editors, ... Also, some device drivers may be unavailable, eg there is no XP-64 driver for my TV tuner card.

MM, consider the request passed on. Until then, maybe you can hack the client_state.xml and other BOINC parts so it shows something else?

Here's 3 lines from the client_state.xml

<p_vendor>GenuineIntel</p_vendor>
<p_model>Intel(R) Core(TM)2 CPU T5600 @ 1.835GHz [x86 Family 6 Model 15 Stepping 6]</p_model>
<p_features>fpu tsc pae nx sse sse2 mmx</p_features>

Take a Q6600, plug in something else and see what happens and surely your team has a few, that do have software tuning skills. Think to have read somewhere how it's done for BOINC.

Movieman,
Regarding your NDA are you sure that it is not so strict that even WCG techs should not see your proc's performance? Because even if the techs can guarantee that these figures cannot reach BoincStats it is obvious that they would be able to find them in the servers if they want. Not meaning that they would do it and even less that they would misuse them, but seen from the other side of the NDA it is probably the ability which matters, not the real facts.

Regarding what you say about 64-bit OS throughputit may be true for projects which are essentially crunching floating point numbers, but it is clearly wrong for HCC which, I presume, must have a higher share of its crunching on integer numbers. I have compared two sets of HCC results under XP32 and Ubuntu 64 in the same machine and the outcome leaves no doubt, particularly since HCC units size is very homogeneous over time and then you can consider that they are all "containing" about the same amount of work. The average claims are about the same, 62.44 for Ub64 and 65.37 for XP32. But the average durations are 2.90 hours for Ub64 and 3.73 hours for XP32.
Maybe this is not true for all 64-bit processors, but it is for this Q6600.

Cheers. Jean.