ABP2 CPU-only applications
9 Jan 2010 2:56:49 UTC
Topic 194715
(moderation:
The APB2 work generator has now produced several batches of 628 tasks (initially 1 batch, followed by several more some time later) and these tasks (a few thousand in total) have been quickly snapped up by both CUDA capable hosts and CPU-only hosts. Right at this moment and temporarily, available ABP2 work is zero.
There is a thread available for people with capable GPUs to report their observations of the performance of the CUDA ABP2 app. Like many others, I don't own a suitable GPU so I thought I'd create this thread purely for observations on CPU-only performance.
The Devs are monitoring the returns of all APB2 tasks to make sure there are no 'gotchas' before unleashing the full flow. If you have been lucky enough to score some of these 'early release' tasks, you might consider temporarily suspending other tasks in your cache so that the Devs can have feedback ASAP. This would be particularly useful if you keep a multi-day cache of work.
One of my hosts, an old AMD Athlon XP with a five day cache scored two APB2 tasks. By suspending older tasks, these two are being crunched and returned immediately - the second task will finish shortly. ABP1 tasks take around 15 hours on this host. The ABP2 tasks are taking very close to 3 hours so Bernd's prediction of a 5 times speedup is spot on for this architecture.
One immediately visible 'problem' that people will notice is that the ABP2 tasks have a time estimate which is the same as that of ABP1 tasks, ie 5 times too slow. Until the DCF (duration correction factor) which is stored in your state file (client_state.xml) corrects itself, your cache of work wont be as large as you might otherwise believe.
A second potential 'problem' is that those whose monthly download allowance is in any way restricted by their ISP may have issues. The data file size is the same (2MB) but you will potentially be doing 5 times as many in a given period. This will certainly affect me. I have two ADSL services, each with a monthly limit of 6GB peak and 54GB off-peak. Last month my most heavily used service ran up 3GB in peak and 30GB in off-peak. The vast bulk of my usage is related to BOINC projects and the majority of that is E@H data :-). My best bet will be to add a third service and get a whole new bunch of off-peak allowance :-).
Cheers,
Gary.
ABP2 CPU-only applications
)
This is a very bad move: I hope that the run-time estimates output by the work generator ('') can have that factor-of-five correction built in asap, and certainly *before* anybody's DCF moves too much.
The reason is that BOINC only maintains one DCF per project - so if it starts to think that the ABP tasks will take one-fifth of the time specified, it'll start to think that the GW tasks have shrunk, too. That will lead to excessive GW work being requested, and possible deadline misses.
OF course, DCF will be corrected back up again as soon as the next GW task completes - and then you'll have to explain to users what 'EDF' means, and why Einstein seems to be hogging their machine to the exclusion of all other projects.....
This has been a perennial problem in BOINC ever since projects started running multiple application types: I saw it first when Astropulse joined SETI, and it has become much worse with the advent of CUDA. The solution, of course, is to keep separate DCFs for each application class, and we have been pestering BOINC for this for at least a year now - most recently just a couple of days ago. The response was:
A short note for OSX
)
A short note for OSX users.
You will probably find out that the speedup of ABP2 vs ABP1 is less on Intel Macs than it is for Linux and Windows.
This does not mean that there's anything wrong with the OSX version of the ABP2 app. It's just that some of the optimizations that were included in ABP2 were designed to close the gap between the SSE2 optimized OSX app and the SSE aware Linux- and Windows apps. The way the code was improved, the SSE-only penalty is much less dramatic, so to speak, so the relative performance gain (ABP2 over ABP1) is higher for thw Linux and Windows apps.
CU
Bikeman
One of my machines picked up
)
One of my machines picked up 6 of them and has completed all of them successfully.
Average cpu time is 3096 sec (approx 51 mins) on a Intel Core i7-920 at "stock" speed.
Links to wu:
65447771
65447765
65447723
65447722
65447684
65447487
BOINC blog
RE: One of my machines
)
Credit is definitely off. That rate would roughly double my 3.87ghz i7's credit to 16k/day.
After reading this I found
)
After reading this I found three of these tasks in the lists of my none-GPU
computers (I think none for the two computers with GPU) - all finished
sucessfully, two got credit, one not, for whatever reason.
Well, the other two computers that got credit for the task are running
microsoftware, maybe this is the/a problem?
http://einsteinathome.org/workunit/65506729
Even with CPU only, these
)
Even with CPU only, these things are definitely speedsters.
On my 3.2 GHz Phenom II Quad, it only takes about an hour to do one. Even on my 2.4 GHz dual-core Opteron machine, my slowest machine to get one, it only takes about an hour and a half.
It's amazing what a bit of clever programming can do to speed things up.
(Edit: Oops! I noticed after it was too late that I put this in the wrong thread. But, I don't see a way to delete it and move it to the correct one. My apologies.)
Now I found the opposite
)
Now I found the opposite constallation - one computer using microsoftware
compared to two linux computers using GPUs here (one of them is mine):
http://einsteinathome.org/workunit/65498028
Credit for the two linux+GPUs, none for the microsoftware-calculator without
GPU.
Thanks for reporting this, I
)
Thanks for reporting this, I forwarded this case to the devs.
Bikeman
And here's another instance
)
And here's another instance where Windows and Linux failed to validate against each other.
My host is at the top.
/Holmis
I found also
)
I found also one
wuid=65493256
my is the linux, the other two are windows.
But have seen, that the app Version has changed.
My was Linux/x86 application version 1.02
New is Linux/x86 1.03 but this app should active since 7 Jan 2010 12:51:19 UTC
the first result is send out at 8 Jan 2010 16:24:52 UTC
The first valid result is send at 8 Jan 2010 16:31:20 UTC with application version 3.02
should be Windows/x86 3.03 since 7 Jan 2010 12:51:19 UTC
Matthias