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%).
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.
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?
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.
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
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.
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
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.
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.
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) !!!
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
RE: What percentage of
)
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
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
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
RE: I guess one thing to
)
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
RE: I guess one thing to
)
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
RE: I guess one thing to
)
It looks like the estimated time was about 20 to 25 pct. high. No problem.
Jim
RE: I'll try to make this
)
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
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.
RE: The operation for the
)
Been there, done that, got the t-shirt ... :-).
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:-
* 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.
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
RE: So whenever I checked
)
Great news. Now it's time to improve it further more :) and reduce the CPU limit :P