+- +-
Say hello if visiting :) by Gecko
11 Jan 2023, 07:43:05 pm

Seti is down again by Mike
09 Aug 2017, 10:02:44 am

Some considerations regarding OpenCL MultiBeam app tuning from algorithm view by Raistmer
11 Dec 2016, 06:30:56 am

Loading APU to the limit: performance considerations by Mike
05 Nov 2016, 06:49:26 am

Better sleep on Windows - new round by Raistmer
26 Aug 2016, 02:02:31 pm

Author Topic: Runninh high priority  (Read 7793 times)

Offline TouchuvGrey

  • Knight o' The Round Table
  • ***
  • Posts: 151
Runninh high priority
« on: 07 Sep 2011, 07:59:11 pm »
     i have 8 WU's running high priority on my computer:
intel core i7 920 cpu, 12 gigs tri channel DDR3, GTS250 and
GTX460 GPU's.   WU's i'm referring to are not due until 09/17/11.

    High CPU usage is slowing my machine down considerably.
Any ideas why they are "high priority" given that they have 10 days until due
and can i change their priority to normal ?
Because we are NOT alone.

Offline Josef W. Segur

  • Janitor o' the Board
  • Knight who says 'Ni!'
  • *****
  • Posts: 3112
Re: Runninh high priority
« Reply #1 on: 07 Sep 2011, 10:49:53 pm »
     i have 8 WU's running high priority on my computer:
intel core i7 920 cpu, 12 gigs tri channel DDR3, GTS250 and
GTX460 GPU's.   WU's i'm referring to are not due until 09/17/11.

    High CPU usage is slowing my machine down considerably.
Any ideas why they are "high priority" given that they have 10 days until due
and can i change their priority to normal ?

On your Computer 5807368, the most recently reported tasks which were sent to be done on CPU, such as task 2059748228, were actually done with the x38g CUDA app. That's welcome testing, but the times from tasks done that way affect the server-side averages for the app the Scheduler intended them to use.

The servers now think your CPU is faster than it really is. So you can end up with more CPU work than you meant to have, and with short estimates. Then when one of those tasks completes, DCF jumps up to a higher level which indicates running in the usual FIFO order some tasks would be in danger of missing deadline. The core client then does some tasks in high priority which its internal simulation indicates are most in danger of missing deadline if done in FIFO order.

The APR for the CPU application isn't seriously too high, I think the high priority will end by itself fairly soon. It would be possible by editing client_state.xml to at least temporarily get it out of high priority immediately, but I recommend letting BOINC work through it. Perhaps the simplest thing you could do is simply abort some unstarted work, but I don't think that's really needed either.

High priority is just an indication of which order tasks are being done, not a boost to the process priority or anything like that. Take a look with Task Manager and you'll see the CPU tasks are still being done at low process priority. However, it's the VHAR shorties which get done first in that mode, and those tend to use cache memory heavily. They even contend with each other for cache, it has been known for a long time that when running multiple VHAR tasks simultaneously on a multicore system the runtimes are longer than when they're paired with midrange or lower tasks (or tasks from another project).
                                                         Joe

 

Welcome, Guest.
Please login or register.
 
 
 
Forgot your password?
Members
Total Members: 97
Latest: ToeBee
New This Month: 0
New This Week: 0
New Today: 0
Stats
Total Posts: 59559
Total Topics: 1672
Most Online Today: 222
Most Online Ever: 983
(20 Jan 2020, 03:17:55 pm)
Users Online
Members: 0
Guests: 191
Total: 191
Powered by EzPortal