I was just going by the exact status on the waiting WU's (waiting for gpu memory) to mean just that, and with my card having 895m I knew I was not pushing that limit either.
Hello Mike,
waiting for gpu memory is a different message.
I checked that now. You could change one line (I tried it in the client_state.xml)
219430400.000000
This is 2 lines after
originally is has the value 419430400.000000. I just changed the first number.
So it seems that einstein reserves more videoram than necessary. Right now I have 4 cuda-wu's running.
That should tell the BOINC client that each Einstein may need up to 420 MB of GPU-RAM, that's why BOINC doesn't start more than 2 tasks on your card. Seems like E@H is erroring on the safe side here. Or we didn't look closely enough to spot such peak memory usage?
The memory limit currently in use by E@H resulted from several cases when users complained that the E@H app would try to start but then failed or got stuck because of lack of video RAM. So I think it would be unwise to lower this limit again as a project wide setting.
The 219430400.000000 did the trick, and now can crunch up to 4. Might convert this scheme to an app_info.xml as listed above, because you have to reenter this value in the client_state member if you restart boinc or update the project it seems and as stated. Thanks for all advise and help.
Crunch on...... -Mike
Hey guys, I have been reading this post and have changed the 'COUNT' parm in the client_state.xml member to .22 and even to .33 on my GTX260-216 with 896m of memory. I can get two ABP2 CUDA23 task running but all others have a status of waiting on memory. GPUZ shows less that 400m being used. SO I can't seem to get a 3rd ABP2 CUDA WU to start? My CPU is a AMD 940 QUAD, so I have cores to spare. Is the 419430400.000000 parm right after the COUNT parm in the client_state.xml limiting me to this value instead of the 896m that I actually have on the card. I also have a GTX470 Fermi with 1280m that has the same value and has the same 2 WU limit (waiting on memory). Do I need to either reset the project or even detach and then reattach to Einstein so that my card gets properly set??
Boinc 6.10.58
4gig memory
WIN XP 32
AMD QUAD 940 and 955
Appreciate the help and info on this board.
Try going into the Boinc Manager and changing the setting under Advanced, Preferences, processor usage tab where it says:
"While processor usage is less than ___ percent (O means no restriction)"
Change that to a zero and then click ok at the bottom and see if your pc doesn't start crunching again. This setting is for those people that want their pc to be more responsive while crunching and stops crunching when the cpu reaches that percentage of free cpu usage. So if a program is a heavy cpu user Boinc may not run much, as opposed to just running at the lowest time slice.
The memory limit currently in use by E@H resulted from several cases when users complained that the E@H app would try to start but then failed or got stuck because of lack of video RAM. So I think it would be unwise to lower this limit again as a project wide setting.
Happy crunching
HBE
Hi Bikeman,
currently I do some maintenance and upgrades on a friends computer and shure I do some crunching as test of stability.
For that reason I ran one single Einstein Cuda wu at a time and monitored the GPU with Afterburner.
After 6 hours of test (GTS250, Driver 258.96) it shows maximum memory usage of 211 MB.
With this result I went to my own system #2 and simply removed the line with the gpu-ram. Einstein runs without any problem.
Then I checked the version history of BOINC and looked for entries about GPU's.
Version 6.10.19 - 6.10.56 ¶
released: 24 May 2010 NOT COMPLETE
* New: Added ability to ignore specific GPU cards through the use of ignore device through the use of a configuration file option
* New: Snooze GPU option off of the system tray menu
* New: Adjust GPU activity settings via the advanced view activity menu
* New: Added ability for a project to be specified as a "Backup Project" by setting its resource share to 0
* Fix: Recover from crashes in Nvidia and ATI GPU functions (Linux, Mac)
Version 6.10.17 ¶
released: 30 Oct 2009
* Support added for ATI GPUs.
* Support for automatic proxy detection on Windows.
* Improvements to the CPU/GPU scheduler.
* A new default screen saver.
It does not specify, which improvements were done. But it raises one question:
are all settings from EINSTEIN up to date? Is someone there who maintains that? I mean, if it's possible to delete some settings in the client_state.xml and all apps are still working, it looks like BOINC has a mechanism to handle that.
It looks like its time for a major update from the dev's!
You listed additions to the client, not to the back-end, which is a completely different kettle of BOINC. Want to see those changes? Go look through the timeline, starting on at least the 25th of March, and check for web and scheduler changes to get a bit of a clue what was changed. At least skip any changes to client and MGR.
If the admins here would now update to the latest code, they'd invite the new credit system as it is being tested on Seti into their code as well. Probably not what you want at this time.
I think Alex meant that the maximum memory consumption number provided by the project (~400 MB) may need an update, since he's only seeing a reported consumption of 211 MB at maximum. This has nothing to do with neither the BOINC client / manager nor the server software, it's just a project setting.
Still I think it's important to understand that "power-users" who want to squeeze the last bit of performance from their hosts for BOINC are a minority and that a project has to select settings mainly fro the majority of users who want to see BOINc crunch in the background without any noticeable impact for their user experience.
Even with the current setting, memory allocation problems are main reason for apps not finishing the computation successfully. Note that even tho there might be enough memory left when you start the app, some other processes might request more memory while the app is running, so it's probably not a nice thing to do for E@H to start an app if this will just barely fit into available memory because that will not leave any headroom for other stuff. I think it's really important for the user acceptance of distributed computing to be "nice".
Totally agreed. I also had a sentence like "if there are problem then Einstein can not afford not to play it safe - the damage done to reputation would be far worse than missing out on some crunching power" in mind but got distracted somehow before I wrote it down. Thanks for fixing!
RE: I was just going by the
)
Hello Mike,
waiting for gpu memory is a different message.
I checked that now. You could change one line (I tried it in the client_state.xml)
219430400.000000
This is 2 lines after
originally is has the value 419430400.000000. I just changed the first number.
So it seems that einstein reserves more videoram than necessary. Right now I have 4 cuda-wu's running.
Regards
Alexander
RE: originally is has the
)
That should tell the BOINC client that each Einstein may need up to 420 MB of GPU-RAM, that's why BOINC doesn't start more than 2 tasks on your card. Seems like E@H is erroring on the safe side here. Or we didn't look closely enough to spot such peak memory usage?
MrS
Scanning for our furry friends since Jan 2002
Hi! The memory limit
)
Hi!
The memory limit currently in use by E@H resulted from several cases when users complained that the E@H app would try to start but then failed or got stuck because of lack of video RAM. So I think it would be unwise to lower this limit again as a project wide setting.
Happy crunching
HBE
The 219430400.000000 did the
)
The 219430400.000000 did the trick, and now can crunch up to 4. Might convert this scheme to an app_info.xml as listed above, because you have to reenter this value in the client_state member if you restart boinc or update the project it seems and as stated. Thanks for all advise and help.
Crunch on...... -Mike
RE: Hey guys, I have been
)
Try going into the Boinc Manager and changing the setting under Advanced, Preferences, processor usage tab where it says:
"While processor usage is less than ___ percent (O means no restriction)"
Change that to a zero and then click ok at the bottom and see if your pc doesn't start crunching again. This setting is for those people that want their pc to be more responsive while crunching and stops crunching when the cpu reaches that percentage of free cpu usage. So if a program is a heavy cpu user Boinc may not run much, as opposed to just running at the lowest time slice.
RE: Hi! The memory limit
)
Hi Bikeman,
currently I do some maintenance and upgrades on a friends computer and shure I do some crunching as test of stability.
For that reason I ran one single Einstein Cuda wu at a time and monitored the GPU with Afterburner.
After 6 hours of test (GTS250, Driver 258.96) it shows maximum memory usage of 211 MB.
With this result I went to my own system #2 and simply removed the line with the gpu-ram. Einstein runs without any problem.
Then I checked the version history of BOINC and looked for entries about GPU's.
Version 6.10.19 - 6.10.56 ¶
released: 24 May 2010 NOT COMPLETE
* New: Added ability to ignore specific GPU cards through the use of ignore device through the use of a configuration file option
* New: Snooze GPU option off of the system tray menu
* New: Adjust GPU activity settings via the advanced view activity menu
* New: Added ability for a project to be specified as a "Backup Project" by setting its resource share to 0
* Fix: Numerous CPU/GPU scheduling fixes
* Fix: Numerous work-fetch fixes
* Fix: Recover from crashes in Nvidia and ATI GPU functions (Linux, Mac)
Version 6.10.17 ¶
released: 30 Oct 2009
* Support added for ATI GPUs.
* Support for automatic proxy detection on Windows.
* Improvements to the CPU/GPU scheduler.
* A new default screen saver.
It does not specify, which improvements were done. But it raises one question:
are all settings from EINSTEIN up to date? Is someone there who maintains that? I mean, if it's possible to delete some settings in the client_state.xml and all apps are still working, it looks like BOINC has a mechanism to handle that.
It looks like its time for a major update from the dev's!
Regards,
Alexander
RE: It looks like its time
)
What do you think was just done?
You listed additions to the client, not to the back-end, which is a completely different kettle of BOINC. Want to see those changes? Go look through the timeline, starting on at least the 25th of March, and check for web and scheduler changes to get a bit of a clue what was changed. At least skip any changes to client and MGR.
If the admins here would now update to the latest code, they'd invite the new credit system as it is being tested on Seti into their code as well. Probably not what you want at this time.
I think Alex meant that the
)
I think Alex meant that the maximum memory consumption number provided by the project (~400 MB) may need an update, since he's only seeing a reported consumption of 211 MB at maximum. This has nothing to do with neither the BOINC client / manager nor the server software, it's just a project setting.
MrS
Scanning for our furry friends since Jan 2002
Still I think it's important
)
Still I think it's important to understand that "power-users" who want to squeeze the last bit of performance from their hosts for BOINC are a minority and that a project has to select settings mainly fro the majority of users who want to see BOINc crunch in the background without any noticeable impact for their user experience.
Even with the current setting, memory allocation problems are main reason for apps not finishing the computation successfully. Note that even tho there might be enough memory left when you start the app, some other processes might request more memory while the app is running, so it's probably not a nice thing to do for E@H to start an app if this will just barely fit into available memory because that will not leave any headroom for other stuff. I think it's really important for the user acceptance of distributed computing to be "nice".
Happy crunching
HBE
Totally agreed. I also had a
)
Totally agreed. I also had a sentence like "if there are problem then Einstein can not afford not to play it safe - the damage done to reputation would be far worse than missing out on some crunching power" in mind but got distracted somehow before I wrote it down. Thanks for fixing!
MrS
Scanning for our furry friends since Jan 2002