Memory consumption is indeed a concern. From the data the Alex' posted I figured each ABP2 would consume <200 MB, which would enable running several of these on most modern cards. If they need ~400 MB max (as the current official requirement seems to be) there'd be much less potential to safely run more of them in parallel.
And of course the memory required by other CUDA projects is a concern. I'm not sure how to deal with this properly, as it's impossible to predict how much these are going to require.
Lately I haven't been following E@H closely. What's the current status of ABP3? I understand the goal is to port many more calculations onto the GPU which, if successful, could eleminate the need to efficiently handle the GPU as a coprocessor. Is there already an approximate ETA?
For me, the following thing would have to be clarified before doing changes to the server settings that would affect everyone (as opposed to AP tricks that affect only individual PCs where users want to optimize GPU utilization):
Can this be done in a way that is "safe" in the sense that the video RAM limits are observed even for people with 512 MB cards or people who have processes running that consume a lot of video RAM. It would be kind of unfair (and probably seen as a rather rude thing) if E@H would eat up lots of CPU cores, fill up video RAM as well and would result other GPU apps to fail for lack of video RAM :-(
Note that many people have reported problems even running a single instance of the ABP2 app for lack of video RAM and I would hate to see reducing volunteer's PCs stability just to squeeze out more GFlops for the project.
As for making the ABP2 app sleep while the GPU is working: Bernd and Oliver have stated that this is planned for ABP3, and whether it's worth the effort to change ABP2 now will depend on how far way ABP3 is.
HB
Hi,
I'm sorry, I really can't understand why this is handled so complicated.
A proposal:
as long as nobody posted a complete and working app_info.xml,
initially load the app as now with the setting of 1.000
This setting is usable by everyone who can use it now. The project will not run into any problem.
All these crunchers who want to optimize their setting can change that according to their individual needs.
And when new wu's are uploaded, do not change their setting. This is the only change I'm asking for.
As everyone can see, it seems not to be that easy to compose an app_info.xml. And, in addition, it must be maintained when new apps are available.
I'm not asking for any change in the application, nor am I asking for any mechanism to find out how many apps could be run on a local gpu, nor am I asking for a way to make shure that other apps keep on working. All that is up to the cruncher who makes changes to his system as it would be if running an (unreliable) app_info.xml.
Or, on the other hand, a developer could compose the app_info. He should have all the necessary info. One of the developers had to write the script that adds the info to the client_state.xml. And he should maintain that (new app will come soon ...)
I agree to your post, that it makes no sense to make changes to an app which is (more or less) outdated. New apps are announced, they may or may not contain new features. But here I'm talking about actual running apps.
Please don't misunderstand me. If the new app is coming in a week, forget all that. But if it takes another two months, it would be very helpful to make this single change in the update-script. Or ask the developers for help with an app_info.xml. But it makes no sense to discuss that another two months.
The app_info in this post works. Only thing is the message from Boinc about removing the app_info if you want more work. Haven't tried getting more work, but as another post in this tread said, you will still get work.
That app_info is for crunching GPU only, which is not what the project wants. That's why you'd get "more" work without it (or by modifying it) - you'd also get cpu-only tasks.
@Alex: as far as I understand the client_state.xml is not meant to be edited by the user or to be used to control anything. The BOINC client writes its status into this file basically whenever anything happens.
That's not to say it couldn't be used in any other way. I suspect the fact that MW and SETI do not change the coproc count (as you observed) is more of an unwanted side effect or error somewhere. Anyway.. if it does the trick, why not? Leaving up to the power user to test it couldn't harm the project, could it?
That app_info is for crunching GPU only, which is not what the project wants. That's why you'd get "more" work without it (or by modifying it) - you'd also get cpu-only tasks.
@Alex: as far as I understand the client_state.xml is not meant to be edited by the user or to be used to control anything. The BOINC client writes its status into this file basically whenever anything happens.
That's not to say it couldn't be used in any other way. I suspect the fact that MW and SETI do not change the coproc count (as you observed) is more of an unwanted side effect or error somewhere. Anyway.. if it does the trick, why not? Leaving up to the power user to test it couldn't harm the project, could it?
MrS
Hi ETA,
every single word in your post is correct.
Only one point needs further discussion.
As JohnDK posted, Only thing is the message from Boinc about removing the app_info if you want more work is the point of interest.
This implies that the project developers know very well how a working (referred to the project policy) app_info.xml should look like. A lot of efford was done to implement a check of that.
Now lets look a little bit into the history of all that. My first post regarding an app_info.xml was on 17.July this year. Instead of getting an app_info, i received this answer: There is no need for an app_info.xml file, the ABP2 CUDA app is a stock app distributed automatically.
I came in contact with Sutaru Tsureku who posted the question in the seti-forum. It was JohnDK who posted there his idea of changing the client_state.xml to make that work.
I was asked You need to document everything very thoroughly and there is a post the following thing would have to be clarified .
Why is all that necessary and why does it take more than 7 weeks to simply ask the developers to distribute their app_info.xml? Did not even one of the responsible persons recognize that there is a need for that?
I'm really tierd to post all that. Crunching is my hobby, not my profession. There is another project coming to life again, orbit@home. They are watching asteroids and impact hazard. Lets see how this project will develop.
I can understand your frustration, but I'm not sure whom else to ask. Mods, Bruce Allen?
And while we're at it: couldn't you just use the app_info.xml for GPUs that Alexander Klietz posted? And we could try to add the CPU apps to it. Unfortunately I don't have access to a nVidia-enabled machine right now and am in a SIMAP race. It should be a solvable problem, though ;)
I can understand your frustration, but I'm not sure whom else to ask. Mods, Bruce Allen?
And while we're at it: couldn't you just use the app_info.xml for GPUs that Alexander Klietz posted? And we could try to add the CPU apps to it. Unfortunately I don't have access to a nVidia-enabled machine right now and am in a SIMAP race. It should be a solvable problem, though ;)
MrS
Hi,
yes shure, there is always a way. Let's wait a couple of days and see what happens.
Only one point needs further discussion.
As JohnDK posted, Only thing is the message from Boinc about removing the app_info if you want more work is the point of interest.
This implies that the project developers know very well how a working (referred to the project policy) app_info.xml should look like. A lot of efford was done to implement a check of that.
I've used the app_info on my other PC and here I don't get the message.
I tested various app_info.xml to run ABP2 CUDA and Seti CUDA concurrently three months ago. I was succesful at Windows (4CPu Xeon + GTX260 on XP 64bit, 2CPU C2D + 9600GT on XP 32bit) and Ubuntu (2CPU C2D + 9600GT on 9.04 64bit), but the things goes best when running ABP2 CUDA + Folding GPU3 on Win XP (2CPU C2D + 9600GT) using no app_info.xml. That is my experience.
Collatz, MW and DNETC I haven't tried as it is territory of ATI stream apps.
Memory consumption is indeed
)
Memory consumption is indeed a concern. From the data the Alex' posted I figured each ABP2 would consume <200 MB, which would enable running several of these on most modern cards. If they need ~400 MB max (as the current official requirement seems to be) there'd be much less potential to safely run more of them in parallel.
And of course the memory required by other CUDA projects is a concern. I'm not sure how to deal with this properly, as it's impossible to predict how much these are going to require.
Lately I haven't been following E@H closely. What's the current status of ABP3? I understand the goal is to port many more calculations onto the GPU which, if successful, could eleminate the need to efficiently handle the GPU as a coprocessor. Is there already an approximate ETA?
MrS
Scanning for our furry friends since Jan 2002
RE: Hi! That sounds very
)
Hi,
I'm sorry, I really can't understand why this is handled so complicated.
A proposal:
as long as nobody posted a complete and working app_info.xml,
initially load the app as now with the setting of 1.000
This setting is usable by everyone who can use it now. The project will not run into any problem.
All these crunchers who want to optimize their setting can change that according to their individual needs.
And when new wu's are uploaded, do not change their setting. This is the only change I'm asking for.
As everyone can see, it seems not to be that easy to compose an app_info.xml. And, in addition, it must be maintained when new apps are available.
I'm not asking for any change in the application, nor am I asking for any mechanism to find out how many apps could be run on a local gpu, nor am I asking for a way to make shure that other apps keep on working. All that is up to the cruncher who makes changes to his system as it would be if running an (unreliable) app_info.xml.
Or, on the other hand, a developer could compose the app_info. He should have all the necessary info. One of the developers had to write the script that adds the info to the client_state.xml. And he should maintain that (new app will come soon ...)
I agree to your post, that it makes no sense to make changes to an app which is (more or less) outdated. New apps are announced, they may or may not contain new features. But here I'm talking about actual running apps.
Please don't misunderstand me. If the new app is coming in a week, forget all that. But if it takes another two months, it would be very helpful to make this single change in the update-script. Or ask the developers for help with an app_info.xml. But it makes no sense to discuss that another two months.
As ETA posted: Let's try to be productive.
Regards,
Alexander
The app_info in this post
)
The app_info in this post works. Only thing is the message from Boinc about removing the app_info if you want more work. Haven't tried getting more work, but as another post in this tread said, you will still get work.
That app_info is for
)
That app_info is for crunching GPU only, which is not what the project wants. That's why you'd get "more" work without it (or by modifying it) - you'd also get cpu-only tasks.
@Alex: as far as I understand the client_state.xml is not meant to be edited by the user or to be used to control anything. The BOINC client writes its status into this file basically whenever anything happens.
That's not to say it couldn't be used in any other way. I suspect the fact that MW and SETI do not change the coproc count (as you observed) is more of an unwanted side effect or error somewhere. Anyway.. if it does the trick, why not? Leaving up to the power user to test it couldn't harm the project, could it?
MrS
Scanning for our furry friends since Jan 2002
RE: That app_info is for
)
Hi ETA,
every single word in your post is correct.
Only one point needs further discussion.
As JohnDK posted, Only thing is the message from Boinc about removing the app_info if you want more work is the point of interest.
This implies that the project developers know very well how a working (referred to the project policy) app_info.xml should look like. A lot of efford was done to implement a check of that.
Now lets look a little bit into the history of all that. My first post regarding an app_info.xml was on 17.July this year. Instead of getting an app_info, i received this answer:
There is no need for an app_info.xml file, the ABP2 CUDA app is a stock app distributed automatically.
I came in contact with Sutaru Tsureku who posted the question in the seti-forum. It was JohnDK who posted there his idea of changing the client_state.xml to make that work.
I was asked You need to document everything very thoroughly and there is a post the following thing would have to be clarified .
Why is all that necessary and why does it take more than 7 weeks to simply ask the developers to distribute their app_info.xml? Did not even one of the responsible persons recognize that there is a need for that?
I'm really tierd to post all that. Crunching is my hobby, not my profession. There is another project coming to life again, orbit@home. They are watching asteroids and impact hazard. Lets see how this project will develop.
Regards,
Alexander
I can understand your
)
I can understand your frustration, but I'm not sure whom else to ask. Mods, Bruce Allen?
And while we're at it: couldn't you just use the app_info.xml for GPUs that Alexander Klietz posted? And we could try to add the CPU apps to it. Unfortunately I don't have access to a nVidia-enabled machine right now and am in a SIMAP race. It should be a solvable problem, though ;)
MrS
Scanning for our furry friends since Jan 2002
RE: I can understand your
)
Hi,
yes shure, there is always a way. Let's wait a couple of days and see what happens.
Kind regards,
Alexander
RE: Only one point needs
)
I've used the app_info on my other PC and here I don't get the message.
But I have to give up using
)
But I have to give up using Einstein, I keep getting permanent upload error when uploading results as I talked about here.
I tested various app_info.xml
)
I tested various app_info.xml to run ABP2 CUDA and Seti CUDA concurrently three months ago. I was succesful at Windows (4CPu Xeon + GTX260 on XP 64bit, 2CPU C2D + 9600GT on XP 32bit) and Ubuntu (2CPU C2D + 9600GT on 9.04 64bit), but the things goes best when running ABP2 CUDA + Folding GPU3 on Win XP (2CPU C2D + 9600GT) using no app_info.xml. That is my experience.
Collatz, MW and DNETC I haven't tried as it is territory of ATI stream apps.