Processor affinity screwed up?

What two applications are you actually seeing this affinity "problem" for?

My guess is that BOINC is launching einstein_S5R4_6.04_windows_intelx86.exe (81 KB), and giving it a whole core all to itself. Since the only role of this app is to detect the presence/absence of SSE capabilities in the CPU, and then launch the appropriate worker app (einstein_S5R4_6.04_windows_intelx86_1.exe, in your case), that's rather a waste of a core.

I think it's highly unlikely that the Einstein project staff will waste time modifying their application to work with an unsupported BOINC feature in an elderly, unofficial BOINC version - I say 'elderly' because even the current (downloaded today) Version 5 of Crunch3r's v6.1.0 is dated 8 February 2008, and hence can't be a true BOINC v6 compliant application.

I think you have three options:

1) Use a stock (supported) BOINC version which doesn't try to enforce processor affinity - I've never seen anyone on any BOINC board post convincing figures to suggest there's any benefit from using affinity on modern CPUs anyway.

2) Write an app_info.xml file to launch instein_S5R4_6.04_windows_intelx86_1.exe directly without benefit of the CPU switcher.

3) Go back to the source of the problem, and ask Crunch3r to write a version of BOINC which handles affinity for child processes too.

I'm one of the few people who has actually posted results attempting to evaluate this point experimentally.

For my particular system and applications, there actually appeared to be a small penalty of turning on processor affinity.

While I'll cheerfully acknowledge that this answer could vary some with detailed application characteristics and system architecture, I think the general conclusion that processor affinity is always helpful is quite clearly wrong.

In your particular case, the penalty that you have already paid in lost work because your specialized BOINC client was allocating an entire core to a dispatching process has probably already lost you more work than any possible gain you might get for many months.

I'm not really saying this to discourage you in your quest, but to balance your comment for others who might be reading and might be influenced.

Possibly your mix of applications (I only run SETI and Einstein, ran the tests a while ago, and don't recall the mix of work I used) gives you an affinity reward not seen by others.

I can mention a couple of ways to get imbalance which I've observed on my Duo and my Quad.

1. As is well known, there is a startup phase each time a new Einstein WU starts up or one resumes from a checkpoint (not for a simple task resume from a memory image). During this phase Process Explorer reports that the Einstein task racks up a huge number of I/O read bytes, I've seen from about 750 Megabytes up past 1.3 Gigabytes--very reproducible within sequential work from the same frequency, but with big fixed effects, I think the higher frequencies do more). During this period, the Einstein task can't use up a full processor, partly because work gets attributed to the System task using perhaps a third of the CPU expended on the Einstein task, but also, at least when four tasks are launching from the same start time, there is appreciable idle time. How long this period lasts seems very highly variable--not only to CPU speed, and environment of other tasks, but also, at the least, to one's choice of anti-virus and firewall software (both). I've seen as little as well under twenty seconds, and as much as five minutes or more).

So, anyway, if I look when one Einstein task is in that startup phase, and other(s) not, there is a big CPU time imbalance, with the starting up one getting well under 1/n, and the others getting just about 1/n, assuming nothing else is going on.

2. When "something else" is going on which uses appreciable resources, I've noticed it to take them unequally from the current running Einstein tasks.

I should note that these observations are all with a client that enforces no CPU affinity preferences (stock BOINC 5.10.45) on Windows XP Pro systems, with Conroe-generation CPUs. As affinity enforcement removes a degree of freedom of the OS to schedule available work to available resources, I suspect it would make these particular cases worse.

Along with archae86, I have attempted to measure the practical benefits of processor affinity. This chart was the result:

(direct link)

OK, that's an elderly chart - first posted 21 December 2006: you can tell from the Crunch3r affinity BOINC I tested (v5.7.5). Also, I was testing the old-style SETI Linefeed applications, not the modern MultiBeam ones.

But I still feel that the difference between standard BOINC (blue markers) and affinity BOINC (green markers) is unconvincing - even with two CPUs, four caches and eight core pipelines just waiting to be trashed! The solution, in my case, was to feed the dual Xeons with quad-channel memory (yellow markers).

I'm willing to be convinced, but I'd like to see some actual, practical, real-world WU timings (since this is Einstein, corrected for sequence periodicity and high-frequency wiggles). What sort of percentage speed increase, overall, do you reckon you get from affinity?

Hi!

Interesting stuff indeed. However, I really don't expect the answer to the question "Does it matter to BOINC perfoamnce to enforce CPU affinity" to be as simple as "yes," or "no".

Think about the the huge scope of different configurations & use cases we are talking about:

* multi-core vs multi CPU
* NUMA style SMP vs shared memory
* multi cores that share (some) cache levels across cores vs dedicated caches per core or per core-pair on the same die or whatever....
* CPUs with an abundance of cache and those with rather small caches...
* Not to forget hyperthreading as an additional complication ..
* The load on the system from other processes than BOINC.

I even would not be surprised if different versions of Windows (e.g. Server and home editions) already had different scheduler strategies and/or built in heuristics for CPU affinity.

CU
Bikeman