Forum > GPU crunching
AK V8 + CUDA MB team work mod
Jason G:
--- Quote from: Raistmer on 05 Feb 2009, 08:58:50 am ---Pure example of CPU scheduling bug in Vista IMHO.
--- End quote ---
Nope, It's not a bug, it's on purpose. If it fills up the first processors first, then the other three can power down and save energy (probably intended for notebooks I suppose). You might want to double check that power saving is disabled in the Bios (&Vista settings?) , and do exactly what you did, assign the single threaded program to the last core. You shouldn't need to place affinity controls on the cuda feeder then, but it would be interesting to know if it then migrates to the last core.
XP Rules! ;)
Raistmer:
--- Quote from: Jason G on 05 Feb 2009, 09:09:42 am ---
--- Quote from: Raistmer on 05 Feb 2009, 08:58:50 am ---Pure example of CPU scheduling bug in Vista IMHO.
--- End quote ---
Nope, It's not a bug, it's on purpose. If it fills up the first processors first, then the other three can power down and save energy. You might want to double check that power saving is disabled in the Bios, and do exactly what you did, assign the single threaded program to the last core. You shouldn't need to place affinity controls on the ciuda feeder then, but it would be interesting to know if it then migrates to the last core.
XP Rules! ;)
--- End quote ---
Sorry, not the case. Power saving disabled, moreover, you forgot that all CPUs still busy with another 4 CPU-based tasks (2 Ak_v8 2 einstein on moment of observation). So there is absolutely no power saving could be done there.
And change affinity only for non-BOINC app is not enough. After I did that situation remains the same. And only when I exclude that core for CUDA app it begin work as usual.
I repeat this experiment few times so pretty sure in that.
Jason G:
--- Quote from: Raistmer on 05 Feb 2009, 09:14:22 am ---Power saving disabled, moreover, you forgot that all CPUs still busy with another 4 CPU-based tasks (2 Ak_v8 2 einstein on moment of observation). So there is absolutely no power saving could be done there.
--- End quote ---
LoL fair enough , you didn't say you were running other apps, and the scheduling algorithm will still attempt to oversubscribe the first core before moving on, So it is still the Windows strategy at work, despite all cores running.
--- Quote ---And change affinity only for non-BOINC app is not enough. After I did that situation remains the same. And only when I exclude that core for CUDA app it begin work as usual.
I repeat this experiment few times so pretty sure in that.
--- End quote ---
Yep, so you are running these apps: Single thread chem model, + 2xAKv8, 2xEinstein & 1xCuda, Which equals full subscription + 1.04 cores. Unfortunately Windows scheduler on any version isn't very good with that. For proof , run RthDribl (GPU test App) without other apps or Boinc Running (Smooth), Then Run Boinc with no Cuda app, and look again at RthDribl (jerky). Boinc alone interacting with Windows CPU Scheduler is oversubscribed already (Using up all time slices).
Beter If oversubscribed, when you have some app that interacts to cause crowded scheduling, might be to reduce Boinc allocation by 1 core. [Hmm... Might be nice if Boinc adjusted this automatically on the fly ....]
Jason
Richard Haselgrove:
--- Quote from: Jason G on 05 Feb 2009, 09:24:20 am ---
[Hmm... Might be nice if Boinc adjusted this automatically on the fly ....]
--- End quote ---
Did you see the trac tickets #841 and #842 that Jord made us write the other day?
Sounds like we need to extend <exclusive_app> to include <exclusive_app_resource_count_n> - "My game takes 2 cpu cores and a video card, please".
Jason G:
I didn't see it no, but it is one thing that makes sense, and I'll take a closer look. I would kindof like to see Boinc detect the oversubscription status, and throttle itself back a core (or more) without intervention (as obviously Windows doesn't quite manage).
Some good discussion on Intel's TBB wiki recongnises the problems:
from Here
--- Quote ---...In the future, we hope to see additional interfaces in operating systems to coordinate threaded applications including those built with TBB. We agree with those who have called for OSes to get out of the business of scheduling threads and focus instead on allocation of processors to applications. It’s an interesting topic to say the least.
--- End quote ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version