ABP2 CPU-only applications

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5,119
Credit: 36,694,742,389
RAC: 37,555,283
Topic 194715

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.

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 1,933
Credit: 197,018,930
RAC: 753,230

ABP2 CPU-only applications

Quote:
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.


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:

Quote:
The "temp DCF" change doesn't address the following problem.
The current plan is to keep track of per-app-version DCF on the server;
I hope get to this in the next couple of months.
-- David [Anderson]
Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,515
Credit: 450,179,579
RAC: 90,350

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

MarkJ
MarkJ
Joined: 28 Feb 08
Posts: 407
Credit: 66,065,894
RAC: 357

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

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1,302
Credit: 1,580,750,997
RAC: 990,793

RE: One of my machines

Message 96464 in response to message 96463

Quote:

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.

Credit is definitely off. That rate would roughly double my 3.87ghz i7's credit to 16k/day.

Olaf
Olaf
Joined: 16 Sep 06
Posts: 26
Credit: 190,763,630
RAC: 0

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

Donald A. Tevault
Donald A. Tevault
Joined: 17 Feb 06
Posts: 439
Credit: 73,516,529
RAC: 0

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.)

Olaf
Olaf
Joined: 16 Sep 06
Posts: 26
Credit: 190,763,630
RAC: 0

Now I found the opposite

Message 96467 in response to message 96465

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.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,515
Credit: 450,179,579
RAC: 90,350

Thanks for reporting this, I

Thanks for reporting this, I forwarded this case to the devs.

Bikeman

Holmis
Joined: 4 Jan 05
Posts: 1,097
Credit: 748,842,385
RAC: 215,191

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

Matthias Lehmkuhl
Matthias Lehmkuhl
Joined: 26 Feb 05
Posts: 10
Credit: 16,751,949
RAC: 0

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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.