New app and SSE-only CPUs
14 Apr 2010 22:01:13 UTC
Topic 194875
(moderation:
This my host http://einsteinathome.org/host/583490/tasks encounteres many errors like this:
einsteinbinary_ABP2_3.08_windows_intelx86.exe caused an Illegal Instruction
Does this app supposed to run on older Athlons? (not Athlon XP) ?
New app and SSE-only CPUs
)
It looks like this machine errors out on ABP tasks, not on GCE. I'll notify the ABP devs, for now you could disable ABP in your preferences for this machine.
BM
BM
Since SSE2 has been available
)
Since SSE2 has been available since 2001, and the vast majority of modern computers support it, it's natural that project developers will wish to take advantage of the benefits it offers: Raistmer, as a developer himself, will be well aware of that.
The question is, how long is it going to go on being worth including 'legacy' (pre-SSE2, or even pre-SSE) versions when developing new applications: and how to enable older computers to contribute meaningfully to science, without manual fine-tuning by the owners of those machines.
Ever since v6.10.34, the BOINC client has included its own CPU detection code, no longer relying on the underlying operating system detection. Thus SSE2 can be detected on Windows 2000, SSE3 and above on Windows XP, etc.
Recent versions of the BOINC server code can also distribute applications selectively based on CPU capabilities, through the 'plan_class' mechanism originally introduced to support GPUs. Obviously Einstein has incorporated some of the new code to support its CUDA application, but equally obviously it hasn't upgraded lock, stock and barrel to a new BOINC server.
A very similar set of problems exists at CPDN, with their new 'FAMOUS' and new-ish 'HadAM3P' applications both requiring SSE2: and their server code is even harder to upgrade with new BOINC features than Einstein's! CPDN have resorted to forum moderators trawling the results for Computer wasting multiple models, and the project administrator blacklisting each host manually (with email notification).
This is clearly manpower-intensive, and I'm not advocating a similar approach here: but I think the projects should put their heads together with BOINC Central to work out some transitional processes before the BOINC development branch, with concepts such as server-side DCF and the new credit scheme, diverges even further from the mature production projects like CPDN and Einstein.
I can confirm that the ABP
)
I can confirm that the ABP App uses SSE, which isn't available on pre-XP Athlons.
Your host can't run ABP Apps (for S5GCE there is a non-SSE application, which runs successful on your machine).
BM
BM
RE: I can confirm that the
)
I see, thanks. Will consider to disable that sub-project to not waste tasks.
But, cause I don't use app_info there, it can be "bell ring" to BOINC/project devs - time to separate hosts by their SSE-level abilities too, not only by available memory and CPU flops...
RE: But, cause I don't use
)
There is the 'plan class' mechanism that would allow to do this automatically, but only with BOINC Core Clients that correctly report the CPU capabilities. And of course requiring some programming effort on the project side. On one hand we have 41(!) hosts on the project that can't do SSE that would benefit a little (no CPU time is wasted in these errors) from that, on the other we have an unknown number of machines that won't get ABP work because of running outdated BOINC clients that don't report the SSE capabilities. Actually we found the benefit not worth the effort to change the project scheduler. If it really annoys the affected participants, there is an easy way for them to avoid getting these tasks.
BM
BM
Could the minimum requirments
)
Could the minimum requirments be added to the applications page
RE: Actually we found the
)
I see, OK. Cause it takes no CPU time to reject such task and usually BOINC users are on flat rate internet connection it's not annoying at all.
From the other hand possible solution could be "if SSE capabilities are unknown (or if reported BOINC client version too old to trust its report), send best what we have" That way for outdated client you could have same situation as now while old hosts with new BOINC client could be treated correctly.
But if there is so low number of old host connected to this project probably it's really not worth any efforts.