Seti@Home optimized science apps and information
Optimized Seti@Home apps => Discussion Forum => Topic started by: Pepi on 01 Oct 2011, 07:28:57 am
-
I have edited limits.conf
and set to root hard priority -19 and/or root soft priority -19 ( I login as root) (tried both version)
When I start Boinc it is set to -19 and that is ok, but when I start calculating Primegrid in the Boinc ,4 process are set to 19.
I can set it with renice to -19, but that is ok until process is finished and pid is changed,then priority is again 19.
How to solve this?
Centos 6 86_64
AuthenticAMD
AMD Phenom(tm) II X4 B50 Processor [Family 16 Model 5 Stepping 3]
(4 processors) ---
Linux 2.6.32-71.29.1.el6.x86_64
I would like to test, is with priority -19 crunching is faster or same as with priority 19, so that is reason why I try this.
Thanks for reply
-
Quite some time ago I tried seti@home with negative niceness and it was slower than 0.
Running with -19 will probably lock your computer. Use no less than 0.
So, do you want everything boinc related to run at 0 or only some of the tasks?
-
Yesterday , I run many WU with priority -19 without any problems. That computer only crunch Primegrid, and dont do anything else. So what I wont : boinc process run at -19, ( and got that) but app for crunching Primegrid go to 0. I wont they also go to -19. Manually setting works until app crunch WU, but when finished, pid is changed and again it is priority 0.
-
Put in your cc_config.xml the following:
<options>
<no_priority_change>1</no_priority_change>
</options>
-
There si primegrid_llr_wrapper and primegrid_sllr_3.8.4 : so that are two applications.
When I don't use <no_priority_change>1</no_priority_change> then primegrid_llr_wrapper is showing rarely and have priority 19
When I use <no_priority_change>1</no_priority_change> then primegrid_llr_wrapper is showing often but have priority -19
But in both cases primegrid_sllr_3.8.4 ( which I believe) is main app have priority 19. So some progress are made: i will now leave under night to see
how this change ( or will be) this change reflect on crunch time.
So rise of priority of primegrid_sllr_3.8.4 will remain unsolved, but now is one step closer :)
UPDATE: you was right: I test it on 8 WU and it was slower, in both cases (2 *4 WU) all are finished in nearly same , near longest time I have had.
So now I will try new tactic: using syntax enabled: I will start BOINC then download few WU in cache, and then raise priority of primegrid_sllr_3.8.4 but not primegrid_llr_wrapper.
-
UPDATE: you was right: I test it on 8 WU and it was slower, in both cases (2 *4 WU) all are finished in nearly same , near longest time I have had.
As I said there is no point for negative priority, in fact it could be worse. Stick with 0.
If <no_priority_change>1</no_priority_change> doesn't affect all primegrid stuff you'll have to use a script. Check at the bottom of this post http://lunatics.kwsn.net/3-linux/seti-mb-cuda-for-linux.msg30557.html#msg30557 Of course you'll have to change it for use in primegrid. With this script you'll not need the no_priority_change option.
-
Thanks
But after all I will back to default values :)