Our tests indicate that the upcoming ABP2 GPU tasks typically take ~0.6 hours per WU. This is still "just" a factor of 2-3 faster than the ABP2 CPU version, but after the ABP2 release we are going to concentrate on improving the GPU code
Looking good.
Is this going to be an automated rollout or do we need to start playing with the app_info file?
Just a thought: Is there anything 'interesting' to see with visualising the CUDA code in operation? Or would it all just be a noisy mass of coloured pixels?
Our tests indicate that the upcoming ABP2 GPU tasks typically take ~0.6 hours per WU. This is still "just" a factor of 2-3 faster than the ABP2 CPU version, but after the ABP2 release we are going to concentrate on improving the GPU code.
Cheers,
Oliver
Sounds like Macs and ATI-equipped PCs are on the losing side...
Our tests indicate that the upcoming ABP2 GPU tasks typically take ~0.6 hours per WU. This is still "just" a factor of 2-3 faster than the ABP2 CPU version, but after the ABP2 release we are going to concentrate on improving the GPU code.
Cheers,
Oliver
Which GPU card, and how much did it took with the ABP1 GPU?
Is this going to be an automated rollout or do we need to start playing with the app_info file?
We're currently running ABP2 workunits on our test project server. These tests typically cover the CPU/GPU versions of all supported platforms. We haven't yet decided whether a public beta test (using app_info.xml) will be necessary or not. If we choose not to run a public beta test, ABP2 apps and workunits are likely to be rolled out very soon (1-2 weeks from now). As soon as ABP2 is running smoothly we'll stop publishing ABP1 work.
Quote:
Just a thought: Is there anything 'interesting' to see with visualising the CUDA code in operation? Or would it all just be a noisy mass of coloured pixels?
No, it does the same as the CPU version. However, the displayed search parameters and the power spectrum will be updated more frequently. Maybe we'll be adding a few GPU-specific details in the future - for the time being we focus on performance though. IMHO, the screensaver should be disabled when running GPU workunits anyway, unless you have a dedicated GPU for crunching...
Our tests indicate that the upcoming ABP2 GPU tasks typically take ~0.6 hours per WU. This is still "just" a factor of 2-3 faster than the ABP2 CPU version, but after the ABP2 release we are going to concentrate on improving the GPU code.
Which GPU card, and how much did it took with the ABP1 GPU?
Sorry, forgot to mention that: we use GTX200 series cards (GTX 285, GTX 295, Tesla C1060). The improvement in comparison to ABP1 stems from changes not related to the GPU, so ABP2 CPU tasks will also finish much more quickly than ABP1 CPU tasks. The CPU/GPU ratio should still be slightly improved however.
Tonight I have a great time for a E@H pause reaching daily quota for 4 results for Q9400 8[ ].
Yes, I did make a mistake when I deleted app_info.xml before the cache has drained out. But!
Suddendly after stopping and upgrading BOINC to the latest 6.10.18, I received 4 last S5R5 tasks and unfortunelly didn't find any *.exe for it neither in my BOINC directory nor in E@H (the link for S5R5 tasks obviously had been removed already). So my BOINC was not able to download any S5R exe and I aborted the download for this file. Now I'm in "reached daily quota" mode for 4 hours. And even 9800GTX suffering because of that.
So, can somebody explain this so strange behaviour of BOINC?
The easiest way is to reset the project after deleting app_info.xml, so that the standard application is downloaded again. There have been several threads about that topic.
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
... Suddendly after stopping and upgrading BOINC to the latest 6.10.18, I received 4 last S5R5 tasks and unfortunelly didn't find any *.exe for it neither in my BOINC directory nor in E@H (the link for S5R5 tasks obviously had been removed already).
The S5R5 app is still readily available. For example, here is the 'switcher' app but the _0, _1 and _2 apps are also there as well.
Quote:
So my BOINC was not able to download any S5R exe and I aborted the download for this file.
The mistake you made was probably that you deleted the app files at the same time as you deleted the app_info.xml file. When BOINC starts, it already has previously copied the contents of app_info.xml into the state file so if you have just deleted app_info.xml, it still has the previous contents (not yet removed but will be auto-removed later) in the state file so it still expects to find the old apps and it gets upset if it doesn't find them. Under the AP mechanism, there is no legally available url for BOINC to use since the files are supposed to be 'user supplied'.
There are several ways to terminate AP participation but I find the easiest is to just delete app_info.xml and leave the apps for BOINC itself to delete (which it will do at a later stage) when it fully realises that it is no longer running under AP. Jord (Ageless) promotes the (perhaps more user friendly) procedure of resetting the project as well (which removes the AP stuff from the state file immediately) but this can entail a lot of unnecessary re-downloading.
Quote:
Now I'm in "reached daily quota" mode for 4 hours. And even 9800GTX suffering because of that.
So, can somebody explain this so strange behaviour of BOINC?
I believe that the 4 S5R5 tasks would have been marked as 'download error' when the app download failed. Let me know if you still have those tasks in your list as it would be possible to 'resurrect' them as long as they hadn't been reported. If you have reported the results (which you probably have by now) it will be too late. I have done this before but the memory is a bit vague :-).
I also hope by then the size of the E@H CUDA/GPU tasks will also be less than 3 hours (a limit which appears to be what the people at S@H are using) so E@H plays better with others on the GPU.
Our tests indicate that the upcoming ABP2 GPU tasks typically take ~0.6 hours per WU. This is still "just" a factor of 2-3 faster than the ABP2 CPU version, but after the ABP2 release we are going to concentrate on improving the GPU code.
Cheers,
Oliver
Thank you for the update. When do you expect to start making ABP2 tasks available and is there a way to identify them when they appear in the task list?
RE: Our tests indicate that
)
Looking good.
Is this going to be an automated rollout or do we need to start playing with the app_info file?
Just a thought: Is there anything 'interesting' to see with visualising the CUDA code in operation? Or would it all just be a noisy mass of coloured pixels?
Happy crunchin',
Martin
See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)
RE: Our tests indicate
)
Sounds like Macs and ATI-equipped PCs are on the losing side...
RE: Our tests indicate
)
Which GPU card, and how much did it took with the ABP1 GPU?
RE: Is this going to be an
)
We're currently running ABP2 workunits on our test project server. These tests typically cover the CPU/GPU versions of all supported platforms. We haven't yet decided whether a public beta test (using app_info.xml) will be necessary or not. If we choose not to run a public beta test, ABP2 apps and workunits are likely to be rolled out very soon (1-2 weeks from now). As soon as ABP2 is running smoothly we'll stop publishing ABP1 work.
No, it does the same as the CPU version. However, the displayed search parameters and the power spectrum will be updated more frequently. Maybe we'll be adding a few GPU-specific details in the future - for the time being we focus on performance though. IMHO, the screensaver should be disabled when running GPU workunits anyway, unless you have a dedicated GPU for crunching...
Best,
Oliver
Einstein@Home Project
RE: RE: Our tests
)
Sorry, forgot to mention that: we use GTX200 series cards (GTX 285, GTX 295, Tesla C1060). The improvement in comparison to ABP1 stems from changes not related to the GPU, so ABP2 CPU tasks will also finish much more quickly than ABP1 CPU tasks. The CPU/GPU ratio should still be slightly improved however.
Oliver
Einstein@Home Project
Tonight I have a great time
)
Tonight I have a great time for a E@H pause reaching daily quota for 4 results for Q9400 8[ ].
Yes, I did make a mistake when I deleted app_info.xml before the cache has drained out. But!
Suddendly after stopping and upgrading BOINC to the latest 6.10.18, I received 4 last S5R5 tasks and unfortunelly didn't find any *.exe for it neither in my BOINC directory nor in E@H (the link for S5R5 tasks obviously had been removed already). So my BOINC was not able to download any S5R exe and I aborted the download for this file. Now I'm in "reached daily quota" mode for 4 hours. And even 9800GTX suffering because of that.
So, can somebody explain this so strange behaviour of BOINC?
The easiest way is to reset
)
The easiest way is to reset the project after deleting app_info.xml, so that the standard application is downloaded again. There have been several threads about that topic.
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
Yes, I did it. But it doesn't
)
Yes, I did it. But it doesn't help, because it tries to download S5R5....x86.exe that doesn't exist anymore :)
RE: ... Suddendly after
)
The S5R5 app is still readily available. For example, here is the 'switcher' app but the _0, _1 and _2 apps are also there as well.
The mistake you made was probably that you deleted the app files at the same time as you deleted the app_info.xml file. When BOINC starts, it already has previously copied the contents of app_info.xml into the state file so if you have just deleted app_info.xml, it still has the previous contents (not yet removed but will be auto-removed later) in the state file so it still expects to find the old apps and it gets upset if it doesn't find them. Under the AP mechanism, there is no legally available url for BOINC to use since the files are supposed to be 'user supplied'.
There are several ways to terminate AP participation but I find the easiest is to just delete app_info.xml and leave the apps for BOINC itself to delete (which it will do at a later stage) when it fully realises that it is no longer running under AP. Jord (Ageless) promotes the (perhaps more user friendly) procedure of resetting the project as well (which removes the AP stuff from the state file immediately) but this can entail a lot of unnecessary re-downloading.
I believe that the 4 S5R5 tasks would have been marked as 'download error' when the app download failed. Let me know if you still have those tasks in your list as it would be possible to 'resurrect' them as long as they hadn't been reported. If you have reported the results (which you probably have by now) it will be too late. I have done this before but the memory is a bit vague :-).
Cheers,
Gary.
RE: RE: I also hope by
)
Thank you for the update. When do you expect to start making ABP2 tasks available and is there a way to identify them when they appear in the task list?
Thanks.
Tom