Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
World Community Grid Forums
Category: Retired Forums Forum: Member-to-Member Support [Read Only] Thread: Thread Priority |
No member browsing this thread |
Thread Status: Active Total posts in this thread: 7
|
Author |
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hi, Grid Gurus... I was hoping one of uber gurus (Rick, you reading this?) could help me with an issue I'm having.
I have the grid software installed at work (with permission) on machines that are used to render 3D animation. Since the grid runs at low priority, there is no conflict, as renders would bump the grid out of the way, do their thing, and then the grid would resume. Until now. We recently changed the way our distributed render system works, and the new software ALSO runs at low priority. As a result, these dual processor systems are not taking advantage of both processors the way they should... when the grid is running. The problem is, since both processes are running at low priority, the system assigns one low priority process to one processor, and other to the 2nd processor. That's fine for the grid software, since it only uses one processor anyway. That's NOT fine for the distributed renders, which finish much slower, since they do not have access to both processors, as they are "tied" with the grid software from a priority standpoint. Is there a way you know of to force the grid to run at an *extra* low priority? I seem to recall reading somewhere that there are other priority levels than the basic levels listed in Task Manager. If there is a way I can get the grid software to run at the lower than low priority level, every time (in case of a reboot, I can't have it return to defaults), then I'm in business. If I can't resolve this issue soon, though, I'm going to have to restrict the grid software to running after hours... that would just be sad. Hope to hear from you soon, -CD |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Compudude --
I am passing your question along on the Community Admin pipeline they set up for us. Regards, Your team mate, |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Compudude -- I am passing your question along on the Community Admin pipeline they set up for us. Thanks, Dave. |
||
|
Viktors
Former World Community Grid Tech Joined: Sep 20, 2004 Post Count: 653 Status: Offline Project Badges: |
We already have the Rosetta program running at the lowest priority we can set on Windows. Unfortunately, this doesn't help in your situation. If you have any way to modify your rendering software to use a higher priority, that would fix the problem. Another thing that could be done is to set the grid agent to run only as a screen saver. Then add a script to run alongside your rendering software to keep the system from going into screen saver mode while the rendering software is running. If you send a windows message to pretend to toggle the shift key periodically using something like keybd_event, that would do it. Or you could have your script set the screen saver off during your run, and turn in back on afterwards. Otherwise, running after hours would have to do. Hope this helps.
|
||
|
Alther
Former World Community Grid Tech United States of America Joined: Sep 30, 2004 Post Count: 414 Status: Offline Project Badges: |
You are correct. A process' priority in Windows is composed of 2 values: the base priority class and the relative priority within the class. The Task Manager only lets you manipulate the base priority, but not the relative priority.
----------------------------------------Rosetta is already running at the lowest priority the system (1) has to offer, so you can't make it any lower. It also sounds like the same is true of your distributed rendering software, thus the CPU contention. Because of the way priorities work in Windows, changing the priority class via the Task Manager for either of these two won't change the real priority (unless you change it to Real Time, which I do NOT recommend as your whole system will become unresponsive). Your only option is to change the priority of the rendering software, if possible (e.g. through a config file or parameter) or halt the Grid Agent for the necessary period of time. You can do this via a profile if it's always the same hours, or you can exit the agent manually and restart manually.
Rick Alther
Former World Community Grid Developer |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Rick,
It would certainly help if Compudude could scedule the grid agent from ( for instance ) 19:00 - 08:00hrs instead of from 00:00 - 08:00hrs. I know this is suggested earlier, and I hope it can be implemted in the future release update. Regards |
||
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
This change was implemented in the Device Profile in Device Manager at the end of December 2004. It is possible to schedule execution from 19:00 to 08:00. It shows up as 19:00 - 24:00 and 0:00 - 08:00. Here is the notice in Member News: http://www.worldcommunitygrid.org/forums/wcg/viewthread?thread=1222
|
||
|
|