Next ABP generation

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,027
Credit: 215,662,186
RAC: 76,719

RE: What percentage of

Message 96954 in response to message 96953

Quote:
What percentage of realtime are we at currently?

The ABP status page shows 133% of the data taking rate (that's what I'd call realtime) for the last 24h, but that includes the results that have been delayed from previous days during the changes that I had to make to the backend components. Averaged over the past week I'd expect it to be something like 2/3 (66%).

BM

BM

hotze33
hotze33
Joined: 10 Nov 04
Posts: 100
Credit: 367,079,550
RAC: 1,705

I got one of the new new wus.

I got one of the new new wus. Validated with 160 credits.
more are comming.
68632876
68632981
taking roughly 4 times longer, so calculation times are 6800sec and 8100 sec.

hotze

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 468,680,238
RAC: 58,096

I guess one thing to have an

I guess one thing to have an eye on is how BOINC cients are coping with the new units, scheduler-wise. Are the predicted runtimes foir the new units about right?

CU
Bikeman

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,027
Credit: 215,662,186
RAC: 76,719

RE: I guess one thing to

Message 96957 in response to message 96956

Quote:
I guess one thing to have an eye on is how BOINC cients are coping with the new units, scheduler-wise. Are the predicted runtimes foir the new units about right?

The flops estimation was multiplied by 4 wrt. that of a 'traditional' task, so the runtime prediction should be exactly as far off as it had been for four 'traditional' tasks.

BM

BM

Holmis
Joined: 4 Jan 05
Posts: 1,118
Credit: 1,010,397,570
RAC: 970,963

RE: I guess one thing to

Message 96958 in response to message 96956

Quote:

I guess one thing to have an eye on is how BOINC cients are coping with the new units, scheduler-wise. Are the predicted runtimes foir the new units about right?

CU
Bikeman

For me the estimated runtime is about 4h40m and the actual runtime is about 2h20m. DCF at 1.5198.
I'm running a 9600GT and a Intel Q9450, win 7 64-bit.
Link to host

/Holmis

Jim Wilkins
Jim Wilkins
Joined: 1 Jun 05
Posts: 33
Credit: 28,426,884
RAC: 0

RE: I guess one thing to

Message 96959 in response to message 96956

Quote:

I guess one thing to have an eye on is how BOINC cients are coping with the new units, scheduler-wise. Are the predicted runtimes foir the new units about right?

CU
Bikeman

It looks like the estimated time was about 20 to 25 pct. high. No problem.

Jim

archae86
archae86
Joined: 6 Dec 05
Posts: 3,011
Credit: 4,865,681,847
RAC: 3,340,056

RE: I'll try to make this

Quote:

I'll try to make this backwards compatible to avoid yet another application (ABP3). If all goes well, a set of new App versions will be issued in the next days, that can process both current and next generation work. Behind the scenes I'll replace server-side daemons with versions that also can handle both kinds of results. So with luck the only things you'll notice of that change are new App versions and later longer running ABP2 workunits.

BM

Oops for me. A little too compatible, at least for the way I wrote my app_info.

The operation for the new workunits is compatible enough that my app_info controlled host downloaded them, and tried to run them with the immediate previous executable. Ran normally too, until a quarter of the way through (reaching the boundary between first and second of the four bundled WUs). Then it errored out. It looks like this on the results page.

I have a couple of productive hosts with big backlogs with a mix of 1x and 4x work, running on app_info and heading for the same train wreck. I've got my three least productive hosts running without app_info, and hope that one will snag the new "ABP2.04" executable in time for me to install it and save the queued work.

Of course, if some kindly soul could post the new executable somewhere and provide me the URL, that would be wonderful. (they are windows x86 hosts, currently running

einsteinbinary_ABP2_3.06_windows_intelx86.exe 
einsteinbinary_ABP2_3.03_graphics_windows_intelx86.exe


If anyone reading this is using app_info to run APB2 and has a greater than one or two day queue, you might want to check to see if you have a group of work waiting with 4x longer predicted runtime and consider setting No New Tasks or other corrective measure.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5,491
Credit: 63,508,316,713
RAC: 53,661,285

RE: The operation for the

Message 96961 in response to message 96960

Quote:
The operation for the new workunits is compatible enough that my app_info controlled host downloaded them, and tried to run them with the immediate previous executable. Ran normally too, until a quarter of the way through (reaching the boundary between first and second of the four bundled WUs). Then it errored out....


Been there, done that, got the t-shirt ... :-).

Quote:
Of course, if some kindly soul could post the new executable somewhere and provide me the URL, that would be wonderful.


Just go here, scroll down near the bottom and grab the latest versions. You can tell the correct ones by the date. In any case it's 3.08 for the CPU app and 3.11 for the CUDA app. There is no new graphics app for the 3.08 version. You can actually run quite happily with no graphics app specified in app_info.xml, presumably as long as you don't need to click any 'graphics' button :-).

You need to have appropriate clauses in your app_info.xml pointing to the 3.08 executable. Make sure you put the 308 clause before the 306 one. That way the newly downloaded tasks will be correctly 'branded' as 3.08. If you have the 306 clause first, new tasks will still be 'branded' as 3.06. They will crunch and validate successfully but will possibly cause consternation to someone looking at the task details on the website and wondering how a new 'long' task could possibly be crunched without error seemingly after using the old app. Of course, the old app wasn't used - it was just mis-reported that way :-).

The changeover (for the CPU only app) is very simple. You can do exactly the following:-

  • * Perform the edits on app_info.xml in-situ or overwrite the current one with a pre-prepared new copy (make really sure the executable is specified as 3.08 in all relevant places).
    * Drop in a copy of the new 3.08 executable
    * Stop BOINC
    * Start BOINC

The new app will be fired up and will correctly read the last written checkpoint and continue from where the old app had got to. As I don't have any CUDA capable graphics cards, I have no experience with a CUDA changeover.

If anything is not clear - please ask.

Cheers,
Gary.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3,516
Credit: 468,680,238
RAC: 58,096

So whenever I checked during

So whenever I checked during the last few days, the throughput of ABP2 was between 101% and 168% of the data acquisition rate. I guess this means that now the ABP2 search IS running at sustained real-time speed or better (compared to ca 40-50% real-time speed during ABP1 search) !!!

CU
HBE

cristipurdel
cristipurdel
Joined: 19 Jul 07
Posts: 26
Credit: 11,991,887
RAC: 0

RE: So whenever I checked

Message 96963 in response to message 96962

Quote:

So whenever I checked during the last few days, the throughput of ABP2 was between 101% and 168% of the data acquisition rate. I guess this means that now the ABP2 search IS running at sustained real-time speed or better (compared to ca 40-50% real-time speed during ABP1 search) !!!

CU
HBE


Great news. Now it's time to improve it further more :) and reduce the CPU limit :P

Comment viewing options

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